From gunnar.hellstrom@omnitor.se Sat Jun 1 00:34:21 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C173D21F84CD for ; Sat, 1 Jun 2013 00:34:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsdWznQmEFGQ for ; Sat, 1 Jun 2013 00:34:16 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 41A2221F848E for ; Sat, 1 Jun 2013 00:34:14 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Sat, 1 Jun 2013 09:34:05 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 956CB3A080 for ; Sat, 1 Jun 2013 09:34:05 +0200 (CEST) Message-ID: <51A9A3F2.3090106@omnitor.se> Date: Sat, 01 Jun 2013 09:34:10 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <51A907C2.6040801@matthew.at> <51A912DB.5010104@alum.mit.edu> In-Reply-To: <51A912DB.5010104@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTT (was Re: No Plan) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Jun 2013 07:34:21 -0000 On 2013-05-31 23:15, Paul Kyzivat wrote: > I've been through this conversation before. > There are no winners. Different strokes for different folks. Agreed, or different strokes for different situations. There is voice calls, video calls and real-time text for the active intensive conversational situations. There is voice mail, video mail and text messaging for more loosely coupled exchange of information. > IMO the texting UI should be as independent as possible of this > stylistic difference, and the actual protocol. The session > establishment should sort out the "best" compromise between the > desires and capabilities of the two ends. > > Thanks, > Paul > Agreed. > On 5/31/13 4:27 PM, Matthew Kaufman wrote: >> On 5/30/2013 10:32 PM, Gunnar Hellstrom wrote: >>> I do not understand why modern communication users accept to see a >>> chat state indication of "composing" instead of really seeing what >>> text is composed. >> >> Perhaps because you haven't done user studies of SMS-style >> compose-and-send vs. real-time text. >> >> I suggest you do that, and then you'll understand the several reasons >> why most users (perhaps interestingly, excluding those users who are >> hearing-impaired) prefer the former. Tests are done and indicate the opposite. >> >>> With real-time text you get rid of the frustration that "composing" >>> creates. >> >> And you add the sender's frustration of not being able to edit and >> rethink their message before sending it, and the expectation on both the >> sender and the receiver that they remain present for the duration of the >> conversation rather than using it as a completely asynchronous messaging >> modality, to reply when convenient. [this is just a subset of what the >> user studies show, but touches a couple of the most common points] Yes, that are commonly used arguments. There are benefits of both. Different strokes and usability in different situations. So I agree with Paul's conclusion above. /Gunnar >> >> Matthew Kaufman >> _______________________________________________ >> 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 emil@sip-communicator.org Sat Jun 1 00:51:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9675E21F894E for ; Sat, 1 Jun 2013 00:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46qLIgABH42q for ; Sat, 1 Jun 2013 00:51:05 -0700 (PDT) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 96AA521F88D8 for ; Sat, 1 Jun 2013 00:51:05 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id 6so1103774bkj.8 for ; Sat, 01 Jun 2013 00:51:04 -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=yy5mlKwz6vj+9Xg8Eiw6kZHD6395d9alYrUDc5H7+4U=; b=l5BdPQGD5wj0uGEGxFRu0zzI191PzEtA60fWHt6WjQTBBj/yTLLMLKyuaA/c4GJA0M 0AW18WYJYSEUm5Vel4Kju0Q0+gdWXAv8TqDUYQUB1p69MLxJZED4qdkNwGCoaTqOekoB zTm/OLwEVxIThZ0bL5lAj8nUH65SPGnLHrfOqWAKKknPfRUhnPXwA477nXizjxxu1oPG EAMQK8Ob5m4G1y429D4rA3Cp3oSeew7udveZIW/45AyJ8LD86mhqb6IZzubftaGVxtMF 2iX2rbpFhoVORWpmBvyG0vIMQB53GxWBRTXn6Eh0yNHUnQMfwob8W5bWsninDLSdL8Ek TkWA== X-Received: by 10.205.75.74 with SMTP id yz10mr4226488bkb.179.1370073064320; Sat, 01 Jun 2013 00:51:04 -0700 (PDT) Received: from camionet.local ([83.228.77.158]) by mx.google.com with ESMTPSA id jy7sm7864165bkb.6.2013.06.01.00.51.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Jun 2013 00:51:03 -0700 (PDT) Message-ID: <51A9A7E2.7000907@jitsi.org> Date: Sat, 01 Jun 2013 10:50:58 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <51A65017.4090502@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmiuGNfUugiviAQp7ITSwDrTwQjiH7QhDnZ17f3AY1orv0t9KmasloAuViov7KYwm1xs2Gg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Jun 2013 07:51:06 -0000 Hey Christer, Apologies for the lag. On 30.05.13, 10:44, Christer Holmberg wrote: > Hi Emil, > > The draft says: > > "For the sake of interoperability this specification strongly advises > against the use of multiple m= lines for a single media type." This should probably be clarified. The above referred mostly to a browser's expectations and default offers. Multiple m= lines can confuse a number of existing legacy endpoints which is why they should be avoided when initiating a session that could reach a similar device (and by default this should be assumed for any session). If applications *know* that they need to have multiple m= lines of a given type they can request this the same way they could do it with Plan B: If the application wishes, it can request that a given media source be placed onto a separate m= line, by setting a new .content property on the desired MediaStreamTrack; the values for the .content property are those defined for the a=content attribute in [RFC4796]. I'll make sure this is part of the next version. Does this make sense? Emil > My understanding is that the usage of multiple m= lines for a single media type would not affect the mechanism as such, but I just want to verify that :) > > Also, there ARE "legacy" implementations that use multiple m= lines for a single media type (e.g. video enabled devices using two video m= lines: one for camera content, and one for slides). > > So, while I definitely think that legacy interoperability shall be taken into consideration, I would not like to make such strong statements. In my opinion (the draft also talks about it), the usage of multiple simultaneous SSRCs per m- line is a much bigger issue when it comes to legacy interoperability. > > Also, in CLUE we have been working on signaling scenarios with multiple m= lines per media type. > > > Regards, > > Christer > > > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Emil Ivov > Sent: 29. toukokuuta 2013 22:00 > To: rtcweb@ietf.org > Subject: [rtcweb] No Plan > > Hey all, > > Based on many of the discussions that we've had here, as well as many others that we've had offlist, it seemed like a good idea to investigate a negotiation alternative that relies on SDP and Offer/Answer just a little bit less. > > The following "no plan" draft attempts to present one such approach: > > http://tools.ietf.org/html/draft-ivov-rtcweb-noplan > > The draft relies on conventional use of SDP O/A but leaves the intricacies of multi-source scenarios to application-specific signalling, with potentially a little help from RTP. > > Hopefully, proponents of Plans A and B would find that the interoperability requirements that concerned them can still be met with "no plan". Of course they would have to be addressed by application-specific signalling and/or signalling gateways. > > Comments are welcome! > > Cheers, > Emil > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > . > -- https://jitsi.org From christer.holmberg@ericsson.com Sat Jun 1 04:05:49 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F2F21F8808 for ; Sat, 1 Jun 2013 04:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.204 X-Spam-Level: X-Spam-Status: No, score=-5.204 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDfhdXMV5eHa for ; Sat, 1 Jun 2013 04:05:42 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1274E21F8746 for ; Sat, 1 Jun 2013 04:05:41 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-67-51a9d58419fc Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 98.DC.15700.485D9A15; Sat, 1 Jun 2013 13:05:40 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Sat, 1 Jun 2013 13:05:39 +0200 From: Christer Holmberg To: Emil Ivov Thread-Topic: [rtcweb] No Plan Thread-Index: AQHOXJ6w4pPZWNQxOUWhx5DufiT5nZkdWAeQgAMGtQCAAFWpzg== Date: Sat, 1 Jun 2013 11:05:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C380AA2@ESESSMB209.ericsson.se> References: <51A65017.4090502@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se>, <51A9A7E2.7000907@jitsi.org> In-Reply-To: <51A9A7E2.7000907@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+JvrW7L1ZWBBh2T1S3W7JzAYrH2Xzu7 A5PHkiU/mTz+vwkMYIrisklJzcksSy3St0vgyrh8/iFjQZdcxZ19zawNjE/Euxg5OSQETCQW z+lghLDFJC7cW8/WxcjFISRwmFHiw8+djBDOYkaJ+YseAjkcHGwCFhLd/7RBGkQE5CW62xYx gdjMAuoSdxafYwexhQVkJbZMnsEEUSMncf3nPjYI20ni7+RvYDUsAioSF++8ZAMZySvgK9H/ IhliVSejxNLZJ8FWcQpoSmz+FgZSzgh02/dTa6BWiUvcejKfCeJmAYkle84zQ9iiEi8f/2MF aZUQUJRY3i8HUa4jsWD3JzYIW1ti2cLXYOW8AoISJ2c+YZnAKDYLydRZSFpmIWmZhaRlASPL Kkb23MTMnPRyw02MwOg4uOW37g7GU+dEDjFKc7AoifPq8S4OFBJITyxJzU5NLUgtii8qzUkt PsTIxMEp1cDI8stv0mLbVxl/LunZxMmvlexNXemy6tH3b1cWXJGdff1G05RbtjnMPUfWPZuo dCRu+snvJXndSnH86vyr3nHXu12Pkm9w5c2f+9hvR5/R/c9L1uqnf9WesWkG/zmrcOZVfc+D nZTMLyStTFBK+BPcemPW5iLeM1cK587z4io1K5x/PWnS1a9MSizFGYmGWsxFxYkARSKhb1wC AAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Jun 2013 11:05:49 -0000 Hi, >> The draft says: >> >> "For the sake of interoperability this specification strongly advi= ses >> against the use of multiple m=3D lines for a single media type." > > This should probably be clarified. The above referred mostly to a > browser's expectations and default offers. Multiple m=3D lines can confus= e > a number of existing legacy endpoints which is why they should be > avoided when initiating a session that could reach a similar device (and > by default this should be assumed for any session). > > If applications *know* that they need to have multiple m=3D lines of a > given type they can request this the same way they could do it with Plan = B: > > If the application wishes, it can request that a given > media source be placed onto a separate m=3D line, by setting a new > .content property on the desired MediaStreamTrack; the values for the > .content property are those defined for the a=3Dcontent attribute in > [RFC4796]. > > I'll make sure this is part of the next version. > > Does this make sense? I have nothing against a general recommendation to, for a given media type,= have as few m- lines as possible.=20 But, I do think the draft need to point out that it is not always possible,= e.g. because: 1) m- lines have different characteristics (normally indicated using SDP at= tributes) that does not "fit" all content for the given media type; 2) different protocols are used for different m- lines, even if the media t= ype is the same; or 3) the remote endpoint only supports a single (or, another given number) of= sources per m- line. Etc. Regards, Christer > My understanding is that the usage of multiple m=3D lines for a single me= dia type would not affect the mechanism as such, but I just want to verify = that :) > > Also, there ARE "legacy" implementations that use multiple m=3D lines for= a single media type (e.g. video enabled devices using two video m=3D lines= : one for camera content, and one for slides). > > So, while I definitely think that legacy interoperability shall be taken = into consideration, I would not like to make such strong statements. In my = opinion (the draft also talks about it), the usage of multiple simultaneous= SSRCs per m- line is a much bigger issue when it comes to legacy interoper= ability. > > Also, in CLUE we have been working on signaling scenarios with multiple m= =3D lines per media type. > > > Regards, > > Christer > > > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Emil Ivov > Sent: 29. toukokuuta 2013 22:00 > To: rtcweb@ietf.org > Subject: [rtcweb] No Plan > > Hey all, > > Based on many of the discussions that we've had here, as well as many oth= ers that we've had offlist, it seemed like a good idea to investigate a neg= otiation alternative that relies on SDP and Offer/Answer just a little bit = less. > > The following "no plan" draft attempts to present one such approach: > > http://tools.ietf.org/html/draft-ivov-rtcweb-noplan > > The draft relies on conventional use of SDP O/A but leaves the intricacie= s of multi-source scenarios to application-specific signalling, with potent= ially a little help from RTP. > > Hopefully, proponents of Plans A and B would find that the interoperabili= ty requirements that concerned them can still be met with "no plan". Of cou= rse they would have to be addressed by application-specific signalling and/= or signalling gateways. > > Comments are welcome! > > Cheers, > Emil > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > . > -- https://jitsi.org From ibc@aliax.net Mon Jun 3 03:09:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B135E21F8930 for ; Mon, 3 Jun 2013 03:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxubFn1mZXU8 for ; Mon, 3 Jun 2013 03:09:23 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 96DB421F9433 for ; Mon, 3 Jun 2013 03:09:22 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id q19so2192011qeb.4 for ; Mon, 03 Jun 2013 03:09:21 -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=JgUIEebISsHRwB9zkk48JNlP6jOT7XMVK954IAt1ZAg=; b=DWPjYKlC9kNMnEIbvIjtfjqkaNP185uPNmIMXM+Vq6FU/xyBLvGBesjJOD5W65CQu8 dNlqgO9Vkrj/5wL06qviDrnzT4d9aSM0NAd8tCY4YbYIEcDVMClRtPcDWbVa5t3bP9oI oucBPNGlr288fuwiCnlSvXeCLLVQfhkEgsBR1IuKYP9GZ3H+cM1dhFNFXsA0I/IG11jH 6nL5rQlxTfh760s/6YdNotzTIFc7mp5hrHk15NlUO4CrYRt00bUYQKS5bqO8nJOuTO8M cyEoODyQG1tK/xwT3p/MurO7sfopPUGR2mxeVMXmYNOnnSOzk+AdhknJXWuNb56U109X wdBw== X-Received: by 10.49.16.42 with SMTP id c10mr20979343qed.33.1370254161843; Mon, 03 Jun 2013 03:09:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Mon, 3 Jun 2013 03:09:01 -0700 (PDT) In-Reply-To: References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 3 Jun 2013 12:09:01 +0200 Message-ID: To: Mark Rejhon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk/w3/kE+Psgx+xmOXMfSTg+NGee1xaHNfcxZrBdNoKsT8p74qTo6N7NY+Z4CN0Wsy9dd9S Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 10:09:28 -0000 2013/5/31 Mark Rejhon : >> Facebook, Google+, Twitter and any other website use their own custom >> mechanisms for providing chat capabilities to *their own* users >> *between them*. I don't expect that they will be interested in a >> peer-to-peer (user-to-user) realtime text because they want to log the >> messages, inspect them, offer you advertisements based on the content >> of your "private" chats, etc. > > > Objection, objection! > They are NOT mutually exclusive. > > I have been in contact with Facebook as part of my XEP-0301 authorship (X= MPP > real-time text). > See this animated GIF of Facebook real-time text concept: > http://www.realjabber.org/anim/facebook_chat_concept.gif Hi, I said "user-to-user realtime text", and not "char-by-char-user-server-user chat" ;) -- I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Jun 3 03:28:36 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8E621F93F8 for ; Mon, 3 Jun 2013 03:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RM8Scppkpm8Q for ; Mon, 3 Jun 2013 03:28:30 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id D01C721F934B for ; Mon, 3 Jun 2013 03:28:29 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 6so2236324qeb.31 for ; Mon, 03 Jun 2013 03:28: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ZnlmmH+vJYe9dP0nyH6q8FoyMb2RarcqYxmav0sFR0o=; b=LijcPb9Owz4YVlnYwhhA9glsQ89uwJsz/LphYg7Q9DrLbmpjyrbrHNEkIWjV3jNU9s OlPx3E2Zh9wYQt0sRl8v6AdC7o5peqBwfeQqDIOM8zPTMrk3m6s6ZxWWB2OEyS25so0i kRK6JeGj5TeXOipKbqeHTbA96TCKMpCOeT9TB7eqb+qAnFSqNn8rusRLiM4nzx/ULn7s gvd/5yQs/Y4nZPfMh4V1FqLK52Nv4FHPVuHfVR8kD5UbHLF1DsZwnHZlY70hmdOB+02R DODXZfeVYoCLZTWLFIN7fopDViD4QN57etoL3on1Rj/RybB4MoSJRhBqFTQnLd4LNqnX iNRQ== X-Received: by 10.229.149.198 with SMTP id u6mr5789873qcv.20.1370255309133; Mon, 03 Jun 2013 03:28:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Mon, 3 Jun 2013 03:28:09 -0700 (PDT) In-Reply-To: <51A8F3EF.9080702@alum.mit.edu> References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <51A8F3EF.9080702@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 3 Jun 2013 12:28:09 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnTQnbYu8CD5V1HUYBQMoepmvqFUU3AgO/P7AUFOQuo7BhrdfW+aCGr4Ffx9EY+EfHBLcre Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 10:28:36 -0000 2013/5/31 Paul Kyzivat : >> That can be implemented on top of DataChannel anyway, I see no need >> for mandating it as a new RTP media stream negotiated via SDP. > > > IIUC, Gunnar is expecting that virtually every app that provides real tim= e > voice communication should also provide RTT. (And this has a habit of > showing up as a legal mandate.) > > Leaving the decision about how to transport RTT to be reinvented by each > application doesn't seem like a good way to achieve that. Hi Paul. Standarizing the "app layer" in WWW does not work, nobody wants it. What about if somebody (a website) wants to send custom emoticons within the realtime text? should the WG define a "text document format" for RTT? Each website does it in the custom way it likes. Tons of webs offer chat since years, why do we need a standard for it now? A user in website-A will never chat with a user in website-B anyway. > Leaving the decision about how to transport RTT to be reinvented by each > application doesn't seem like a good way to achieve that. The Web has succeeded because each website has the capability of reinventing the application by adding its own innovation and features. Otherwise there would not be so many different social networks or travel websites offereing "the same". > If that is good enough for RTT, then why not voice and video too? Just se= nd > it over a data channel in any format you like. We don't need to standardi= ze > how to do it. JS can not retrieve the audio/video bits received from the peer and convert them into audio/video to be sent to the local multimedia devices. That's why the WG defines a media format (I mean RTP + security) and an API for providing such a multimedia flow to the JS app. The same is not true for text chat which can be achieved in tons of ways in the WWW, without the need of a standard. Regards. -- I=C3=B1aki Baz Castillo From ron.even.tlv@gmail.com Mon Jun 3 03:31:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D3B21F93C4 for ; Mon, 3 Jun 2013 03:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1K8XVV-dknQF for ; Mon, 3 Jun 2013 03:31:09 -0700 (PDT) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3C64321F938E for ; Mon, 3 Jun 2013 03:31:09 -0700 (PDT) Received: by mail-ea0-f179.google.com with SMTP id z16so3269818ead.38 for ; Mon, 03 Jun 2013 03:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=EP5aam1LbgHH5U6U9fB16vDqQuaQB+rylhamkL3kvkM=; b=s234ckd3TsYOkAZj1EJBtK3VYDlomC2FJbga7v6uC9UWqqzgnLgbW7O7ddVEH4p0lf aTWNiIzXlW/fbFfH4V0hWALe5frJ2Rrd7G3TYbWnOcCW/xH5GxlaH7H8tZu8rm5+OqTP dxsdm3ucA+y43wigRBnlvKPXOZfdINFsU5byaB15nmv2ln1Dp2EhotzJ0Y9d/ZFA0Mld haRoPPXFdqZoDLiMTt596q4h2RbpzQ4Td5HXEla97c/UpfdfkBjgPJhyv8XfNUbfaNfH 5Y5Kqts3xYLxuqrqSh++nDFHh59k1+lR+40WGzF/r31olwwE9Xb5pAYc6UtLr1iiH3G1 70mQ== X-Received: by 10.14.149.12 with SMTP id w12mr15372132eej.135.1370255468235; Mon, 03 Jun 2013 03:31:08 -0700 (PDT) Received: from RoniE ([109.64.225.31]) by mx.google.com with ESMTPSA id l6sm83846279eef.12.2013.06.03.03.31.06 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Jun 2013 03:31:07 -0700 (PDT) From: "Roni Even" To: "'Emil Ivov'" , Date: Mon, 3 Jun 2013 13:29:53 +0300 Message-ID: <020e01ce6045$4b07dee0$e1179ca0$@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: Ac5gRUj6/oll8pTVRnuqLmPGNIrG0A== Content-Language: en-us Subject: Re: [rtcweb] No Plan - SDP offer/answer clarification X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 10:31:10 -0000 Hi, I read the draft and the email thread and I think I have similar questions to the ones Cullen made. My understanding was that the proposal is to do one SDP offer/ answer exchange and add remove streams using other means (not specified) I looked at the offer example is section 3 and it has a=max-send-ssrc:{*:1} // declaring maximum a=max-recv-ssrc:{*:4} // number of SSRCs I have some clarifying questions? 1. Is the proposal to always offer max-send-ssrc=1? 2. What is the answer in this case can it be max-send-ssrc=4? 3. If max-send-ssrc >1 in the answer and the m-line has, for example, support for H.264 and VP8 with max-send-ssrc=2 and de-multiplexing is based on pt number, it will require four pt in the m-line since there can be two VP8 or two H.264 RTP streams m=video 5002 RTP/SAVPF 97 98 99 100 a=mid:video a=rtcp-mux a=rtpmap:97 VP8/90000 a=rtpmap:98 VP8/90000 a=rtpmap:99 H264/90000 a=rtpmap:100 H264/90000 Is my understanding correct? Roni > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Emil Ivov > Sent: 29 May, 2013 10:00 PM > To: rtcweb@ietf.org > Subject: [rtcweb] No Plan > > Hey all, > > Based on many of the discussions that we've had here, as well as many > others that we've had offlist, it seemed like a good idea to investigate a > negotiation alternative that relies on SDP and Offer/Answer just a little bit > less. > > The following "no plan" draft attempts to present one such approach: > > http://tools.ietf.org/html/draft-ivov-rtcweb-noplan > > The draft relies on conventional use of SDP O/A but leaves the intricacies of > multi-source scenarios to application-specific signalling, with potentially a > little help from RTP. > > Hopefully, proponents of Plans A and B would find that the interoperability > requirements that concerned them can still be met with "no plan". Of course > they would have to be addressed by application-specific signalling and/or > signalling gateways. > > Comments are welcome! > > Cheers, > Emil > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From emil@sip-communicator.org Mon Jun 3 03:46:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515C721F93D2 for ; Mon, 3 Jun 2013 03:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYS-1OLeQRu0 for ; Mon, 3 Jun 2013 03:46:09 -0700 (PDT) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6FB21F8F2F for ; Mon, 3 Jun 2013 03:46:08 -0700 (PDT) Received: by mail-bk0-f43.google.com with SMTP id jm19so780161bkc.16 for ; Mon, 03 Jun 2013 03:46:08 -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=Oj+v4tWMlIaYJS3vFJtSVkrxrphnnOA8oH1tfbt8QuE=; b=fj/lKV8jqdEKbp5BNtlCXu/gWY/x/LLe3JzbnDdjrsE7AeJUcZ7HI3oBEHhE/sWjuk MCuNPUyJ77nnAbIVRUnHCCor8Ge3BLZLIzfk4SF+ta2p5eXUj2a+fJKk2S8LTW9W0n0q oXQg2S6Q0q1jTT8/hKSqt6Vn/dGjKtKpW7VF03HB8G6QIJQ+dLnxX5D0J1uXAHQpZL1o 1C3WmLxZTbbM4N3L/mfbybG11wPBaLZ820QQZQGCJh7jh48h0VsYWcgC+SZaHiLiXFJY dnPVgCVin2g800HEGH6wZ24tz/3IcR2+zSe/jz/mKPggHYJDKlDLvH6JJHnOFGdb4fvH z0YQ== X-Received: by 10.205.128.204 with SMTP id hf12mr6189594bkc.30.1370256367901; Mon, 03 Jun 2013 03:46:07 -0700 (PDT) Received: from [192.168.1.118] ([88.203.232.9]) by mx.google.com with ESMTPSA id rj5sm18919543bkb.1.2013.06.03.03.46.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 03:46:06 -0700 (PDT) Message-ID: <51AC73EE.5080603@jitsi.org> Date: Mon, 03 Jun 2013 13:46:06 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Roni Even References: <020e01ce6045$4b07dee0$e1179ca0$@gmail.com> In-Reply-To: <020e01ce6045$4b07dee0$e1179ca0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkFdTdmmq920Q+oQnJgjDSVnIOCpkPsAWPLXfs0gS9RtKrDDlJonP5L2YB2GGX/eSl5cMPQ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan - SDP offer/answer clarification X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 10:46:10 -0000 Hey Roni, On 03.06.13, 13:29, Roni Even wrote: > Hi, > I read the draft and the email thread and I think I have similar questions > to the ones Cullen made. > My understanding was that the proposal is to do one SDP offer/ answer > exchange and add remove streams using other means (not specified) Yes, this is exactly it. > I looked at the offer example is section 3 and it has > > a=max-send-ssrc:{*:1} // declaring maximum > a=max-recv-ssrc:{*:4} // number of SSRCs > > I have some clarifying questions? > > 1. Is the proposal to always offer max-send-ssrc=1? > > 2. What is the answer in this case can it be max-send-ssrc=4? The max-ssrc in the SDP was just an example for capabilities that the offerer could add to SDP (could be useful for mobile devices for example). It is by no means essential to the approach. > 3. If max-send-ssrc >1 in the answer and the m-line has, for example, > support for H.264 and VP8 with max-send-ssrc=2 and de-multiplexing is based > on pt number, it will require four pt in the m-line since there can be two > VP8 or two H.264 RTP streams > > m=video 5002 RTP/SAVPF 97 98 99 100 > a=mid:video > a=rtcp-mux > a=rtpmap:97 VP8/90000 > a=rtpmap:98 VP8/90000 > a=rtpmap:99 H264/90000 > a=rtpmap:100 H264/90000 > Is my understanding correct? Can you help me understand why you need the PT duplication? Is this just so that you could understand distinguish between two sources? If so, then it wouldn't be necessary. With No Plan you would just send: m=video 5002 RTP/SAVPF 97 99 a=mid:video a=rtcp-mux a=rtpmap:97 VP8/90000 a=rtpmap:99 H264/90000 If then you want to have one of the VP8 streams rendered on the left screen and the other on the right, you will add this in application-specific signalling. A web application could do this like this: { "leftSSRC": "1234", "rightSSRC": "5678" } An WebRTC-to-SIP gateway could transform this into SDP or whatever that target devices need. Does this answer your question? Emil > > > Roni > > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Emil Ivov >> Sent: 29 May, 2013 10:00 PM >> To: rtcweb@ietf.org >> Subject: [rtcweb] No Plan >> >> Hey all, >> >> Based on many of the discussions that we've had here, as well as many >> others that we've had offlist, it seemed like a good idea to investigate a >> negotiation alternative that relies on SDP and Offer/Answer just a little > bit >> less. >> >> The following "no plan" draft attempts to present one such approach: >> >> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >> >> The draft relies on conventional use of SDP O/A but leaves the intricacies > of >> multi-source scenarios to application-specific signalling, with > potentially a >> little help from RTP. >> >> Hopefully, proponents of Plans A and B would find that the > interoperability >> requirements that concerned them can still be met with "no plan". Of > course >> they would have to be addressed by application-specific signalling and/or >> signalling gateways. >> >> Comments are welcome! >> >> Cheers, >> Emil >> >> -- >> https://jitsi.org >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > -- https://jitsi.org From gunnar.hellstrom@omnitor.se Mon Jun 3 04:26:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D16121F8F2F for ; Mon, 3 Jun 2013 04:26:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H27u2dJBikFE for ; Mon, 3 Jun 2013 04:26:48 -0700 (PDT) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id E9AB121F9424 for ; Mon, 3 Jun 2013 04:26:47 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 3 Jun 2013 13:26:06 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id B74543A1F5 for ; Mon, 3 Jun 2013 13:26:06 +0200 (CEST) Message-ID: <51AC7D4F.6090708@omnitor.se> Date: Mon, 03 Jun 2013 13:26:07 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <51A8F3EF.9080702@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] RTT (was :No Plan ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 11:26:54 -0000 On 2013-06-03 12:28, Iñaki Baz Castillo wrote: > Tons of webs offer chat since years, why do we need a standard for it > now? A user in website-A will never chat with a user in website-B > anyway. As I see it, RTCWEB has a goal to enable audio, video and data communication between a user in Website-A and a user in Website-B. Sometimes I have seen in the discussion that we shall not build silos again. To me, that means create and use standards for the features of common interest. Video, real-time text and audio are the three real-time media of common interest. All three are possible to transport as you like, but the RTCWEB activity is about making it in a similar way to enable interoperability and ease inclusion in web applications. Even the isolated web designer who makes the dedicated site only offering communication between users of that site and the customer service will be glad to find common ways to include the three real-time communication modalities as components rather than being forced to invent everything again. And users will be happy to find that it works in similar ways in different sites. ( just as you are happy to find the gas pedal located in the same place in every car ) There are more reasons why standards are good for this purpose, but I stop here. We had a discussion in November - January. It just popped up again because of how interop plans with SIP were expressed in the "No Plan". And it was not the "No Plan" itself that was limiting, it was rather the way the need for legacy interop was described in the No Plan draft. My conclusion is again: whatever transport we select for Real-Time Text in the WebRTC environment, there is a need to standardize it. /Gunnar From ibc@aliax.net Mon Jun 3 04:38:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0096F21F962D for ; Mon, 3 Jun 2013 04:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFFPEkEQU3rv for ; Mon, 3 Jun 2013 04:38:38 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 75DFD21F9485 for ; Mon, 3 Jun 2013 04:38:38 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id i13so1727548qae.17 for ; Mon, 03 Jun 2013 04:38:38 -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=vAuHROhi+P2p2vVHHKFa7qIt0ZWWnH80qHeP20bTvk0=; b=NoDtmeUkwC5+uXEEU6uf9MmG2MnjA78qAJQ4xPLyWsLWPEptm6Gt0q+tKsBxZLhhSF fuV6qVKcLu02/ZsPXmF2Nhro+cCK6ERDAU1Ge0reX2lQfQUT3DlbJIiHj/ksIJwVy9hs Mn8EMStUaoUPWItfvaMxNcyZSvyts33LqtGLjOogyzX6BAYLOinlpzJUeYsuRWh0E9dU YU8k4/JQ/BbDyBcFWN+IPdMTK6dAPQrkMt+kX/16jpVc3r/hwGMivMIT7yiYAxtBZ1ZF 7TEprM3/G8MvVnwvVNNv15fAJ4qYUzrC9rfH9dmzD1XUujvkFiLp3CP5M/N4P+ztzEKF KkUA== X-Received: by 10.224.146.66 with SMTP id g2mr18630093qav.50.1370259517909; Mon, 03 Jun 2013 04:38:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Mon, 3 Jun 2013 04:38:17 -0700 (PDT) In-Reply-To: <51AC7D4F.6090708@omnitor.se> References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <51A8F3EF.9080702@alum.mit.edu> <51AC7D4F.6090708@omnitor.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 3 Jun 2013 13:38:17 +0200 Message-ID: To: Gunnar Hellstrom Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkjGGbyvsoc6dTf6rb66O+EW02UEnDC1lr9GPwwO9gItRS/J6UUchFC7N0/pBbpRBOGV76d Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTT (was :No Plan ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 11:38:39 -0000 2013/6/3 Gunnar Hellstrom : > As I see it, RTCWEB has a goal to enable audio, video and data communicat= ion > between a user in Website-A and a user in Website-B. I strongly disagree. A WG won't change what the WWW wants, ant the WWW has shown us, during years, a way of communication without real interaction between different websites. Specifically users logged into site-A don't directly interact with users logged into site-B, instead site-A embed a JS code of site-B into the web, so users of site-B can use site-B features (*same* JS app client in both users). > My conclusion is again: whatever transport we select for Real-Time Text i= n > the WebRTC environment, there is a need to standardize it. My opinion is that we don't need a Real-Time Text specification in WebRTC at all. We have DataChannel which means "realtime data", and such a data can be text, images, binary content or whatever the website wants to offer. Regards. -- I=C3=B1aki Baz Castillo From btdingle@gmail.com Mon Jun 3 04:52:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CF421F9294 for ; Mon, 3 Jun 2013 04:52:05 -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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPzYv9BCW998 for ; Mon, 3 Jun 2013 04:52:04 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 21B4821F8F6E for ; Mon, 3 Jun 2013 04:52:03 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hi5so2585632wib.6 for ; Mon, 03 Jun 2013 04:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+QhIpBCGKYGWk5c2IRflCi5eInIHAHtf8XzAkhTBI/w=; b=iTDeZcsT6U76mt6w10tUYZcEdJpHdJxxOwEJSzA7wnKedngo2boTqkjxPHNozjIWcx JKhbTS+yl5QVdYQo12a3gVz54c6IXkIl3lOapI+jlKwaw0tHx8LplRi7bItlhc3vhpmo XvVGBEefE9hMSaEqjriMDiR5ZHmxKgIQK0v42k0c+9INrOSNMQtm28+2rammgbsy6xGR xkKRLY8diEoWraVu7sfSdHQWAsgMy/U0Yqi6Q1g9quSzhtMLR2Zo2qptzsib22TGGXEF G2NWbsZj9Athw+c2EUTJpXoh6jA/qU55vdTVH+Pt4REvcw9uoK/9hMLweLZq4sP9QH1R yROQ== X-Received: by 10.194.6.9 with SMTP id w9mr18492427wjw.32.1370260323301; Mon, 03 Jun 2013 04:52:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.61.42 with HTTP; Mon, 3 Jun 2013 04:51:43 -0700 (PDT) In-Reply-To: References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <51A8F3EF.9080702@alum.mit.edu> <51AC7D4F.6090708@omnitor.se> From: Barry Dingle Date: Mon, 3 Jun 2013 21:51:43 +1000 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b450966d1fff304de3e9714 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTT (was :No Plan ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 11:52:07 -0000 --047d7b450966d1fff304de3e9714 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Real-time voice and real-time video need to agree on encode/decode rules and transport. Real-time text requires the same. Using your rationale Inaki, then we don't need to standardise RT voice and RT video - so WebRTC/rtcWeb is a waste of time!! Or do you see RT Text as something different to RT Voice and RT Video? Cheers, /Barry Dingle On Mon, Jun 3, 2013 at 9:38 PM, I=C3=B1aki Baz Castillo wro= te: > 2013/6/3 Gunnar Hellstrom : > > As I see it, RTCWEB has a goal to enable audio, video and data > communication > > between a user in Website-A and a user in Website-B. > > I strongly disagree. A WG won't change what the WWW wants, ant the WWW > has shown us, during years, a way of communication without real > interaction between different websites. Specifically users logged into > site-A don't directly interact with users logged into site-B, instead > site-A embed a JS code of site-B into the web, so users of site-B can > use site-B features (*same* JS app client in both users). > > > > My conclusion is again: whatever transport we select for Real-Time Text > in > > the WebRTC environment, there is a need to standardize it. > > My opinion is that we don't need a Real-Time Text specification in > WebRTC at all. We have DataChannel which means "realtime data", and > such a data can be text, images, binary content or whatever the > website wants to offer. > > > Regards. > > > > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b450966d1fff304de3e9714 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Real-time voice and real-time video need to= agree on encode/decode rules and transport.

Real-time text r= equires the same.

Using your rationale Inaki, then we don'= ;t need to standardise RT voice and RT video - so WebRTC/rtcWeb is a waste = of time!!

Or do you see RT Text as something different to RT Voice and RT V= ideo?

Cheers,
/Barr= y Dingle



On Mon, Jun 3, 2013 at 9:38 PM, I=C3=B1a= ki Baz Castillo <ibc@aliax.net> wrote:
2013/6/3 Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>:
> As I see it, RTCWEB has a goal to enable audio, vide= o and data communication
> between a user in Website-A and a user in Website-B.

I strongly disagree. A WG won't change what the WWW wants, ant th= e WWW
has shown us, during years, a way of communication without real
interaction between different websites. Specifically users logged into
site-A don't directly interact with users logged into site-B, instead site-A embed a JS code of site-B into the web, so users of site-B can
use site-B features (*same* JS app client in both users).


> My conclusion is again: whatever transport we select for Real-Time Tex= t in
> the WebRTC environment, there is a need to standardize it.

My opinion is that we don't need a Real-Time Text specification i= n
WebRTC at all. We have DataChannel which means "realtime data", a= nd
such a data can be text, images, binary content or whatever the
website wants to offer.


Regards.



--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
___________________________________= ____________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7b450966d1fff304de3e9714-- From gunnar.hellstrom@omnitor.se Mon Jun 3 05:00:21 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E1121F86F5 for ; Mon, 3 Jun 2013 05:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AinAsjv8IKR1 for ; Mon, 3 Jun 2013 05:00:14 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id C02F821F8CB5 for ; Mon, 3 Jun 2013 05:00:13 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Mon, 3 Jun 2013 14:00:06 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 3E6043A0F7; Mon, 3 Jun 2013 14:00:06 +0200 (CEST) Message-ID: <51AC8547.1060400@omnitor.se> Date: Mon, 03 Jun 2013 14:00:07 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <51A8F3EF.9080702@alum.mit.edu> <51AC7D4F.6090708@omnitor.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060809020905030001060507" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTT (was :No Plan ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:00:21 -0000 This is a multi-part message in MIME format. --------------060809020905030001060507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2013-06-03 13:38, Iñaki Baz Castillo wrote: > 2013/6/3 Gunnar Hellstrom: >> >As I see it, RTCWEB has a goal to enable audio, video and data communication >> >between a user in Website-A and a user in Website-B. > I strongly disagree. A WG won't change what the WWW wants, ant the WWW > has shown us, during years, a way of communication without real > interaction between different websites. Specifically users logged into > site-A don't directly interact with users logged into site-B, instead > site-A embed a JS code of site-B into the web, so users of site-B can > use site-B features (*same* JS app client in both users). > > Iñaki, I disagree. The use cases draft includes a case titled: 4.2.10 . Simple video communication service with inter-operator calling See: http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10#page-9 With RTCWEB, the web takes the step towards inter-provider-communication. I think that is one big reason why so much interest is shown to RTCWEB and WebRTC. /Gunnar --------------060809020905030001060507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 2013-06-03 13:38, Iñaki Baz Castillo wrote:
2013/6/3 Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>:

> As I see it, RTCWEB has a goal to enable audio, video and data communication
> between a user in Website-A and a user in Website-B.

I strongly disagree. A WG won't change what the WWW wants, ant the WWW
has shown us, during years, a way of communication without real
interaction between different websites. Specifically users logged into
site-A don't directly interact with users logged into site-B, instead
site-A embed a JS code of site-B into the web, so users of site-B can
use site-B features (*same* JS app client in both users).
Iñaki,
I disagree.

The use cases draft includes a case titled:

4.2.10.  Simple video communication service with inter-operator calling
See: http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10#page-9

With RTCWEB, the web takes the step towards inter-provider-communication. I think that is one big reason why so much interest is shown to RTCWEB and WebRTC.

/Gunnar
--------------060809020905030001060507-- From ibc@aliax.net Mon Jun 3 05:10:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973AF21F9473 for ; Mon, 3 Jun 2013 05:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbt12iiESBy4 for ; Mon, 3 Jun 2013 05:10:33 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id E2A1721F92FC for ; Mon, 3 Jun 2013 05:10:32 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id n1so2092869qcw.13 for ; Mon, 03 Jun 2013 05:10:32 -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=mds2RNuyPolOiJEQ8umK/e2SrQDyPSuTRmE4AdRjbiI=; b=QJfwvEwhWMjcrINZD/cFOya5PufZVMdynZaTaYBsQBRUM3gILLY6EbQ+9489MBaaiZ in+DXI62QzFA5cfaVix+fY1a1OT4mfb48AAPgbW7R3y13872/hnxKhbLERLFVMNCQ2mb wJwH7rmw06loMTrs+7esIMjiJ3/IzqoQIqMuHZjlEtyGu0CiWkFTHIWkZVv2a3P5LmdE iG5shEaHDAQ32vWrvrD+JLHYkZowPzk3iXm/aK7i2u8+FHcdMzar4fDkEVQTeH1/wGFZ BlMqU+5zchvaeNqYjwQZ14tpHQnlNSZPRZVmNUW1cpsDdYxIl3YZFnWi98qMw6UUnpKI gI6w== X-Received: by 10.229.149.198 with SMTP id u6mr5919545qcv.20.1370261432307; Mon, 03 Jun 2013 05:10:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Mon, 3 Jun 2013 05:10:12 -0700 (PDT) In-Reply-To: References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <51A8F3EF.9080702@alum.mit.edu> <51AC7D4F.6090708@omnitor.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 3 Jun 2013 14:10:12 +0200 Message-ID: To: Barry Dingle Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkMOLLYLLGu2d1y/EhI2wyktsCVxhgpnzJaIcWr7CZ9adt2o/BuDPY9oB/yLa2VgraioL25 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTT (was :No Plan ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:10:33 -0000 2013/6/3 Barry Dingle : > Real-time voice and real-time video need to agree on encode/decode rules = and > transport. > > Real-time text requires the same. > > Using your rationale Inaki, then we don't need to standardise RT voice an= d > RT video - so WebRTC/rtcWeb is a waste of time!! I can tell you 100 ways for sending/receiving Real-time Text using existing technology in browsers. Can you tell me how a browser can send and receive RT audio/video without proprietary plugins? If there is no way then we agree that WebRTC spec is needed for providing those capabilities to browsers, but the same is not true for text. > Or do you see RT Text as something different to RT Voice and RT Video? Regardles RT Text is useful or not (it can be for some scenarios) it can *already* be implemented over the standarized DataChannel (in which the custom JS app can send/receive text, images, binary content or whatever in realtime). No need at all to create a new RTP media type. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Jun 3 05:14:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119EF21F9622 for ; Mon, 3 Jun 2013 05:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZV2A+LHdXWES for ; Mon, 3 Jun 2013 05:14:32 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 76C7E21F95DD for ; Mon, 3 Jun 2013 05:14:32 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id hu16so1768304qab.10 for ; Mon, 03 Jun 2013 05:14:31 -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=JK2+qiCSeSNSw8safNhLAKtWuI8MCDYKFjUPp1D6Lrw=; b=MmQ6Vvt5P/s4O3UzEyVIqiHGHwmC5D7VTssDzGfz96a1vX0BJ99ZNss4bbdZuh6sUx xIB3Ne60+rVzGSTOHqK5jz9NEMjVO7AnylUOoGuAFSONVdvm+WbFPHVWmUaL6HviYaxg 7pMhWZ6kFtgDCR1Y3sW1csQkyLPvVdOamqHeh/9Q98h9bBjIO0HkfNxBayP+PpG/46wM Zdk1oX0Em/QUZdLmqjpO/v4Cg8GhYKkB6TsEtMctQrGHmKyl+XzXz4z7z9WGDtqR9rKx KhK4UaxiN/xdKQuClZiPPowHU6XbvqW67G/B9umiwc0H6bztaK9p3oNWGQVKofRqQyOb FfHA== X-Received: by 10.49.0.244 with SMTP id 20mr21613428qeh.50.1370261671738; Mon, 03 Jun 2013 05:14:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Mon, 3 Jun 2013 05:14:11 -0700 (PDT) In-Reply-To: <51AC8547.1060400@omnitor.se> References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <51A8F3EF.9080702@alum.mit.edu> <51AC7D4F.6090708@omnitor.se> <51AC8547.1060400@omnitor.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 3 Jun 2013 14:14:11 +0200 Message-ID: To: Gunnar Hellstrom Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm6KlvuGfSB3yBmLLrkHpd/YT7dmUFF9hbkKlktVvSLLl4WE46sUp9VVmNGzia5cBrZy7eY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTT (was :No Plan ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:14:33 -0000 2013/6/3 Gunnar Hellstrom : > The use cases draft includes a case titled: > > 4.2.10. Simple video communication service with inter-operator calling > > See: > http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-1= 0#page-9 That will just work if both websites want to offer such a inter-website-communication. And that's already feasible. But we don't need a new standard (RTT-over-RTP) for allowing two users in different websites to intercommunicate via RTT. That can be achieved in multiple ways with existing technology (WebSocket, DataChannel) but, still, both websites must allow it. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Jun 3 05:51:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421C721F9698 for ; Mon, 3 Jun 2013 05:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IBrehDgx+Xb for ; Mon, 3 Jun 2013 05:51:37 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D8F0221F947C for ; Mon, 3 Jun 2013 05:51:36 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id bs12so1783278qab.15 for ; Mon, 03 Jun 2013 05:51:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=rt3wmyPEMh9Kzkpb1K+BN+6UCyci+wam5mqfRaZhVNA=; b=I90PuDwxRIKTdauHG7CpI3Bv/6m2qXcu2jkT6HrmveD8yz57LVJ1bj2lxC0P0uNRUo o08n/KXt9Iosne9KZMJleH83ReYZyVJUNtPGNXPOjhVmXUTYYvaM3JQryCmc9CYOnZZr +l+D8PRTZ3871oqFghh4UcHYcHkw9Cz4BveY6Wr++AF2CrvoP+++Wuuz+x5dCd2q1huM 1ICtenBno1igGAQ0vSP/nbEibiqaoy0JHLol79SffPxJSawotlLV5XhDvExTSC2p9kAz cN9ygF0aL8cGMHCQchnCsNHy6bIJ8YNf1qwJXWAIhEKRK6v+O2NUt1z8qB6k1g0lviga 5UQg== X-Received: by 10.229.124.80 with SMTP id t16mr4204129qcr.93.1370263896039; Mon, 03 Jun 2013 05:51:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Mon, 3 Jun 2013 05:51:15 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 3 Jun 2013 14:51:15 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkqYe/HAOlJTo0fVt6boy1SgnYU/HJ+GfkqIJjE8EbG1WDidmQdpDHMgLI2C2BAf4a6ajzu Subject: [rtcweb] My considerations about "inter-website-communication", RTT and emergency services X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:51:38 -0000 Hi, Currently interaction between users of different websites is achieved via widgets and/or oAuth. JS codes provided by different websites typically don't directly interact. Alice can give a comment into a Wordpress blog by signing with her Facebook account, but the JS code she uses for leaving such a comment is provided by the blog. There is not an "inter-blogging standard protocol". WebRTC is like Youtube, but instead of user-to-server it provides user-to-user RT communication. A user logged into Youtube cannot directly access to a video published in Vimeo, right? A webpage can include a Youtube video, but for that it must include a JS/HTML code provided by Youtube site. The same for WebRTC. Let's assume that website-B will provide some JS widget that can be embedded in any webpage (i.e. a "call me" button) so the web visitor in website-A can click on it and establish a WebRTC audio/video session with somebody (Bob) in website-B. The important consideration here is that the JS app is provided by the website of the called party, and the RT session established between Alice and Bob makes use of JS code and server(s) provided by a single website/domain (website-B). So when I constantly read about "inter-operator RT communication" I wonder, do we really know how the WWW works and what the WWW wants and needs? If we talk about RealTime-Text, there are tons of ways it can be achieved with existing browser technologies (including the new DataChannel). Assuming the WWW-"federation"-style explained above, RTT between different websites can be already implemented, and the same for usual-chat. But it's not implemented in that way (two users logged into different websites can not chat one to each other because websites don't want to offer such a feature). This is, it can already be done, but it's not done. Adding a new standard specification (just covering the realtime text part) will change nothing. It's up to websites to allow it. And since "emergency services" seem to be the last argument for all, I wonder whether we expect that a web visitor in a RealTime audio/video poker game should be able to make an audio call to 112 emergency number from the poker website. If the answer is not (and it should be "not") I expect that the "emergency services" argument is avoided from now because it is a show-stopper which hast zero relationship with the WWW. Emergency services will be able to provide their own website or JS widget that other websites could embed into their webs. Those emergency websites will deploy the servers and the logic they require to interact, at audio/video/text/fax/sms/whatever levels, with the RT signaling protocols they use in the "leg B" of the session with their existing legacy communication systems. My two cents. -- I=C3=B1aki Baz Castillo From gunnar.hellstrom@omnitor.se Mon Jun 3 06:37:20 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9705C21F9843 for ; Mon, 3 Jun 2013 06:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMRGC7T8E4xg for ; Mon, 3 Jun 2013 06:37:09 -0700 (PDT) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 1367921F882A for ; Mon, 3 Jun 2013 06:37:08 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP; Mon, 3 Jun 2013 15:36:30 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id 8838C3A1BC; Mon, 3 Jun 2013 15:36:30 +0200 (CEST) Message-ID: <51AC9BDF.2050404@omnitor.se> Date: Mon, 03 Jun 2013 15:36:31 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <51A8F3EF.9080702@alum.mit.edu> <51AC7D4F.6090708@omnitor.se> <51AC8547.1060400@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTT (was :No Plan ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 13:37:20 -0000 On 2013-06-03 14:14, Iñaki Baz Castillo wrote: > 2013/6/3 Gunnar Hellstrom : >> The use cases draft includes a case titled: >> >> 4.2.10. Simple video communication service with inter-operator calling >> >> See: >> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10#page-9 > That will just work if both websites want to offer such a > inter-website-communication. And that's already feasible. But we don't > need a new standard (RTT-over-RTP) for allowing two users in different > websites to intercommunicate via RTT. That can be achieved in multiple > ways with existing technology (WebSocket, DataChannel) but, still, > both websites must allow it. The inter - operator communication is also described in the overview: http://tools.ietf.org/html/draft-ietf-rtcweb-overview-06#section-3 It is because it can be done in multiple ways that we need a standard for it. And a standard that combines audio, video and real-time text in the same session. Outside of that it is of course valuable to have 1000 other ways to do it. But that does not reduce the need for a standard. /Gunnar > > > -- > Iñaki Baz Castillo > From ibc@aliax.net Mon Jun 3 08:41:36 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3600E21F9985 for ; Mon, 3 Jun 2013 08:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KciGm+612dE for ; Mon, 3 Jun 2013 08:41:32 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 01D6F21F8693 for ; Mon, 3 Jun 2013 08:41:31 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id 1so496154qec.34 for ; Mon, 03 Jun 2013 08:41:31 -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=v8Ui+9dDhBp0wmBTGIv8313v0TcPh2fJtK45MNbSm44=; b=ZtUQjrz8E9XAnuNQCXgrbtXH6ie+6qbowF5DynaRSphcMyXDFg8qT3YN8fwSTAkdOn 9l9kHt78asnkhR/dpx7+ncUKz2Y/JQ3i6fZ5uIX++FZ2u9bONKFmLr8nOrHQlD605pCl Uaz2EIFrL1pug8lAuDjv50yI3eRsTRN6yiqS2kEcQS4W16j2GE+PtusszfNhgv5h1cEg 3JISy0IwaYHt6cAZGMpm2U82InVwjZF54Y00Rxi/dT6OhR8q0SiBJ66in1AWeO22aEzb U8v4D3NIMBehyI124ShePegnVB+3v9LPqqcryaym8JXwEEgKE7h+aPZ9YgKtib5MW5gl AoqA== X-Received: by 10.229.106.20 with SMTP id v20mr8017834qco.129.1370274091111; Mon, 03 Jun 2013 08:41:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Mon, 3 Jun 2013 08:41:10 -0700 (PDT) In-Reply-To: <51AC9BDF.2050404@omnitor.se> References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <51A8F3EF.9080702@alum.mit.edu> <51AC7D4F.6090708@omnitor.se> <51AC8547.1060400@omnitor.se> <51AC9BDF.2050404@omnitor.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 3 Jun 2013 17:41:10 +0200 Message-ID: To: Gunnar Hellstrom Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmoD3Mc7vMopAZnY7u16ueIzF3NsjX8+Bef3YRwXB7ecXpQveBE8sZyQj99M3K3w7Sa0uME Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTT (was :No Plan ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 15:41:36 -0000 2013/6/3 Gunnar Hellstrom : > The inter - operator communication is also described in the overview: > http://tools.ietf.org/html/draft-ietf-rtcweb-overview-06#section-3 > > It is because it can be done in multiple ways that we need a standard for > it. And a standard that combines audio, video and real-time text in the s= ame > session. > > Outside of that it is of course valuable to have 1000 other ways to do it= . > But that does not reduce the need for a standard. There are tons of ways of implementing chat or RTT in current websites, but no one of them implements RT chat with users of a different website. A WG standard will not change this reality and the lack of interest. Said that, "SDP m=3Dtext" would just become an uneeded and unrequested complexity. -- I=C3=B1aki Baz Castillo From emil@sip-communicator.org Mon Jun 3 10:32:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C500A21F8FDC for ; Mon, 3 Jun 2013 10:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyZq48LxzuJ7 for ; Mon, 3 Jun 2013 10:32:04 -0700 (PDT) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id ADBFE21F86CB for ; Mon, 3 Jun 2013 10:28:08 -0700 (PDT) Received: by mail-bk0-f41.google.com with SMTP id jc3so344762bkc.14 for ; Mon, 03 Jun 2013 10:28: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=rP5XCiMJqG+udECwgBPaJ6/qBjrOMjz1sRwRdRTtj2c=; b=KsqGHWIiI0Rlx3h7Wj+/shDmEIbKHudbaeQStpF4bOkd+hOgLsQvFS+HqHoqT6SVpM a/6a28bDxKL+IHaLGiKZOtlvUObNzwp3tzzVX0ZS+sxe+4cu5Ms4MYIdEBjEeKksAPuC lh+irv1mXtaQHYjwTI11+CA0/UffeZuQZi1qsNWHwXNXAyX2u1/nG78ApQVkRk0B39Mc wKvqBphC4kIU9b4ZGMsGboEkX0Gkd6Q5U1sB9p8K8HQ3DU6eF4FuM5mz5dF/eCoxbdaZ 13edoOLmecDzLm+clvXLLaP8t9NrVX028CmugIl6Nn17CFcwcoUBvCZCazq1ixQM7Brz LHNg== X-Received: by 10.204.183.16 with SMTP id ce16mr6685598bkb.91.1370280487221; Mon, 03 Jun 2013 10:28:07 -0700 (PDT) Received: from [192.168.1.118] ([88.203.232.9]) by mx.google.com with ESMTPSA id cm9sm20727477bkb.4.2013.06.03.10.28.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 10:28:06 -0700 (PDT) Message-ID: <51ACD224.8080100@jitsi.org> Date: Mon, 03 Jun 2013 20:28:04 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm5BxDLKP/IXtjCU/pi24NrsyfNBe4gB/XcSsSZ1+GZwXvWb71vW+kzJC5CDxKuzmtWoQ8d Cc: "rtcweb@ietf.org" Subject: [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 17:32:14 -0000 Hey Cullen, Paul, all On 31.05.13, 22:19, Cullen Jennings (fluffy) wrote: > On 31.05.2013, at 12:23 PM, Emil Ivov wrote: > >> Certainly. Could you please post the SDP that you would like to see >> translated in a way that's compatible with "No Plan"? >> >> Emil > > We can start with the SDP in plan A The example in "7.3. Many Videos" looks like a good start: http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00#section-7.3 Here it is: v=0 o=- 20518 0 IN IP4 198.51.100.1 s= t=0 0 c=IN IP4 203.0.113.1 a=ice-ufrag:F7gI a=ice-pwd:x9cml/YzichV2+XlhiMu8g a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7 a=group:BUNDLE m0 m1 m2 m3 m=audio 56600 RTP/SAVPF 0 96 a=mid:m0 a=rtpmap:0 PCMU/8000 a=rtpmap:96 opus/48000 a=ptime:20 a=sendrecv a=rtcp-mux [ICE Candidates] m=video 0 RTP/SAVPF 97 98 a=mid:m1 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 a=rtpmap:98 VP8/90000 a=sendrecv a=rtcp-mux a=bundle-only a=ssrc:11111 cname:45:5f:fe:cb:81:e9 m=video 0 RTP/SAVPF 97 98 a=mid:m2 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 a=rtpmap:98 VP8/90000 a=sendrecv a=rtcp-mux a=bundle-only a=ssrc:22222 cname:45:5f:fe:cb:81:e9 m=video 0 RTP/SAVPF 97 98 a=mid:m3 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 a=rtpmap:98 VP8/90000 a=sendrecv a=rtcp-mux a=bundle-only a=ssrc:333333 cname:45:5f:fe:cb:81:e9 An offer generated by a "No Plan" browser in this case would look something like this: v=0 o=- 20518 0 IN IP4 198.51.100.1 s= t=0 0 c=IN IP4 203.0.113.1 a=ice-ufrag:F7gI a=ice-pwd:x9cml/YzichV2+XlhiMu8g a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7 a=group:BUNDLE m0 m1 m=audio 56600 RTP/SAVPF 96 0 a=mid:m0 a=rtpmap:96 opus/48000 a=rtpmap:0 PCMU/8000 a=ptime:20 a=sendrecv a=rtcp-mux [ICE candidates] m=video 56602 RTP/SAVPF 97 98 a=mid:m1 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 a=rtpmap:98 VP8/90000 a=sendrecv a=rtcp-mux [ICE candidates] I. Talking to legacy In case you need to talk to an actual legacy (as in widely deployed SIP) endpoint, the above would translate into a regular two-stream call. Both Plan A and No Plan would lead to essentially the same result (if we accept that older endpoints won't throw an exception at the sight of 4 m= lines) so not much to discuss here. II. Talking to Plan A style endpoints If you need to talk to a Plan A endpoint you basically have the following options: 1. You use JavaScript to prettify the "No Plan" SDP and turn it into something that looks like "Plan A". Not my favourite option, but I am sure some would like to use it. Maybe vendors of Plan A equipment would even distribute JS libs that do this. It would basically all come down to generating one ssrc attribute and two additional m=lines and appending this to the existing SDP string. 2. The application retrieves SSRCs from the browser, adds additional application-specific signalling to it and then sends the whole thing to a signalling gateway. The gateway (which you would also have with Plan A) would convert the SDP into what it needs it to be. The application specific signalling can look like this: { "firstStream": { "SSRC": "11111", "CNAME": "45:5f:fe:cb:81:e9" }, "secondStream": { "SSRC": "22222", "CNAME": "45:5f:fe:cb:81:e9" }, "thirdStream": { "SSRC": "333333", "CNAME": "45:5f:fe:cb:81:e9" }, } 3. In Plan B, section 3.1 talks about generating "Plan A" style SDP with the help of .content properties. If browser vendors are willing to implement support for this then I suppose it would be a third option. III. Talking to other WebRTC applications This is the fun case and the one we should be most concerned with. Let's imagine that the answerer needs to add a fourth video stream. To make this work endpoints would need to do the following: a) with Plan A and draft-roach-rtcweb-glareless-add: - send application specific signalling to the offerer - have a new O/A exchange b) with Plan A: - have a new O/A exchange - potentially risk glare with some impact on user experience c) with No Plan: ... nothing I am intentionally not going into how all plans would require additional metadata that would place SSRC 1 left and 2 right as I don't think this conveys any meaningful differences. Comments on the above are welcome. We could also move to another scenario from the Plan A draft, if you believe that 7.3 is not representative enough. Emil -- https://jitsi.org From ibc@aliax.net Mon Jun 3 11:26:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26ED921F91B8 for ; Mon, 3 Jun 2013 11:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnlfuOFxX3ny for ; Mon, 3 Jun 2013 11:26:34 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD6621F8667 for ; Mon, 3 Jun 2013 11:26:34 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id s11so2385106qcw.15 for ; Mon, 03 Jun 2013 11:26:33 -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=5ZI0FCfZF8QuRgc9TY0femXepTtKDmgjHwwcmT1yxcA=; b=lvSD45Xjp16w2Y7mMkhOger9HjAajgCyZ9EW3ND5W/LGgpvS2mBFfaHedSidhL1x56 Yc21HfHBh9P6C78Sg7HcoZ0s21uyYseyK6DfbdvMAWEBsKCR8S78roLK8hXFMEEYkXqq JzIT8qQrt2FbSfWCGKwA7fstzj+AsF5+9Jzq0YQL7V8La0kRG+Tw0/hd7dY8HGSg6aI1 w0ogOOyu/VrpYo9pqOt0Fgwqc3wgGqIfZ0BfQ2tMgTJv6yZ4ATSFjCLmQCSZ2bGLPdVn BpvUEd5nti3FDURAmqG804tazzT5GL3wUV4vhiVYZpjYoULkyksN+ZcGVnyE3GCU7RSR Zjwg== X-Received: by 10.224.4.74 with SMTP id 10mr20519035qaq.38.1370283993825; Mon, 03 Jun 2013 11:26:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Mon, 3 Jun 2013 11:26:13 -0700 (PDT) In-Reply-To: <51ACD224.8080100@jitsi.org> References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 3 Jun 2013 20:26:13 +0200 Message-ID: To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkEsgJGPqTkLPI6HE3XRVR+kp7bAQ3BdG+ViTniYpKkuCvlu5yuykIKwq56b3N8pzRL2EEI Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 18:26:53 -0000 2013/6/3 Emil Ivov : > If you need to talk to a Plan A endpoint you basically have the following > options: > > 1. You use JavaScript to prettify the "No Plan" SDP and turn it into > something that looks like "Plan A". Not my favourite option, but I am sur= e > some would like to use it. Maybe vendors of Plan A equipment would even > distribute JS libs that do this. It would basically all come down to > generating one ssrc attribute and two additional m=3Dlines and appending = this > to the existing SDP string. HI, I would really prefer something that does not require SDP mangling via JS. That is dangerous. SDP is too much flexible and we never know how a SDP will look, so artificial mangling at JS level seems unfeasible IMHO. -- I=C3=B1aki Baz Castillo From ekr@rtfm.com Mon Jun 3 11:35:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D79511E80A4 for ; Mon, 3 Jun 2013 11:35:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12oGF-A2FiYv for ; Mon, 3 Jun 2013 11:34:58 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 11A4021F92FC for ; Mon, 3 Jun 2013 11:34:24 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id ne12so2034891qeb.27 for ; Mon, 03 Jun 2013 11:34:24 -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=m19/R522ObJCRQ6dcAEOiGsJ6akQPxbA8aCa92t6aq4=; b=Em6oxK5nqvsHlzjDlBIPO2fqwzOKk9cTNX/IFxkUhJPjNLNKtZvRkjESC+KEoDbka2 rG9tk23NeME4EzsOjgcC0gPw5gKfBccUCkWAgK8zG3t9ztFxqZA5mOl6RT0mtaXZXmrM XVV+gBLefnG8qoCRYPMW+9LFk/+XwBE66bHzrBphgBu6MBEB4hlRSaYyfY+57yZRJfbR BN1NFVRBoYThAxMisT5VUn+W42OD4RLY8M+hRv636D6lTbGS4RnRV4tNw8YeDqd1aLya 4xDT/7iBEZ7LxNXj9Wkvij2CW2WjPv/dsagY+NTalKZOunc/5W0Tyyn7tuvA6055hNfI jb7g== X-Received: by 10.49.81.147 with SMTP id a19mr18754133qey.47.1370284464413; Mon, 03 Jun 2013 11:34:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.0.163 with HTTP; Mon, 3 Jun 2013 11:33:44 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: <51ACD224.8080100@jitsi.org> References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> From: Eric Rescorla Date: Mon, 3 Jun 2013 11:33:44 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=047d7b6dd15ebe37ac04de4436a8 X-Gm-Message-State: ALoCoQnw5IAq6AH9WUUGtGVhhdYdLGP6QHNVhRtCb+A8uJUCR3WE4fgDhl0DN53VBK4x6f86luO5 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 18:35:14 -0000 --047d7b6dd15ebe37ac04de4436a8 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 3, 2013 at 10:28 AM, Emil Ivov wrote: [...] > III. Talking to other WebRTC applications > > This is the fun case and the one we should be most concerned with. Let's > imagine that the answerer needs to add a fourth video stream. To make this > work endpoints would need to do the following: > > a) with Plan A and draft-roach-rtcweb-glareless-**add: > - send application specific signalling to the offerer > - have a new O/A exchange > > b) with Plan A: > - have a new O/A exchange > - potentially risk glare with some impact on user experience > > c) with No Plan: > ... nothing > > I'm really not following how this works in "No Plan". Ignoring Plan A and Plan B, can you just walk through a complete example of what happens in your plan? I.e., how does browser B learn learn that Browser A wants to send 3 streams instead of one? -Ekr --047d7b6dd15ebe37ac04de4436a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 3, 2013 at 10:28 AM, Emil Ivov <emcho@jitsi.org><= /span> wrote:
[...]
III. Talking to other WebRTC applications

This is the fun case and the one we should be most concerned with. Let'= s imagine that the answerer needs to add a fourth video stream. To make thi= s work endpoints would need to do the following:

a) with Plan A and draft-roach-rtcweb-glareless-add:
=A0 =A0- send application specific signalling to the offerer
=A0 =A0- have a new O/A exchange

b) with Plan A:
=A0 =A0- have a new O/A exchange
=A0 =A0- potentially risk glare with some impact on user experience

c) with No Plan:
=A0 =A0... nothing


I'm really not following how= this works in "No Plan". Ignoring Plan A and Plan B, can you jus= t
walk through a complete example of what happens in your p= lan? I.e., how does browser
B learn learn that Browser A wants to send 3 streams instead of = one?

-Ekr

--047d7b6dd15ebe37ac04de4436a8-- From fluffy@iii.ca Mon Jun 3 12:53:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988D021E805A for ; Mon, 3 Jun 2013 12:53:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQztEXoxZ2cc for ; Mon, 3 Jun 2013 12:52:52 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id EF72B1F0D1D for ; Mon, 3 Jun 2013 12:42:53 -0700 (PDT) Received: from sjc-vpn1-987.cisco.com (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 CFB5E22E25B; Mon, 3 Jun 2013 15:42:46 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <51A8EB7F.6000506@jitsi.org> Date: Mon, 3 Jun 2013 13:42:43 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51A65017.4090502@jitsi.org> <51A8EB7F.6000506@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.1503) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan - but what's the proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 19:53:16 -0000 I just wanted to quickly clear up I was not treating any of your ideas = as a joke at all. Inline =85. On May 31, 2013, at 12:27 PM, Emil Ivov wrote: >>=20 >> The idea of exposing a low level API to the media stack and having >> the all proposing to do FEC, RTX, SDP processing ect has been >> discussed many times across the various working groups. It' jokingly >> refereed to as comment 22 at this point. >=20 > I appreciate you are trying to turn this into a joke (which I think is = a pity provide your chairing role in this working group), but abandoning = SDP really isn't what this is about. You might have noticed text about = this as early as the abstract: I am not treating any of this as a joke at all - I am trying to = understand what your roposal is. The "Comment 22" jokingly refers to = some comments made by Mathew at WebRTC and nothing really to do this = given that, as you say, this still uses Offer / Answer=20 >=20 > This document does not question the use of SDP and the Offer/Answer > model or the value they have in terms of interoperability with legacy > or other non-WebRTC devices. From fluffy@iii.ca Mon Jun 3 12:54:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338E621F8F4A for ; Mon, 3 Jun 2013 12:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXLKHgl1ToBA for ; Mon, 3 Jun 2013 12:54:04 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 416BE21F8F87 for ; Mon, 3 Jun 2013 12:44:19 -0700 (PDT) Received: from sjc-vpn1-987.cisco.com (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F0F5D50ABD; Mon, 3 Jun 2013 15:44:17 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <51A8EB7F.6000506@jitsi.org> Date: Mon, 3 Jun 2013 13:44:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <72B58042-78E3-4759-B3CD-204B82A38447@iii.ca> References: <51A65017.4090502@jitsi.org> <51A8EB7F.6000506@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.1503) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan - but what's the proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 19:54:19 -0000 On May 31, 2013, at 12:27 PM, Emil Ivov wrote: >>=20 >> Can you explain what you are actually proposing we do do instead of >> just saying what not to do ? >=20 > We create an offer that would describe the media types and the bundle. = We use that offer to also describe capabilities in terms of maximum = resolutions, supported header extensions, potentially max-ssrc-s, etc. >=20 > It is up to the application how to handle the rest. If it needs to = transmit additional signalling: let it. If it wants to encode that in = SDP, great. If it wants to attach it in JSON next to the browser = generated SDP, that also works. Great - I have super news for you. The WG agree to do that a year or = more ago.=20 From emil@sip-communicator.org Mon Jun 3 13:29:25 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3873921F90CC for ; Mon, 3 Jun 2013 13:29:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3iDu05PyoVr for ; Mon, 3 Jun 2013 13:29:15 -0700 (PDT) Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFC921F909A for ; Mon, 3 Jun 2013 13:16:37 -0700 (PDT) Received: by mail-bk0-f46.google.com with SMTP id na10so2193142bkb.33 for ; Mon, 03 Jun 2013 13:16:28 -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=j3Krwe2ZEdW4Dcp8tUCnJEV7mDUdinON6p3VbkGvtR8=; b=luFE5SAn+ala/HO/qTfLW7jM+gRfjWiOr3q9Y1oSnJyiBxOi323i8ZVXaatYqW+Hd6 yC9BFpdb3R/g+zv3s4D41n8SH4y+IG2K+VwzV8d4NVl5iqEC2Kh2pfGthT0+qAzAXIts ymH/biFlPcI/Wn2oulpTJtN/5jxYt4bkMJO8Br2gvEgYgauJrq/5GKU3nqEUlG3jDEyx 9bTmhICJd4LUqaq189VyWN1UYFYt4mcWK9arp/4qD/j0+5EkezAUTmYquPymwAg1SRhj 7QAJEbbCSgK6soFOONdLvD0fetiWtN/sWFKjM6/knTHfHXB7bqUocO1JBf6HCZAV4fWW EK/A== X-Received: by 10.204.185.201 with SMTP id cp9mr6940040bkb.128.1370290588030; Mon, 03 Jun 2013 13:16:28 -0700 (PDT) Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id cm9sm21001836bkb.4.2013.06.03.13.16.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 13:16:27 -0700 (PDT) Message-ID: <51ACF998.5030202@jitsi.org> Date: Mon, 03 Jun 2013 23:16:24 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Cullen Jennings References: <51A65017.4090502@jitsi.org> <51A8EB7F.6000506@jitsi.org> <72B58042-78E3-4759-B3CD-204B82A38447@iii.ca> In-Reply-To: <72B58042-78E3-4759-B3CD-204B82A38447@iii.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnPXnTEzEtVwYgOnl/T+wxcRRwoDaKI7Msuz/y1kWtM08kaMUR3NEGkDhcAHry9MxCqq/Ah Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan - but what's the proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 20:29:25 -0000 On 03.06.13, 22:44, Cullen Jennings wrote: > > On May 31, 2013, at 12:27 PM, Emil Ivov wrote: > >>> >>> Can you explain what you are actually proposing we do do instead of >>> just saying what not to do ? >> >> We create an offer that would describe the media types and the bundle. We use that offer to also describe capabilities in terms of maximum resolutions, supported header extensions, potentially max-ssrc-s, etc. >> >> It is up to the application how to handle the rest. If it needs to transmit additional signalling: let it. If it wants to encode that in SDP, great. If it wants to attach it in JSON next to the browser generated SDP, that also works. > > Great - I have super news for you. The WG agree to do that a year or more ago. So I've heard indeed. Unfortunately however, it seems that we might have forgotten this decision. We are now trying hard to come up with a signalling mechanism that will do everything with Offer/Answer. From pkyzivat@alum.mit.edu Mon Jun 3 13:45:21 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D114521F9298 for ; Mon, 3 Jun 2013 13:45:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRJRrCCASw6E for ; Mon, 3 Jun 2013 13:45:07 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id AFABD21E80CB for ; Mon, 3 Jun 2013 13:37:31 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA11.westchester.pa.mail.comcast.net with comcast id jvDT1l0081YDfWL5BwdXoi; Mon, 03 Jun 2013 20:37:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id jwdW1l01b3ZTu2S3gwdWWj; Mon, 03 Jun 2013 20:37:31 +0000 Message-ID: <51ACFE8A.8030503@alum.mit.edu> Date: Mon, 03 Jun 2013 16:37:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8F5D8.8070602@alum.mit.edu> <51A98934.3000103@jitsi.org> In-Reply-To: <51A98934.3000103@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370291851; bh=CkrgJ7CBfDWYUM7oLv9YLTQJKDslaoo+v5UJsM++Ixo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=J5NIg6rMLa0KKo6Y+c9U9dx3OrkUbWSulE9xs+AH9KiDEGlxyn+YUD/xHy9B9GUOB Xy2vbacdi/dMAbk7wpg5lf2FIWyOaRL3podqYYSiOOovYiQivHVGx2o7gipvKNU8Gb gR4lstqlsv7Rp2XPTzP55ZbIlMbF9uW42rkcDga0vbv1rBPFhx6D4YjOwVI/yC1J4F GdbUP1arDcQrGmsu8ECoxyBiPluvVsqynmyaIjDytUE5+NzzYqNxiCNJAwRxAFSS8R 8kSA/w32UAzTW9446zYTBZMxte6/eTxBJIcGQkk55NE0wmpcC57PcDfYW+5GbUuBRd kzdxZ+126kx5g== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 20:45:22 -0000 On 6/1/13 1:40 AM, Emil Ivov wrote: > > > On 31.05.13, 22:11, Paul Kyzivat wrote: >> On 5/31/13 6:51 AM, Emil Ivov wrote: >>> Hey Paul, >>> >>> On 29.05.13, 22:57, Paul Kyzivat wrote: >>>> Emil, >>>> >>>> I'm going to reserve judgment on this pending further discussion. >>>> I think this *might* work for CLUE, but I want to be certain. >>> >>> Sure! >>> >>>> I'm concerned with decomposed endpoints that can't manage all the >>>> streams on the same address/port. They will need multiple independent >>>> m-lines and/or bundle groups. >>> >>> This is obviously open for debate but the general idea of No Plan is >>> that: Offer/Answer is used for configuring media and RTP stacks and >>> additional signalling is not the browser's concern. >>> >>> Having extra m= lines, particularly when using BUNDLE, is in many ways >>> just extra signalling. >> >> You may be able to argue that adding extra m-lines into an existing >> bundle is "just extra signaling". But introducing an additional 5-tuple >> is more substantial. It requires configuring a new RTP stack and media. > > Indeed, this would require BUNDLE to work. I don't understand what that means - what point you are trying to make. You seem to have some criterion for what requires sdp and what does not. And AFAIK you are already assuming bundle works - you are simply using it less. As best I can tell, you acknowledge that you need SDP to: - negotiate a 5-tuple over which media will flow - specify which types of media can be carried and the codec info they may use. I'm just pointing out that for decomposed endpoints one 5-tuple may not be enough. And the need for this might not be known a priori. One side may be ready to add another stream for some purpose, and be willing/able to use private signaling to negotiate that. But the other side may not be able to handle that stream on the same 5-tuple. That in turn may result in a need to negotiate SDP changes to establish an additional 5-tuple that can then be used for that new stream. Thanks, Paul > Emil > > >> >> Thanks, >> Paul >> >>> If you'd like for that signalling to be in SDP, I >>> don't see any problem with it. However it would be best for this extra >>> layer of SDP signalling to appear at either the application layer or in >>> a signalling gateway (that is going to be there anyway). >>> >>> Does this make sense? >>> >>> Emil >>> >>>> >>>> Further questions: >>>> >>>> I presume that you expect bandwidth in the SDP to be an aggregate >>>> per-m-line, with application specific signaling for bandwidth at the >>>> per-RTP-stream level? >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 5/29/13 2:59 PM, Emil Ivov wrote: >>>>> Hey all, >>>>> >>>>> Based on many of the discussions that we've had here, as well as many >>>>> others that we've had offlist, it seemed like a good idea to >>>>> investigate >>>>> a negotiation alternative that relies on SDP and Offer/Answer just a >>>>> little bit less. >>>>> >>>>> The following "no plan" draft attempts to present one such approach: >>>>> >>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>>> >>>>> The draft relies on conventional use of SDP O/A but leaves the >>>>> intricacies of multi-source scenarios to application-specific >>>>> signalling, with potentially a little help from RTP. >>>>> >>>>> Hopefully, proponents of Plans A and B would find that the >>>>> interoperability requirements that concerned them can still be met >>>>> with >>>>> "no plan". Of course they would have to be addressed by >>>>> application-specific signalling and/or signalling gateways. >>>>> >>>>> Comments are welcome! >>>>> >>>>> Cheers, >>>>> Emil >>>>> >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> . >>>> >>> >> >> . >> > From pkyzivat@alum.mit.edu Mon Jun 3 13:47:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AAB11E80DC for ; Mon, 3 Jun 2013 13:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_17=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3elY4ahzpwIC for ; Mon, 3 Jun 2013 13:47:33 -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 5D54521F8808 for ; Mon, 3 Jun 2013 13:40:19 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta14.westchester.pa.mail.comcast.net with comcast id jna71l0060EZKEL5EwgJxv; Mon, 03 Jun 2013 20:40:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id jwgJ1l0113ZTu2S3MwgJ06; Mon, 03 Jun 2013 20:40:18 +0000 Message-ID: <51ACFF31.9090607@alum.mit.edu> Date: Mon, 03 Jun 2013 16:40:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A65017.4090502@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se>, <51A9A7E2.7000907@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C380AA2@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C380AA2@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370292018; bh=I6jlqFtUFDj/ci/bMDMK6nBDDxGUMNQV/in0WnrlzuA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DI6JBRb6dw4hCxsiieOwcJbe2AzCtJEbcBg31iG8lLSINsXOOV3J5A2fbi1H0OK2I PZH0kuv/XjWGBGCjrac7C6WSJogtLW8shd7RvUIHleuhjDVOn3381HyAOpYlB+fGB8 A5L26gJxkYL4O0xwR8Y+3n0VmxQtqtqFAAv+yRiuQ8Tf7JUJVn/mPhqhDDAWj7sWAy jJ9Nh6I9kXMY09AlQYwHe95HXoDKfp96NjsqhNBnkdwf5chQRKJBCaS3h65QQ8KFP6 ZdNsShdM0hzXrRYUCCtcqXOFPs/eYjcUn2b4I2C0IQglWFVZvb24uPOUUa7MPfczPW l9qWuO20AoyIw== Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 20:47:57 -0000 +1 The more we dig into this the more it looks like Plan B. Thanks, Paul On 6/1/13 7:05 AM, Christer Holmberg wrote: > > Hi, > >>> The draft says: >>> >>> "For the sake of interoperability this specification strongly advises >>> against the use of multiple m= lines for a single media type." >> >> This should probably be clarified. The above referred mostly to a >> browser's expectations and default offers. Multiple m= lines can confuse >> a number of existing legacy endpoints which is why they should be >> avoided when initiating a session that could reach a similar device (and >> by default this should be assumed for any session). >> >> If applications *know* that they need to have multiple m= lines of a >> given type they can request this the same way they could do it with Plan B: >> >> If the application wishes, it can request that a given >> media source be placed onto a separate m= line, by setting a new >> .content property on the desired MediaStreamTrack; the values for the >> .content property are those defined for the a=content attribute in >> [RFC4796]. >> >> I'll make sure this is part of the next version. >> >> Does this make sense? > > I have nothing against a general recommendation to, for a given media type, have as few m- lines as possible. > > But, I do think the draft need to point out that it is not always possible, e.g. because: > > 1) m- lines have different characteristics (normally indicated using SDP attributes) that does not "fit" all content for the given media type; > 2) different protocols are used for different m- lines, even if the media type is the same; or > 3) the remote endpoint only supports a single (or, another given number) of sources per m- line. > > Etc. > > Regards, > > Christer > > > > > >> My understanding is that the usage of multiple m= lines for a single media type would not affect the mechanism as such, but I just want to verify that :) >> >> Also, there ARE "legacy" implementations that use multiple m= lines for a single media type (e.g. video enabled devices using two video m= lines: one for camera content, and one for slides). >> >> So, while I definitely think that legacy interoperability shall be taken into consideration, I would not like to make such strong statements. In my opinion (the draft also talks about it), the usage of multiple simultaneous SSRCs per m- line is a much bigger issue when it comes to legacy interoperability. >> >> Also, in CLUE we have been working on signaling scenarios with multiple m= lines per media type. > > >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Emil Ivov >> Sent: 29. toukokuuta 2013 22:00 >> To: rtcweb@ietf.org >> Subject: [rtcweb] No Plan >> >> Hey all, >> >> Based on many of the discussions that we've had here, as well as many others that we've had offlist, it seemed like a good idea to investigate a negotiation alternative that relies on SDP and Offer/Answer just a little bit less. >> >> The following "no plan" draft attempts to present one such approach: >> >> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >> >> The draft relies on conventional use of SDP O/A but leaves the intricacies of multi-source scenarios to application-specific signalling, with potentially a little help from RTP. >> >> Hopefully, proponents of Plans A and B would find that the interoperability requirements that concerned them can still be met with "no plan". Of course they would have to be addressed by application-specific signalling and/or signalling gateways. >> >> Comments are welcome! >> >> Cheers, >> Emil >> >> -- >> https://jitsi.org >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> . >> > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From martin.thomson@gmail.com Mon Jun 3 13:56:25 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554C421F965A for ; Mon, 3 Jun 2013 13:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3khIyvQm7U1 for ; Mon, 3 Jun 2013 13:56:15 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 23B0A11E8116 for ; Mon, 3 Jun 2013 13:49:38 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id n12so3126443wgh.3 for ; Mon, 03 Jun 2013 13:49: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=adRfkSGeM950JqDsejZVo2+cIQrKhV2Sgh8Qzpj5rd0=; b=zfV2CsYv96LTwosSGhBL28+ODihM9SX69jJgnNDDWvisyy7i1BvgDroaYue595hPzb FfrkQY8pxS5lbHpZnyQum0h09OdWB2lUGz9HXqrthEfESJL9w7omwm1+1UM9HWNI/TCH e7uV8SH7Im83h8+5sNh+/lUSUYUSC+DiH2TycG1GnEKfj/d0istnZViOd1Vnt7IyFqi9 W/ocudXpcL3pRXVREJTqaTUnpPUgZ64BYGdJUrDpruGEWnPj7645edt1eI7RBjplHYW0 srsb0KbQiHVPO28O9YmEpO4zR0rCL7HpYKxfmhPYQJrjE7YM2HEQrW6eqYkhDu8HXLhu c49g== MIME-Version: 1.0 X-Received: by 10.194.249.231 with SMTP id yx7mr10251203wjc.13.1370292578323; Mon, 03 Jun 2013 13:49:38 -0700 (PDT) Received: by 10.194.250.10 with HTTP; Mon, 3 Jun 2013 13:49:38 -0700 (PDT) In-Reply-To: References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> Date: Mon, 3 Jun 2013 13:49:38 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 20:56:25 -0000 On 3 June 2013 11:33, Eric Rescorla wrote: > > I'm really not following how this works in "No Plan". Ignoring Plan A and > Plan B, can you just > walk through a complete example of what happens in your plan? I.e., how does > browser > B learn learn that Browser A wants to send 3 streams instead of one? I think that I've reached the same conclusion. At some point, the browser needs to be told what to do. At browser A, this is fairly obvious: streams are added to the RTCPeerConnection instance. But what happens at browser B? I think that there are a couple of alternatives, and we might need to enable more than one of those, but I don't think that Section 7 has enough information yet. From pkyzivat@alum.mit.edu Mon Jun 3 14:09:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A2611E80EC for ; Mon, 3 Jun 2013 14:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.237 X-Spam-Level: X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvMDvD8f7C+d for ; Mon, 3 Jun 2013 14:09:15 -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 5E91121E809D for ; Mon, 3 Jun 2013 14:02:47 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta03.westchester.pa.mail.comcast.net with comcast id ju6d1l0071vXlb853x2j5f; Mon, 03 Jun 2013 21:02:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id jx2j1l00J3ZTu2S3dx2jpj; Mon, 03 Jun 2013 21:02:43 +0000 Message-ID: <51AD0472.9020506@alum.mit.edu> Date: Mon, 03 Jun 2013 17:02:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <51A8F3EF.9080702@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370293363; bh=EkXP7pB8Hbs0xFQktjAQ/VtVuXHKR0bl0KMNtIYXrlI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oYRf9kjSZBwsd4q0jBCHSqSw5Lw5SE3zyEne3bPRXv18/9yJPFQB+25G5wsZSDlCo DlilG8pLkAiehOdu2UoxSEhKmeczBC7i4nFk3odeQMO4WyBZXEjrRyV0LWalqHkN68 kfP/HCTE+QLpaG59DTeKJlHQBSorJYgM21vguhqNBcCJhWtLUI3lE8cgPooHQEbdBc QuhP5zYy9eCo8BEu4ECLlmiqxFMj8bYLLGetdGzbmAmhlFwKtMte1bN3E1MygB7ho0 rny3FlKMLJGGHFC5SwkFVtNHJztOr4rfs2BySfEwKFrqA0tOAHTUuGCJJFEzRQBXLB O4u5lhtXLCsIQ== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:09:30 -0000 On 6/3/13 6:28 AM, Iñaki Baz Castillo wrote: > 2013/5/31 Paul Kyzivat : >>> That can be implemented on top of DataChannel anyway, I see no need >>> for mandating it as a new RTP media stream negotiated via SDP. >> >> >> IIUC, Gunnar is expecting that virtually every app that provides real time >> voice communication should also provide RTT. (And this has a habit of >> showing up as a legal mandate.) >> >> Leaving the decision about how to transport RTT to be reinvented by each >> application doesn't seem like a good way to achieve that. > > > Hi Paul. Standarizing the "app layer" in WWW does not work, nobody > wants it. What about if somebody (a website) wants to send custom > emoticons within the realtime text? should the WG define a "text > document format" for RTT? Each website does it in the custom way it > likes. > > Tons of webs offer chat since years, why do we need a standard for it > now? A user in website-A will never chat with a user in website-B > anyway. I think this comes down to whether you think text/chat is "application" or "media". Contrast it to video. My web app can send an image as part of a web page. It is "just a part of the application". And video is "just" a matter of sending a bunch if images in succession. So why isn't that still just "application" stuff? Why should we need RTP for it? One answer may be that the difference is that the real-time requirements for text aren't as demanding as they are for voice or video. But there are other good reasons for identifying interactive text as media. One reason is what we are arguing right how: the desire to negotiate properties of the transmission. (Should it be byte-by-byte or line-by-line.) Another is that, like voice and video there is likely to be a demand to record it for later analysis and playback, or to broadcast it to a collection of people. When text is treated as media, then treating it in parallel with other media makes more sense. (For instance ensuring the that the text is synchronized with the other media, both initially and when recorded and played back later.) >> Leaving the decision about how to transport RTT to be reinvented by each >> application doesn't seem like a good way to achieve that. > > The Web has succeeded because each website has the capability of > reinventing the application by adding its own innovation and features. > Otherwise there would not be so many different social networks or > travel websites offereing "the same". There is the good and the bad of this. There are lots of web sites that off something they call "chat". And they are all different. So I can't be sure if I will have a transcript of the chat at the end or not. Or any record of it after the fact. It is evident to me that we can't prevent chat being done this way. But it doesn't make it best practice. >> If that is good enough for RTT, then why not voice and video too? Just send >> it over a data channel in any format you like. We don't need to standardize >> how to do it. > > JS can not retrieve the audio/video bits received from the peer and > convert them into audio/video to be sent to the local multimedia > devices. Maybe true for audio, but not video. If the video bits were sent over a data channel the JS could retrieve them and put them into a window. (It would be a pig, but possible.) > That's why the WG defines a media format (I mean RTP + > security) and an API for providing such a multimedia flow to the JS > app. > > The same is not true for text chat which can be achieved in tons of > ways in the WWW, without the need of a standard. I agree there are some differences. But there are also a lot similarities. Thanks, Paul From pkyzivat@alum.mit.edu Mon Jun 3 14:10:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B50221F8689 for ; Mon, 3 Jun 2013 14:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vg6sejFnZFLu for ; Mon, 3 Jun 2013 14:10:16 -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 DDB5721E80A6 for ; Mon, 3 Jun 2013 14:03:32 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta02.westchester.pa.mail.comcast.net with comcast id jvHK1l0071swQuc51x3YSd; Mon, 03 Jun 2013 21:03:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id jx3Y1l0093ZTu2S3bx3YsV; Mon, 03 Jun 2013 21:03:32 +0000 Message-ID: <51AD04A4.9010607@alum.mit.edu> Date: Mon, 03 Jun 2013 17:03:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <51A8F3EF.9080702@alum.mit.edu> <51AC7D4F.6090708@omnitor.se> <51AC8547.1060400@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370293412; bh=ZzAkiOyBU9EjyPuSfa1yoExRnYbMWm0orlQbGZAoVmA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KRfAdzTj16sIjLYiQYcixuOa4bErx6cS51pFLajgwVQdTz37LI/eArlsXnnJl1qh2 qcpKGRCtpg5+uWpNhIdmPQDQg45k6GlpnrGpucs2vH/awYIqQjZm8e+nWyj4EFJGAO oh+2ILKJRi5PMPgDKsgRE2/9hG1I1YPgn3J8wmaaNMey/98C2bxrH7J7FEdshFbVzD q0ZhVruvOmOLIO3eVheMlCObYBE1yUxS8CPDwhc13Gfgq2jULel8dM2h8eViy6eClE RejmfSvKdZ12DdUpX+rlDDeARw/aq0IKZS4D2IynMH0xVD+Lxmx73RbP7S+00uWvxw se80o+bGXBGkQ== Subject: Re: [rtcweb] RTT (was :No Plan ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:10:30 -0000 On 6/3/13 8:14 AM, Iñaki Baz Castillo wrote: > 2013/6/3 Gunnar Hellstrom : >> The use cases draft includes a case titled: >> >> 4.2.10. Simple video communication service with inter-operator calling >> >> See: >> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10#page-9 > > That will just work if both websites want to offer such a > inter-website-communication. And that's already feasible. But we don't > need a new standard (RTT-over-RTP) for allowing two users in different > websites to intercommunicate via RTT. It isn't new. > That can be achieved in multiple > ways with existing technology (WebSocket, DataChannel) but, still, > both websites must allow it. > > > -- > Iñaki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From ibc@aliax.net Mon Jun 3 14:12:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782BF11E80F6 for ; Mon, 3 Jun 2013 14:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrR59ECnPRek for ; Mon, 3 Jun 2013 14:12:42 -0700 (PDT) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 44F8121F9648 for ; Mon, 3 Jun 2013 14:07:27 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id s14so980731qeb.29 for ; Mon, 03 Jun 2013 14:07:25 -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=dp3IS/ChiSnHslRGwtPFxsmYGsChgmmUNAVKIaXroyc=; b=mAFuqWfoOrDigkEHKzN8VKo2t2Pjq2Bu4kIRyB0WcRHvWEXYqDOJfXWPj0BruU8+Ta ThZlFuRkEsY/p/X21U1u7kUq9jpXlxghGMQQ9S2bRMFLCMnJ50a/DNECubcegfl1v7jy R5116MVmF+piVh3UIx3JpiCfwgj3R9/ALce9xwGe0s2N8h9r/KTJue2BhsNKc8WJZqTp lcbWnLEgO3FBlf6Aq71HxmzNcR8GmTGz7dF1edWlc3h7+3YFbYAo9NgOyNUuJL/ZgQQ3 pFgCUaLy46e7nmLrpV9Wp9vGm85Y2hyCjcmO3N4pBMTRBop2UdG8HBUZEnP6kE7wyloL qwRA== X-Received: by 10.224.4.74 with SMTP id 10mr21039360qaq.38.1370293645393; Mon, 03 Jun 2013 14:07:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Mon, 3 Jun 2013 14:07:05 -0700 (PDT) In-Reply-To: <51ACF998.5030202@jitsi.org> References: <51A65017.4090502@jitsi.org> <51A8EB7F.6000506@jitsi.org> <72B58042-78E3-4759-B3CD-204B82A38447@iii.ca> <51ACF998.5030202@jitsi.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 3 Jun 2013 23:07:05 +0200 Message-ID: To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlBqA2gc7SefzMVusMAcUb9dqGahvZS5BR6x1W+kBb7SGvkVsNnqJ/mSz9HyqvDEUFj3IxC Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan - but what's the proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:12:57 -0000 2013/6/3 Emil Ivov : >>> We create an offer that would describe the media types and the bundle. = We >>> use that offer to also describe capabilities in terms of maximum >>> resolutions, supported header extensions, potentially max-ssrc-s, etc. >>> >>> It is up to the application how to handle the rest. If it needs to >>> transmit additional signalling: let it. If it wants to encode that in S= DP, >>> great. If it wants to attach it in JSON next to the browser generated S= DP, >>> that also works. >> >> >> Great - I have super news for you. The WG agree to do that a year or mor= e >> ago. > > > So I've heard indeed. > > Unfortunately however, it seems that we might have forgotten this decisio= n. > We are now trying hard to come up with a signalling mechanism that will d= o > everything with Offer/Answer. I think there is a misunderstanding here. I understand from Emil's mail that media re-negotation or streams addition after the first SDP O/A is not carried as a new full SDP O/A. Am I right? -- I=C3=B1aki Baz Castillo From emil@sip-communicator.org Mon Jun 3 14:15:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FB411E80F4 for ; Mon, 3 Jun 2013 14:15:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcdD3uCBZcVi for ; Mon, 3 Jun 2013 14:14:50 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id A504A11E80F5 for ; Mon, 3 Jun 2013 14:09:46 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hr14so3135370wib.3 for ; Mon, 03 Jun 2013 14:09:45 -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=9nAlLtu+EzBRjJGKLi9UXVXgS9ZOLIYAjwKq2W9aD54=; b=A3cDWAAvtHm5YCrhKyVV1+0GY81zRzzs804Ns5/fxq+JmZ1HyddD14dtNhtSy/6Mcm sOPMwdjMfaZkVIwZKZfX12yKSAjBh18FK0wylmw2woRVrROcq6GEXwpYWSgAB6OlpYjT em7dOK7EmVRSCuxplmVPVAxjL6E1t+yYbS54CvzZIgBJj53UK8NyjgyO9Osl7tlurgmi 7TJEXqwCuvhK7vonAc7krIrpLxlBi68BVxS3W8occ1g+RB7epklEzoGMe17B/cFy+Ztx Gikz+AzEVqnpcYmRiFkPSQWt9PjBnSHEZkHugwlQiI3f4Eo5piifTwHthYvry+ISGFaM CLgw== X-Received: by 10.194.243.129 with SMTP id wy1mr10346838wjc.47.1370293785756; Mon, 03 Jun 2013 14:09:45 -0700 (PDT) Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id ff10sm26188335wib.10.2013.06.03.14.09.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 14:09:44 -0700 (PDT) Message-ID: <51AD0616.5040008@jitsi.org> Date: Tue, 04 Jun 2013 00:09:42 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8F5D8.8070602@alum.mit.edu> <51A98934.3000103@jitsi.org> <51ACFE8A.8030503@alum.mit.edu> In-Reply-To: <51ACFE8A.8030503@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn3khdAkfP/LnoOOTTb2lIElxZztYahNnpr9lblvTqnQi2X3PdrsThyOj4ly8B2YwTug1iw Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:15:01 -0000 Hey Paul, On 03.06.13, 23:37, Paul Kyzivat wrote: > On 6/1/13 1:40 AM, Emil Ivov wrote: >> >> >> On 31.05.13, 22:11, Paul Kyzivat wrote: >>> On 5/31/13 6:51 AM, Emil Ivov wrote: >>>> Hey Paul, >>>> >>>> On 29.05.13, 22:57, Paul Kyzivat wrote: >>>>> Emil, >>>>> >>>>> I'm going to reserve judgment on this pending further discussion. >>>>> I think this *might* work for CLUE, but I want to be certain. >>>> >>>> Sure! >>>> >>>>> I'm concerned with decomposed endpoints that can't manage all the >>>>> streams on the same address/port. They will need multiple independent >>>>> m-lines and/or bundle groups. >>>> >>>> This is obviously open for debate but the general idea of No Plan is >>>> that: Offer/Answer is used for configuring media and RTP stacks and >>>> additional signalling is not the browser's concern. >>>> >>>> Having extra m= lines, particularly when using BUNDLE, is in many ways >>>> just extra signalling. >>> >>> You may be able to argue that adding extra m-lines into an existing >>> bundle is "just extra signaling". But introducing an additional 5-tuple >>> is more substantial. It requires configuring a new RTP stack and media. >> >> Indeed, this would require BUNDLE to work. > > I don't understand what that means - what point you are trying to make. Sorry about this. What I was trying to say was: yes, you are right, introducing a new 5-tuple is more substantial. Therefore adding a new m= line to an SDP is a lot simpler if it didn't also imply adding a new 5-tuple. This would only be possible when m= lines are bundled. This is why I said: "Indeed, this would require BUNDLE to work." Is this clearer? > You seem to have some criterion for what requires sdp and what does not. > And AFAIK you are already assuming bundle works - you are simply using > it less. No, not really. The assumption is only necessary when trying to talk to Plan A devices and you want to have new m= lines added en route. No such assumption is necessary, for example, when talking to legacy SIP phones that will only show one video and one audio stream. > As best I can tell, you acknowledge that you need SDP to: > - negotiate a 5-tuple over which media will flow > - specify which types of media can be carried and the codec info > they may use. Yes. > I'm just pointing out that for decomposed endpoints one 5-tuple may not > be enough. And the need for this might not be known a priori. One side > may be ready to add another stream for some purpose, and be willing/able > to use private signaling to negotiate that. But the other side may not > be able to handle that stream on the same 5-tuple. That in turn may > result in a need to negotiate SDP changes to establish an additional > 5-tuple that can then be used for that new stream. I think I see ... but not completely. Could you please post an SDP offer with BUNDLE and the corresponding answer? (This might be a good point to move this to mmusic) Thanks, Emil >> >> >>> >>> Thanks, >>> Paul >>> >>>> If you'd like for that signalling to be in SDP, I >>>> don't see any problem with it. However it would be best for this extra >>>> layer of SDP signalling to appear at either the application layer or in >>>> a signalling gateway (that is going to be there anyway). >>>> >>>> Does this make sense? >>>> >>>> Emil >>>> >>>>> >>>>> Further questions: >>>>> >>>>> I presume that you expect bandwidth in the SDP to be an aggregate >>>>> per-m-line, with application specific signaling for bandwidth at the >>>>> per-RTP-stream level? >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 5/29/13 2:59 PM, Emil Ivov wrote: >>>>>> Hey all, >>>>>> >>>>>> Based on many of the discussions that we've had here, as well as many >>>>>> others that we've had offlist, it seemed like a good idea to >>>>>> investigate >>>>>> a negotiation alternative that relies on SDP and Offer/Answer just a >>>>>> little bit less. >>>>>> >>>>>> The following "no plan" draft attempts to present one such approach: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>>>> >>>>>> The draft relies on conventional use of SDP O/A but leaves the >>>>>> intricacies of multi-source scenarios to application-specific >>>>>> signalling, with potentially a little help from RTP. >>>>>> >>>>>> Hopefully, proponents of Plans A and B would find that the >>>>>> interoperability requirements that concerned them can still be met >>>>>> with >>>>>> "no plan". Of course they would have to be addressed by >>>>>> application-specific signalling and/or signalling gateways. >>>>>> >>>>>> Comments are welcome! >>>>>> >>>>>> Cheers, >>>>>> Emil >>>>>> >>>>> >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> . >>>>> >>>> >>> >>> . >>> >> > > -- https://jitsi.org From pkyzivat@alum.mit.edu Mon Jun 3 14:21:58 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FDF11E80F4 for ; Mon, 3 Jun 2013 14:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.519 X-Spam-Level: X-Spam-Status: No, score=0.519 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLVWNDiAsvRb for ; Mon, 3 Jun 2013 14:21:41 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 27E3B11E8108 for ; Mon, 3 Jun 2013 14:16:38 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta12.westchester.pa.mail.comcast.net with comcast id jnCV1l0071YDfWL5CxGeEv; Mon, 03 Jun 2013 21:16:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id jxGd1l01R3ZTu2S3gxGdDf; Mon, 03 Jun 2013 21:16:37 +0000 Message-ID: <51AD07B4.3070702@alum.mit.edu> Date: Mon, 03 Jun 2013 17:16:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> In-Reply-To: <51ACD224.8080100@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370294198; bh=yC2M7raLj1egp+YbmG87QHDNYn1I5KqcLFUltIX16Wc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oKoNy+/rYC3Ki8tA/J2M/R9Bb/AhaHaLLzc3PD7emvRc5vHCWCBXQwIaZFMcEqnbI Lgugu9eeHjsTVjD4EBPtvjwocLpHuGpV5CvZzZueJF5zoxQKsMIuMo3jt5HLItCCN1 rD2l+QXaImvqaqPzYB4nVrU1lUTHSsyKRZRYceT1nAP9Gu6MV9wdJ3hiBX/S8965NQ zaOe+q0dilwv9KNFivqCFyCDgUvNfLPZO5T7Gvj5ZVuStmcCvUe5tATvxZttN4VdVk 3yNKVCByklg+nCmC8NR71zccdUf5h+nkKPRPPrnYsRBfZwy/eV9B3liBsjGvCfuUEI hTJT1V6aWCjmw== Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:21:58 -0000 I don't understand why we would be talking about translating from one of these plans to another. AFAIK they are *alternatives*, and that we will at some point agree on one, and that will be the only one implemented. Thanks, Paul On 6/3/13 1:28 PM, Emil Ivov wrote: > Hey Cullen, Paul, all > > On 31.05.13, 22:19, Cullen Jennings (fluffy) wrote: >> On 31.05.2013, at 12:23 PM, Emil Ivov wrote: >> >>> Certainly. Could you please post the SDP that you would like to see >>> translated in a way that's compatible with "No Plan"? >>> >>> Emil >> >> We can start with the SDP in plan A > > The example in "7.3. Many Videos" looks like a good start: > > http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00#section-7.3 > > Here it is: > > v=0 > o=- 20518 0 IN IP4 198.51.100.1 > s= > t=0 0 > c=IN IP4 203.0.113.1 > a=ice-ufrag:F7gI > a=ice-pwd:x9cml/YzichV2+XlhiMu8g > a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7 > a=group:BUNDLE m0 m1 m2 m3 > > m=audio 56600 RTP/SAVPF 0 96 > a=mid:m0 > a=rtpmap:0 PCMU/8000 > a=rtpmap:96 opus/48000 > a=ptime:20 > a=sendrecv > a=rtcp-mux > [ICE Candidates] > > m=video 0 RTP/SAVPF 97 98 > a=mid:m1 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 > a=rtpmap:98 VP8/90000 > a=sendrecv > a=rtcp-mux > a=bundle-only > a=ssrc:11111 cname:45:5f:fe:cb:81:e9 > > m=video 0 RTP/SAVPF 97 98 > a=mid:m2 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 > a=rtpmap:98 VP8/90000 > a=sendrecv > a=rtcp-mux > a=bundle-only > a=ssrc:22222 cname:45:5f:fe:cb:81:e9 > > m=video 0 RTP/SAVPF 97 98 > a=mid:m3 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 > a=rtpmap:98 VP8/90000 > a=sendrecv > a=rtcp-mux > a=bundle-only > a=ssrc:333333 cname:45:5f:fe:cb:81:e9 > > > An offer generated by a "No Plan" browser in this case would look > something like this: > > v=0 > o=- 20518 0 IN IP4 198.51.100.1 > s= > t=0 0 > c=IN IP4 203.0.113.1 > a=ice-ufrag:F7gI > a=ice-pwd:x9cml/YzichV2+XlhiMu8g > a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7 > a=group:BUNDLE m0 m1 > > m=audio 56600 RTP/SAVPF 96 0 > a=mid:m0 > a=rtpmap:96 opus/48000 > a=rtpmap:0 PCMU/8000 > a=ptime:20 > a=sendrecv > a=rtcp-mux > [ICE candidates] > > m=video 56602 RTP/SAVPF 97 98 > a=mid:m1 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 > a=rtpmap:98 VP8/90000 > a=sendrecv > a=rtcp-mux > [ICE candidates] > > I. Talking to legacy > > In case you need to talk to an actual legacy (as in widely deployed SIP) > endpoint, the above would translate into a regular two-stream call. Both > Plan A and No Plan would lead to essentially the same result (if we > accept that older endpoints won't throw an exception at the sight of 4 > m= lines) so not much to discuss here. > > II. Talking to Plan A style endpoints > > If you need to talk to a Plan A endpoint you basically have the > following options: > > 1. You use JavaScript to prettify the "No Plan" SDP and turn it into > something that looks like "Plan A". Not my favourite option, but I am > sure some would like to use it. Maybe vendors of Plan A equipment would > even distribute JS libs that do this. It would basically all come down > to generating one ssrc attribute and two additional m=lines and > appending this to the existing SDP string. > > 2. The application retrieves SSRCs from the browser, adds additional > application-specific signalling to it and then sends the whole thing to > a signalling gateway. The gateway (which you would also have with Plan > A) would convert the SDP into what it needs it to be. > > The application specific signalling can look like this: > > { > "firstStream": > { > "SSRC": "11111", > "CNAME": "45:5f:fe:cb:81:e9" > }, > "secondStream": > { > "SSRC": "22222", > "CNAME": "45:5f:fe:cb:81:e9" > }, > "thirdStream": > { > "SSRC": "333333", > "CNAME": "45:5f:fe:cb:81:e9" > }, > } > > 3. In Plan B, section 3.1 talks about generating "Plan A" style SDP with > the help of .content properties. If browser vendors are willing to > implement support for this then I suppose it would be a third option. > > III. Talking to other WebRTC applications > > This is the fun case and the one we should be most concerned with. Let's > imagine that the answerer needs to add a fourth video stream. To make > this work endpoints would need to do the following: > > a) with Plan A and draft-roach-rtcweb-glareless-add: > - send application specific signalling to the offerer > - have a new O/A exchange > > b) with Plan A: > - have a new O/A exchange > - potentially risk glare with some impact on user experience > > c) with No Plan: > ... nothing > > I am intentionally not going into how all plans would require additional > metadata that would place SSRC 1 left and 2 right as I don't think this > conveys any meaningful differences. > > Comments on the above are welcome. We could also move to another > scenario from the Plan A draft, if you believe that 7.3 is not > representative enough. > > Emil > > From ibc@aliax.net Mon Jun 3 14:25:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC4021F8FA5 for ; Mon, 3 Jun 2013 14:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kkGoQ8pNImf for ; Mon, 3 Jun 2013 14:25:27 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id AEC9711E80F2 for ; Mon, 3 Jun 2013 14:20:33 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id cr7so2133397qab.11 for ; Mon, 03 Jun 2013 14:20:33 -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=088tR0Kp81ILFJHR+FHmMrI4GxJvtcL0p0qWXv3zoXE=; b=TNNMDSZmIM4evXBF+J54c66iTGe4zZNrMM23DSVsNZ1feQg7Buf5TtgjzQMbPMKQzh 6Lq/E06Da9dVxE5RFV3SkhG9H8orscbFHsAgvSo7QJ06v0uRkirMJp/aboEDNyxOj1lo AM+QP22MHx9vr4tc3EkCS7/b0TZBZaPtUEyDERa71vo5gyNGYNn7IS9DAfB1RThP5cYq YAF8djsOmYYK7fILo/XrpR/TD5rGgoJRtg0BKimqqQIDxqm5SrcrWE62pgjo34/rbrdh 0EP8JxuHxL8ReJN5ekOR5UiCtrytxUiQkapuJ0ZY/HaVCTbsE8K8c55tgqDHssdPmx0S Ky/w== X-Received: by 10.224.4.74 with SMTP id 10mr21078684qaq.38.1370294432955; Mon, 03 Jun 2013 14:20:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Mon, 3 Jun 2013 14:20:12 -0700 (PDT) In-Reply-To: <51AD0472.9020506@alum.mit.edu> References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <51A8F3EF.9080702@alum.mit.edu> <51AD0472.9020506@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 3 Jun 2013 23:20:12 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl64orAKSWhtBQvztk8JxCh6XaZdDa3TsibZG2UUym/1E7WYB7cUmEMIzXrwhj5pCx0nSwA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:25:42 -0000 2013/6/3 Paul Kyzivat : > One answer may be that the difference is that the real-time requirements = for > text aren't as demanding as they are for voice or video. But there are ot= her > good reasons for identifying interactive text as media. One reason is wha= t > we are arguing right how: the desire to negotiate properties of the > transmission. (Should it be byte-by-byte or line-by-line.) Another is tha= t, > like voice and video there is likely to be a demand to record it for late= r > analysis and playback, or to broadcast it to a collection of people. > > When text is treated as media, then treating it in parallel with other me= dia > makes more sense. (For instance ensuring the that the text is synchronize= d > with the other media, both initially and when recorded and played back > later.) Well, I must recognize that now I see a real usecase: realtime subtitles synchronized with audio/video streams. That would be much better than the typicall subtitles embed in the video stream (because it could be rendered as real text, so the user could choose the text size, and so on). Problems of standarizing text over RTP: - Encoding - =C2=BFjust plain text? =C2=BFcould it be HTML code instead? =C2=BFhow to = send hyperlinks? =C2=BFhow to use custom markup? - Integrity: RTP can loose packets, do we accept that a chat can loose "chars" or "lines"? -- I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Jun 3 14:30:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAC211E80BA for ; Mon, 3 Jun 2013 14:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC6ujUlE7Uou for ; Mon, 3 Jun 2013 14:30:12 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1EA21F8F87 for ; Mon, 3 Jun 2013 14:24:00 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id n1so2436056qcw.41 for ; Mon, 03 Jun 2013 14:23: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=CKVVysBChD8g554DvNkNSE9IGoiD3uRHkS9s98wdSRI=; b=EmTaT629unI8jboU162ksCnVswZw2LwU4bmzss6DX5wyA3bd5+9PprdmdkSxsILh79 +Lxr9myw/oSc8NECxS9TTY0JxwdGBZNw63ucpuNi2io5GpMjg3+ikAIRAYAhPIdPXPRS PcDYSRQl5BGw+Lyub+kWLjgfGyC1Re5JaTbpQBXIQOnMg2a/nKsjdvuSU+AeOLTV3WdD h7wjv4ywD6q9sBb5PkNUOewJZi4Qf76oc5RGW4QMkzG+leqF7l8+xyY0gYvAR//V88H3 E2JoOKdNJz9y+OrVgIWM0+Qg7d9iPAWr6DCyQ1TKVB2UexlCu0l6WfzMYcq98zPoXo/y gctg== X-Received: by 10.49.96.10 with SMTP id do10mr13537061qeb.23.1370294637154; Mon, 03 Jun 2013 14:23:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Mon, 3 Jun 2013 14:23:36 -0700 (PDT) In-Reply-To: <51AD07B4.3070702@alum.mit.edu> References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> <51AD07B4.3070702@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 3 Jun 2013 23:23:36 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQna+JSL232HjW3npAex2qhQhE6nCBC9xX/t/KOylThUrODIn8kk13ZF0Uv1iPHMxsS+GHAx Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:30:22 -0000 2013/6/3 Paul Kyzivat : > I don't understand why we would be talking about translating from one of > these plans to another. AFAIK they are *alternatives*, and that we will a= t > some point agree on one, and that will be the only one implemented. +1 Just one please, just one... -- I=C3=B1aki Baz Castillo From emil@sip-communicator.org Mon Jun 3 14:40:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0BF11E80BA for ; Mon, 3 Jun 2013 14:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yORB6Xf0sz+L for ; Mon, 3 Jun 2013 14:40:16 -0700 (PDT) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id D4DBB11E8110 for ; Mon, 3 Jun 2013 14:36:31 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id d4so1245766eek.28 for ; Mon, 03 Jun 2013 14:36:31 -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=lLyWFIWkyfvQNpQn9mnOFSl/EDSOpRKLlX3jw/AbhoU=; b=nYaowk30nQWfp2R+4F7ASYWc6rlB69YIXBRJtRXnWrwEelVGnKJRp7463lSHOKQx+j bb/eenXkwYzKbSNe3wipgBAq5NAuywW3nLzT4Ki666BKCADFRsUMaL6UDnm+/58z+X3U jIeCFOm37LloQ9k+DFOQSRA4CGYzf9PCyo/d2tz+ynWCw2Y2auY1lm/TxQErzn7ymzoG s+J6i6x9NBz8VKfxsi6c8bF/EgmFTi2N83RSbKsMFdMCmdmZ+hrObgFGyxuWht43m1fC NS7/W4AZ/WEpzkR9NfvFLnauIPEEL53hMGQwMOPjdGwZAruSoDzqYntugmD81wvSJwDY 36Yw== X-Received: by 10.15.23.73 with SMTP id g49mr21715eeu.8.1370295390876; Mon, 03 Jun 2013 14:36:30 -0700 (PDT) Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id y44sm5813234eel.10.2013.06.03.14.36.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 14:36:30 -0700 (PDT) Message-ID: <51AD0C5B.6080508@jitsi.org> Date: Tue, 04 Jun 2013 00:36:27 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> <51AD07B4.3070702@alum.mit.edu> In-Reply-To: <51AD07B4.3070702@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlrVApGmtf/rj0PGH49NM/ZyaJ8k9KWHxj+Bt0wDwl0FOZaUslmsDU81smtaAY5OzleZbmU Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:40:27 -0000 On 04.06.13, 00:16, Paul Kyzivat wrote: > I don't understand why we would be talking about translating from one of > these plans to another. AFAIK they are *alternatives*, and that we will > at some point agree on one, and that will be the only one implemented. It has been pointed out that some existing non-WebRTC endpoints expect to get SDP "the Plan A way". Cullen asked how such devices could be made to communicate with "No Plan" browsers. This was my answer. Personally I haven't come across such devices so I can only speculate about the reasons why they work the way they work. Still I don't see why they shouldn't be able to talk to WebRTC browsers ... hence my answer. Emil > > Thanks, > Paul > > On 6/3/13 1:28 PM, Emil Ivov wrote: >> Hey Cullen, Paul, all >> >> On 31.05.13, 22:19, Cullen Jennings (fluffy) wrote: >>> On 31.05.2013, at 12:23 PM, Emil Ivov wrote: >>> >>>> Certainly. Could you please post the SDP that you would like to see >>>> translated in a way that's compatible with "No Plan"? >>>> >>>> Emil >>> >>> We can start with the SDP in plan A >> >> The example in "7.3. Many Videos" looks like a good start: >> >> http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00#section-7.3 >> >> Here it is: >> >> v=0 >> o=- 20518 0 IN IP4 198.51.100.1 >> s= >> t=0 0 >> c=IN IP4 203.0.113.1 >> a=ice-ufrag:F7gI >> a=ice-pwd:x9cml/YzichV2+XlhiMu8g >> a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7 >> a=group:BUNDLE m0 m1 m2 m3 >> >> m=audio 56600 RTP/SAVPF 0 96 >> a=mid:m0 >> a=rtpmap:0 PCMU/8000 >> a=rtpmap:96 opus/48000 >> a=ptime:20 >> a=sendrecv >> a=rtcp-mux >> [ICE Candidates] >> >> m=video 0 RTP/SAVPF 97 98 >> a=mid:m1 >> a=rtpmap:97 H264/90000 >> a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 >> a=rtpmap:98 VP8/90000 >> a=sendrecv >> a=rtcp-mux >> a=bundle-only >> a=ssrc:11111 cname:45:5f:fe:cb:81:e9 >> >> m=video 0 RTP/SAVPF 97 98 >> a=mid:m2 >> a=rtpmap:97 H264/90000 >> a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 >> a=rtpmap:98 VP8/90000 >> a=sendrecv >> a=rtcp-mux >> a=bundle-only >> a=ssrc:22222 cname:45:5f:fe:cb:81:e9 >> >> m=video 0 RTP/SAVPF 97 98 >> a=mid:m3 >> a=rtpmap:97 H264/90000 >> a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 >> a=rtpmap:98 VP8/90000 >> a=sendrecv >> a=rtcp-mux >> a=bundle-only >> a=ssrc:333333 cname:45:5f:fe:cb:81:e9 >> >> >> An offer generated by a "No Plan" browser in this case would look >> something like this: >> >> v=0 >> o=- 20518 0 IN IP4 198.51.100.1 >> s= >> t=0 0 >> c=IN IP4 203.0.113.1 >> a=ice-ufrag:F7gI >> a=ice-pwd:x9cml/YzichV2+XlhiMu8g >> a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7 >> a=group:BUNDLE m0 m1 >> >> m=audio 56600 RTP/SAVPF 96 0 >> a=mid:m0 >> a=rtpmap:96 opus/48000 >> a=rtpmap:0 PCMU/8000 >> a=ptime:20 >> a=sendrecv >> a=rtcp-mux >> [ICE candidates] >> >> m=video 56602 RTP/SAVPF 97 98 >> a=mid:m1 >> a=rtpmap:97 H264/90000 >> a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 >> a=rtpmap:98 VP8/90000 >> a=sendrecv >> a=rtcp-mux >> [ICE candidates] >> >> I. Talking to legacy >> >> In case you need to talk to an actual legacy (as in widely deployed SIP) >> endpoint, the above would translate into a regular two-stream call. Both >> Plan A and No Plan would lead to essentially the same result (if we >> accept that older endpoints won't throw an exception at the sight of 4 >> m= lines) so not much to discuss here. >> >> II. Talking to Plan A style endpoints >> >> If you need to talk to a Plan A endpoint you basically have the >> following options: >> >> 1. You use JavaScript to prettify the "No Plan" SDP and turn it into >> something that looks like "Plan A". Not my favourite option, but I am >> sure some would like to use it. Maybe vendors of Plan A equipment would >> even distribute JS libs that do this. It would basically all come down >> to generating one ssrc attribute and two additional m=lines and >> appending this to the existing SDP string. >> >> 2. The application retrieves SSRCs from the browser, adds additional >> application-specific signalling to it and then sends the whole thing to >> a signalling gateway. The gateway (which you would also have with Plan >> A) would convert the SDP into what it needs it to be. >> >> The application specific signalling can look like this: >> >> { >> "firstStream": >> { >> "SSRC": "11111", >> "CNAME": "45:5f:fe:cb:81:e9" >> }, >> "secondStream": >> { >> "SSRC": "22222", >> "CNAME": "45:5f:fe:cb:81:e9" >> }, >> "thirdStream": >> { >> "SSRC": "333333", >> "CNAME": "45:5f:fe:cb:81:e9" >> }, >> } >> >> 3. In Plan B, section 3.1 talks about generating "Plan A" style SDP with >> the help of .content properties. If browser vendors are willing to >> implement support for this then I suppose it would be a third option. >> >> III. Talking to other WebRTC applications >> >> This is the fun case and the one we should be most concerned with. Let's >> imagine that the answerer needs to add a fourth video stream. To make >> this work endpoints would need to do the following: >> >> a) with Plan A and draft-roach-rtcweb-glareless-add: >> - send application specific signalling to the offerer >> - have a new O/A exchange >> >> b) with Plan A: >> - have a new O/A exchange >> - potentially risk glare with some impact on user experience >> >> c) with No Plan: >> ... nothing >> >> I am intentionally not going into how all plans would require additional >> metadata that would place SSRC 1 left and 2 right as I don't think this >> conveys any meaningful differences. >> >> Comments on the above are welcome. We could also move to another >> scenario from the Plan A draft, if you believe that 7.3 is not >> representative enough. >> >> Emil >> >> > > -- https://jitsi.org From pkyzivat@alum.mit.edu Mon Jun 3 14:43:32 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBEB11E8109 for ; Mon, 3 Jun 2013 14:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.152 X-Spam-Level: X-Spam-Status: No, score=-0.152 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC7k8kQHprjQ for ; Mon, 3 Jun 2013 14:43:16 -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 E102A11E810A for ; Mon, 3 Jun 2013 14:40:31 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta02.westchester.pa.mail.comcast.net with comcast id joYh1l0050QuhwU51xgX04; Mon, 03 Jun 2013 21:40:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id jxgX1l00X3ZTu2S3NxgX07; Mon, 03 Jun 2013 21:40:31 +0000 Message-ID: <51AD0D4E.5000207@alum.mit.edu> Date: Mon, 03 Jun 2013 17:40:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <51A8F3EF.9080702@alum.mit.edu> <51AD0472.9020506@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370295631; bh=+M+LcvloESxZPidxvFO1DoHuay2qiAtoof4H4Gk8eeM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=keLXbJnfFzEYWq/crE5Yp6KxZCr4v2FVtgYfCzqUEJFdH34A814YaoO2Zkf/Qa9w+ T9Nhk7bnVL799cLTuYfdMytLh8luPakk+tPg8rd0UeFQmxyaUK6GNFaNdZmk84SDsD zAlO6XmPoCq6vaZemDNvb6iV2G6+GqYE9j5W4X99V+k7jFxPcbf1ajxGoFvEFS42Xs V2iwIzUN9AEINhR87TE/ZMyecqr2DWI9F7Wk4wWq3BWKBWCc35wJWp3HYwnOhID8/x ksY0+odcTJlvQoNx3cGZUA0uSOtKN+Blly00mBm7rtzKWTIWNaj2ObfqF53ZmV5stQ qkQqKAZOfkNvA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:43:32 -0000 RFC4103 On 6/3/13 5:20 PM, Iñaki Baz Castillo wrote: > 2013/6/3 Paul Kyzivat : > >> One answer may be that the difference is that the real-time requirements for >> text aren't as demanding as they are for voice or video. But there are other >> good reasons for identifying interactive text as media. One reason is what >> we are arguing right how: the desire to negotiate properties of the >> transmission. (Should it be byte-by-byte or line-by-line.) Another is that, >> like voice and video there is likely to be a demand to record it for later >> analysis and playback, or to broadcast it to a collection of people. >> >> When text is treated as media, then treating it in parallel with other media >> makes more sense. (For instance ensuring the that the text is synchronized >> with the other media, both initially and when recorded and played back >> later.) > > Well, I must recognize that now I see a real usecase: realtime > subtitles synchronized with audio/video streams. That would be much > better than the typicall subtitles embed in the video stream (because > it could be rendered as real text, so the user could choose the text > size, and so on). > > Problems of standarizing text over RTP: > > - Encoding > > - ¿just plain text? ¿could it be HTML code instead? ¿how to send > hyperlinks? ¿how to use custom markup? > > - Integrity: RTP can loose packets, do we accept that a chat can loose > "chars" or "lines"? > > > > > -- > Iñaki Baz Castillo > > From emil@sip-communicator.org Mon Jun 3 14:44:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C00511E812B for ; Mon, 3 Jun 2013 14:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vy53mG31dSXT for ; Mon, 3 Jun 2013 14:43:57 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3A28911E8100 for ; Mon, 3 Jun 2013 14:41:47 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id r16so3964942ead.27 for ; Mon, 03 Jun 2013 14:41:47 -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=iAVn7JmIAyoXP6XuLEhEhn0QIqt8GfvoR2uw9f/o/i4=; b=drQt/Guiv1V1Bk9WfDnfctzyWrF6SuZXV6X+pmlGoZgtqZrnQxSOHfCa2Rzf4YvN21 oeAcEe87iPeJuXp3rwcygRBmQ7/Visa1Ttl2N7b1ZROPZfrJRYFcN9p/QddPkGiDyQSN g/jh32hngS7XvrkpK5D7hBx9ulmQGNJFmyTHBkPoT9p3IVkHUOzu5/kkV3l3jIqXERPe Y6ArBv7p1GLO087e2A3QEEE6tbt4774MK4NcrCY8irIpcXSS7KTsPHvpniKaIWpO6ejk ymyyGK9s9avnqZ5xb010J6IqhChB/IrZsjNUkRPUXjr9DecfrNJoZfOvSFQpoGRN1NkE 4P7A== X-Received: by 10.15.68.194 with SMTP id w42mr10665354eex.59.1370295707154; Mon, 03 Jun 2013 14:41:47 -0700 (PDT) Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id y10sm87236674eev.3.2013.06.03.14.41.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 14:41:46 -0700 (PDT) Message-ID: <51AD0D98.2080302@jitsi.org> Date: Tue, 04 Jun 2013 00:41:44 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <51A65017.4090502@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se>, <51A9A7E2.7000907@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C380AA2@ESESSMB209.ericsson.se> <51ACFF31.9090607@alum.mit.edu> In-Reply-To: <51ACFF31.9090607@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmsF6wbNj9QKi0Akpw+0iD27lpWtyJO1trhcfLKm1lD7FyFdDkQBAmzh8+eITD0djmTHqI7 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:44:22 -0000 On 03.06.13, 23:40, Paul Kyzivat wrote: > +1 > > The more we dig into this the more it looks like Plan B. I am not sure exactly what you mean by this. I did try to make it clear that "No Plan" has a lot in common with "Plan B". The main differences are that there is no expectation for SSRCs to be pre-announced and there are requirements for WebRTC APIs to provide the tools necessary for apps to control individual streams themselves. Emil > > Thanks, > Paul > > On 6/1/13 7:05 AM, Christer Holmberg wrote: >> >> Hi, >> >>>> The draft says: >>>> >>>> "For the sake of interoperability this specification strongly advises >>>> against the use of multiple m= lines for a single media type." >>> >>> This should probably be clarified. The above referred mostly to a >>> browser's expectations and default offers. Multiple m= lines can confuse >>> a number of existing legacy endpoints which is why they should be >>> avoided when initiating a session that could reach a similar device (and >>> by default this should be assumed for any session). >>> >>> If applications *know* that they need to have multiple m= lines of a >>> given type they can request this the same way they could do it with Plan B: >>> >>> If the application wishes, it can request that a given >>> media source be placed onto a separate m= line, by setting a new >>> .content property on the desired MediaStreamTrack; the values for the >>> .content property are those defined for the a=content attribute in >>> [RFC4796]. >>> >>> I'll make sure this is part of the next version. >>> >>> Does this make sense? >> >> I have nothing against a general recommendation to, for a given media type, have as few m- lines as possible. >> >> But, I do think the draft need to point out that it is not always possible, e.g. because: >> >> 1) m- lines have different characteristics (normally indicated using SDP attributes) that does not "fit" all content for the given media type; >> 2) different protocols are used for different m- lines, even if the media type is the same; or >> 3) the remote endpoint only supports a single (or, another given number) of sources per m- line. >> >> Etc. >> >> Regards, >> >> Christer >> >> >> >> >> >>> My understanding is that the usage of multiple m= lines for a single media type would not affect the mechanism as such, but I just want to verify that :) >>> >>> Also, there ARE "legacy" implementations that use multiple m= lines for a single media type (e.g. video enabled devices using two video m= lines: one for camera content, and one for slides). >>> >>> So, while I definitely think that legacy interoperability shall be taken into consideration, I would not like to make such strong statements. In my opinion (the draft also talks about it), the usage of multiple simultaneous SSRCs per m- line is a much bigger issue when it comes to legacy interoperability. >>> >>> Also, in CLUE we have been working on signaling scenarios with multiple m= lines per media type. >> > >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Emil Ivov >>> Sent: 29. toukokuuta 2013 22:00 >>> To: rtcweb@ietf.org >>> Subject: [rtcweb] No Plan >>> >>> Hey all, >>> >>> Based on many of the discussions that we've had here, as well as many others that we've had offlist, it seemed like a good idea to investigate a negotiation alternative that relies on SDP and Offer/Answer just a little bit less. >>> >>> The following "no plan" draft attempts to present one such approach: >>> >>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>> >>> The draft relies on conventional use of SDP O/A but leaves the intricacies of multi-source scenarios to application-specific signalling, with potentially a little help from RTP. >>> >>> Hopefully, proponents of Plans A and B would find that the interoperability requirements that concerned them can still be met with "no plan". Of course they would have to be addressed by application-specific signalling and/or signalling gateways. >>> >>> Comments are welcome! >>> >>> Cheers, >>> Emil >>> >>> -- >>> https://jitsi.org >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> . >>> >> >> -- >> https://jitsi.org >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- https://jitsi.org From emil@sip-communicator.org Mon Jun 3 14:46:25 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D528511E80FC for ; Mon, 3 Jun 2013 14:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHFr0TktWdaI for ; Mon, 3 Jun 2013 14:46:11 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7950E21F8EFE for ; Mon, 3 Jun 2013 14:44:04 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id o14so1685675eaj.35 for ; Mon, 03 Jun 2013 14:44:03 -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=NhzK5ueQzSP3efUF3nWfJ9e7UdIXcFjOI2Hfmhuh57U=; b=UaP7ktLSTfpAxUohe7cxlJc2HBtug+qMbM85EEgL1yUGIH08y3Ncv0+WykfTvwfty5 Uhi+YuQClU+OZeJxF0X0lqk18pgxWkiDBHluLx4mL2L+p5Vjfv0G/m9iNKtP01wHMb3p 4ku1S3cL2//vLTfZYzl1x0YdCktVbD1Hulr/d2CX7/gJiVdOFfWrDwXTOSQxmwhzHX7C /8oIplM2wY1aO6GDD3wL1UYRvnlpHc0+cWu77a8uUwjh0moBy/xUl58+NYMT7i7QLZpl wN7HE64/ZO4//ZXHa+EdK5qrpQZYTPo+m9dX3Kir33SNE2hrocJqgSAdCgexqL5wo6Op H2oQ== X-Received: by 10.14.204.3 with SMTP id g3mr24584310eeo.85.1370295843547; Mon, 03 Jun 2013 14:44:03 -0700 (PDT) Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id b14sm16658410ees.16.2013.06.03.14.44.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 14:44:02 -0700 (PDT) Message-ID: <51AD0E20.1070901@jitsi.org> Date: Tue, 04 Jun 2013 00:44:00 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <51A65017.4090502@jitsi.org> <51A8EB7F.6000506@jitsi.org> <72B58042-78E3-4759-B3CD-204B82A38447@iii.ca> <51ACF998.5030202@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnrdzMkzCwPSD2gwUhH/L+B4IW6l3Dm52InLrIVzjEhnd9aTAwP7io37IHEzr75fCz4jMgO Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan - but what's the proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:46:25 -0000 On 04.06.13, 00:07, I=C3=B1aki Baz Castillo wrote: > 2013/6/3 Emil Ivov : >>>> We create an offer that would describe the media types and the bundl= e. We >>>> use that offer to also describe capabilities in terms of maximum >>>> resolutions, supported header extensions, potentially max-ssrc-s, et= c. >>>> >>>> It is up to the application how to handle the rest. If it needs to >>>> transmit additional signalling: let it. If it wants to encode that i= n SDP, >>>> great. If it wants to attach it in JSON next to the browser generate= d SDP, >>>> that also works. >>> >>> >>> Great - I have super news for you. The WG agree to do that a year or = more >>> ago. >> >> >> So I've heard indeed. >> >> Unfortunately however, it seems that we might have forgotten this deci= sion. >> We are now trying hard to come up with a signalling mechanism that wil= l do >> everything with Offer/Answer. > > > I think there is a misunderstanding here. I understand from Emil's > mail that media re-negotation or streams addition after the first SDP > O/A is not carried as a new full SDP O/A. Am I right? Correct. Unless of course these streams require new payload types to be=20 introduced, 5-tuples to be changed or other m=3D line parameters modified= =2E Emil --=20 https://jitsi.org From pkyzivat@alum.mit.edu Mon Jun 3 14:48:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EBA11E812D for ; Mon, 3 Jun 2013 14:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2f2f594eJ3q for ; Mon, 3 Jun 2013 14:48:18 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id BBDCC11E80F4 for ; Mon, 3 Jun 2013 14:45:30 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta10.westchester.pa.mail.comcast.net with comcast id jnHU1l0050bG4ec5AxlWkS; Mon, 03 Jun 2013 21:45:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id jxlV1l01J3ZTu2S3PxlWjm; Mon, 03 Jun 2013 21:45:30 +0000 Message-ID: <51AD0E78.8050100@alum.mit.edu> Date: Mon, 03 Jun 2013 17:45:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> <51AD07B4.3070702@alum.mit.edu> <51AD0C5B.6080508@jitsi.org> In-Reply-To: <51AD0C5B.6080508@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370295930; bh=vUflZPJP8xjJ1AK1x1wMf/Xvmxx4XC3Ks+EhUtW/mxI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZrLrleRTCXvJUsYcC95Y7gXnmgkTjx5g4/ooH5M6R3mg635g6vuOFrl2OlJOll7Kx DgjhMoOQox0jGc+iRCGkMD71pV5yjhBwIWJczzXcwYlxIvY5i9fHcZfTIgDgQxrnck Y8Aywbj8kd9ubAgZH5VenXK469eYEEbrRETlggxLOLhKjVCKrkdFjxyH1EOc1bekEQ B7cQMfSDzUZ3P2WNlxD0qNGTQyNW9a/K+jGQJboO6cpya3WiHdke1WvF++jVK4TI2u zqdPIcRQ4fzFw5xIqBpTiooVQMlX/L4Py8Vn8RE2qZxKFeY93WQjvnDZjnbmKHzw0J ehH2Jx9gu6cMA== Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:48:33 -0000 On 6/3/13 5:36 PM, Emil Ivov wrote: > On 04.06.13, 00:16, Paul Kyzivat wrote: >> I don't understand why we would be talking about translating from one of >> these plans to another. AFAIK they are *alternatives*, and that we will >> at some point agree on one, and that will be the only one implemented. > > It has been pointed out that some existing non-WebRTC endpoints expect > to get SDP "the Plan A way". Cullen asked how such devices could be made > to communicate with "No Plan" browsers. This was my answer. > > Personally I haven't come across such devices so I can only speculate > about the reasons why they work the way they work. Still I don't see why > they shouldn't be able to talk to WebRTC browsers ... hence my answer. They clearly *don'* expect to get it the Plan A way (bundled). I accept that there must be a variety of things that employ multiple (unbundled) m-lines, each on its own 5-tuple with one RTP stream. But that is not Plan A. You can view it as a special case of what I just responded to you on another thread (now on mmusic) where one end requires that a new media stream be on a different 5-tuple than those existing. Thanks, Paul > Emil > >> >> Thanks, >> Paul >> >> On 6/3/13 1:28 PM, Emil Ivov wrote: >>> Hey Cullen, Paul, all >>> >>> On 31.05.13, 22:19, Cullen Jennings (fluffy) wrote: >>>> On 31.05.2013, at 12:23 PM, Emil Ivov wrote: >>>> >>>>> Certainly. Could you please post the SDP that you would like to see >>>>> translated in a way that's compatible with "No Plan"? >>>>> >>>>> Emil >>>> >>>> We can start with the SDP in plan A >>> >>> The example in "7.3. Many Videos" looks like a good start: >>> >>> http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00#section-7.3 >>> >>> Here it is: >>> >>> v=0 >>> o=- 20518 0 IN IP4 198.51.100.1 >>> s= >>> t=0 0 >>> c=IN IP4 203.0.113.1 >>> a=ice-ufrag:F7gI >>> a=ice-pwd:x9cml/YzichV2+XlhiMu8g >>> a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7 >>> a=group:BUNDLE m0 m1 m2 m3 >>> >>> m=audio 56600 RTP/SAVPF 0 96 >>> a=mid:m0 >>> a=rtpmap:0 PCMU/8000 >>> a=rtpmap:96 opus/48000 >>> a=ptime:20 >>> a=sendrecv >>> a=rtcp-mux >>> [ICE Candidates] >>> >>> m=video 0 RTP/SAVPF 97 98 >>> a=mid:m1 >>> a=rtpmap:97 H264/90000 >>> a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 >>> a=rtpmap:98 VP8/90000 >>> a=sendrecv >>> a=rtcp-mux >>> a=bundle-only >>> a=ssrc:11111 cname:45:5f:fe:cb:81:e9 >>> >>> m=video 0 RTP/SAVPF 97 98 >>> a=mid:m2 >>> a=rtpmap:97 H264/90000 >>> a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 >>> a=rtpmap:98 VP8/90000 >>> a=sendrecv >>> a=rtcp-mux >>> a=bundle-only >>> a=ssrc:22222 cname:45:5f:fe:cb:81:e9 >>> >>> m=video 0 RTP/SAVPF 97 98 >>> a=mid:m3 >>> a=rtpmap:97 H264/90000 >>> a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 >>> a=rtpmap:98 VP8/90000 >>> a=sendrecv >>> a=rtcp-mux >>> a=bundle-only >>> a=ssrc:333333 cname:45:5f:fe:cb:81:e9 >>> >>> >>> An offer generated by a "No Plan" browser in this case would look >>> something like this: >>> >>> v=0 >>> o=- 20518 0 IN IP4 198.51.100.1 >>> s= >>> t=0 0 >>> c=IN IP4 203.0.113.1 >>> a=ice-ufrag:F7gI >>> a=ice-pwd:x9cml/YzichV2+XlhiMu8g >>> a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7 >>> a=group:BUNDLE m0 m1 >>> >>> m=audio 56600 RTP/SAVPF 96 0 >>> a=mid:m0 >>> a=rtpmap:96 opus/48000 >>> a=rtpmap:0 PCMU/8000 >>> a=ptime:20 >>> a=sendrecv >>> a=rtcp-mux >>> [ICE candidates] >>> >>> m=video 56602 RTP/SAVPF 97 98 >>> a=mid:m1 >>> a=rtpmap:97 H264/90000 >>> a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 >>> a=rtpmap:98 VP8/90000 >>> a=sendrecv >>> a=rtcp-mux >>> [ICE candidates] >>> >>> I. Talking to legacy >>> >>> In case you need to talk to an actual legacy (as in widely deployed SIP) >>> endpoint, the above would translate into a regular two-stream call. Both >>> Plan A and No Plan would lead to essentially the same result (if we >>> accept that older endpoints won't throw an exception at the sight of 4 >>> m= lines) so not much to discuss here. >>> >>> II. Talking to Plan A style endpoints >>> >>> If you need to talk to a Plan A endpoint you basically have the >>> following options: >>> >>> 1. You use JavaScript to prettify the "No Plan" SDP and turn it into >>> something that looks like "Plan A". Not my favourite option, but I am >>> sure some would like to use it. Maybe vendors of Plan A equipment would >>> even distribute JS libs that do this. It would basically all come down >>> to generating one ssrc attribute and two additional m=lines and >>> appending this to the existing SDP string. >>> >>> 2. The application retrieves SSRCs from the browser, adds additional >>> application-specific signalling to it and then sends the whole thing to >>> a signalling gateway. The gateway (which you would also have with Plan >>> A) would convert the SDP into what it needs it to be. >>> >>> The application specific signalling can look like this: >>> >>> { >>> "firstStream": >>> { >>> "SSRC": "11111", >>> "CNAME": "45:5f:fe:cb:81:e9" >>> }, >>> "secondStream": >>> { >>> "SSRC": "22222", >>> "CNAME": "45:5f:fe:cb:81:e9" >>> }, >>> "thirdStream": >>> { >>> "SSRC": "333333", >>> "CNAME": "45:5f:fe:cb:81:e9" >>> }, >>> } >>> >>> 3. In Plan B, section 3.1 talks about generating "Plan A" style SDP with >>> the help of .content properties. If browser vendors are willing to >>> implement support for this then I suppose it would be a third option. >>> >>> III. Talking to other WebRTC applications >>> >>> This is the fun case and the one we should be most concerned with. Let's >>> imagine that the answerer needs to add a fourth video stream. To make >>> this work endpoints would need to do the following: >>> >>> a) with Plan A and draft-roach-rtcweb-glareless-add: >>> - send application specific signalling to the offerer >>> - have a new O/A exchange >>> >>> b) with Plan A: >>> - have a new O/A exchange >>> - potentially risk glare with some impact on user experience >>> >>> c) with No Plan: >>> ... nothing >>> >>> I am intentionally not going into how all plans would require additional >>> metadata that would place SSRC 1 left and 2 right as I don't think this >>> conveys any meaningful differences. >>> >>> Comments on the above are welcome. We could also move to another >>> scenario from the Plan A draft, if you believe that 7.3 is not >>> representative enough. >>> >>> Emil >>> >>> >> >> > From pkyzivat@alum.mit.edu Mon Jun 3 14:50:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B5821F90A5 for ; Mon, 3 Jun 2013 14:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_17=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqMjNdyFSj+Z for ; Mon, 3 Jun 2013 14:50:28 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 19D4A11E8126 for ; Mon, 3 Jun 2013 14:48:09 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta08.westchester.pa.mail.comcast.net with comcast id jnS91l0021c6gX858xo9qc; Mon, 03 Jun 2013 21:48:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id jxo91l0053ZTu2S3jxo97G; Mon, 03 Jun 2013 21:48:09 +0000 Message-ID: <51AD0F18.5020202@alum.mit.edu> Date: Mon, 03 Jun 2013 17:48:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51A65017.4090502@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se>, <51A9A7E2.7000907@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C380AA2@ESESSMB209.ericsson.se> <51ACFF31.9090607@alum.mit.edu> <51AD0D98.2080302@jitsi.org> In-Reply-To: <51AD0D98.2080302@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370296089; bh=qrrgppz4EW9M2ZTnu5Dw+N3a6wYAYD/vZSZ9b490qe8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DET+jqKyd3YnTO048hMnQTNku02ZxnLCmvH7k0R9p4wigoC46zzycAmrQdEJImbs1 0boE9zxc69mce5yAa853KPO2MeLlpos8pc1gAAuHKuW5JDE02LnU9wYLNCN2Dsl2Xr xz7N/SGaRtRL6lauGaxlFDknY7WtvwdCPwxXHq3bsFPXMFFGe35BXUi+SGdBmz9zT5 uOMhe04AwsfvfnfxRwDmLV1rk/03N50OguBC+p7KORPf+u4aRPn5kh2L/ev8JU9uku EIjir6EKnHQkxMdrt2o/CNz4Qbw0VCcozAO63sheS0q3UGQ2wMQCQwPOEPE/JAaKM5 DuIg0RI4ErPSg== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:50:51 -0000 On 6/3/13 5:41 PM, Emil Ivov wrote: > > > On 03.06.13, 23:40, Paul Kyzivat wrote: >> +1 >> >> The more we dig into this the more it looks like Plan B. > > I am not sure exactly what you mean by this. I did try to make it clear > that "No Plan" has a lot in common with "Plan B". The main differences > are that there is no expectation for SSRCs to be pre-announced and there > are requirements for WebRTC APIs to provide the tools necessary for apps > to control individual streams themselves. I now think that it is enough like plan B that the two should be collapsed together. Make the signaling of the explicit SSRCs optional when there is some other mechanism to agree upon them. Thanks, Paul > Emil > >> >> Thanks, >> Paul >> >> On 6/1/13 7:05 AM, Christer Holmberg wrote: >>> >>> Hi, >>> >>>>> The draft says: >>>>> >>>>> "For the sake of interoperability this specification >>>>> strongly advises >>>>> against the use of multiple m= lines for a single media type." >>>> >>>> This should probably be clarified. The above referred mostly to a >>>> browser's expectations and default offers. Multiple m= lines can >>>> confuse >>>> a number of existing legacy endpoints which is why they should be >>>> avoided when initiating a session that could reach a similar device >>>> (and >>>> by default this should be assumed for any session). >>>> >>>> If applications *know* that they need to have multiple m= lines of a >>>> given type they can request this the same way they could do it with >>>> Plan B: >>>> >>>> If the application wishes, it can request that a given >>>> media source be placed onto a separate m= line, by setting a new >>>> .content property on the desired MediaStreamTrack; the values >>>> for the >>>> .content property are those defined for the a=content attribute in >>>> [RFC4796]. >>>> >>>> I'll make sure this is part of the next version. >>>> >>>> Does this make sense? >>> >>> I have nothing against a general recommendation to, for a given media >>> type, have as few m- lines as possible. >>> >>> But, I do think the draft need to point out that it is not always >>> possible, e.g. because: >>> >>> 1) m- lines have different characteristics (normally indicated using >>> SDP attributes) that does not "fit" all content for the given media >>> type; >>> 2) different protocols are used for different m- lines, even if the >>> media type is the same; or >>> 3) the remote endpoint only supports a single (or, another given >>> number) of sources per m- line. >>> >>> Etc. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>>> My understanding is that the usage of multiple m= lines for a single >>>> media type would not affect the mechanism as such, but I just want >>>> to verify that :) >>>> >>>> Also, there ARE "legacy" implementations that use multiple m= lines >>>> for a single media type (e.g. video enabled devices using two video >>>> m= lines: one for camera content, and one for slides). >>>> >>>> So, while I definitely think that legacy interoperability shall be >>>> taken into consideration, I would not like to make such strong >>>> statements. In my opinion (the draft also talks about it), the usage >>>> of multiple simultaneous SSRCs per m- line is a much bigger issue >>>> when it comes to legacy interoperability. >>>> >>>> Also, in CLUE we have been working on signaling scenarios with >>>> multiple m= lines per media type. >>> > >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>> Behalf Of Emil Ivov >>>> Sent: 29. toukokuuta 2013 22:00 >>>> To: rtcweb@ietf.org >>>> Subject: [rtcweb] No Plan >>>> >>>> Hey all, >>>> >>>> Based on many of the discussions that we've had here, as well as >>>> many others that we've had offlist, it seemed like a good idea to >>>> investigate a negotiation alternative that relies on SDP and >>>> Offer/Answer just a little bit less. >>>> >>>> The following "no plan" draft attempts to present one such approach: >>>> >>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>> >>>> The draft relies on conventional use of SDP O/A but leaves the >>>> intricacies of multi-source scenarios to application-specific >>>> signalling, with potentially a little help from RTP. >>>> >>>> Hopefully, proponents of Plans A and B would find that the >>>> interoperability requirements that concerned them can still be met >>>> with "no plan". Of course they would have to be addressed by >>>> application-specific signalling and/or signalling gateways. >>>> >>>> Comments are welcome! >>>> >>>> Cheers, >>>> Emil >>>> >>>> -- >>>> https://jitsi.org >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> . >>>> >>> >>> -- >>> https://jitsi.org >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > From jonathan@vidyo.com Mon Jun 3 15:07:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD22B11E814C for ; Mon, 3 Jun 2013 15:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVslP+dNdMbX for ; Mon, 3 Jun 2013 15:07:40 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.252]) by ietfa.amsl.com (Postfix) with ESMTP id 2477111E80F9 for ; Mon, 3 Jun 2013 15:04:04 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 3FC0D7A9643; Mon, 3 Jun 2013 18:04:01 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 92E847A9726; Mon, 3 Jun 2013 18:03:52 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Mon, 3 Jun 2013 18:01:25 -0400 From: Jonathan Lennox To: Paul Kyzivat Date: Mon, 3 Jun 2013 18:03:03 -0400 Thread-Topic: [rtcweb] No Plan Thread-Index: Ac5gpeQYUrL8sEaDRNOL8AoeTeLkoQ== Message-ID: <7426877E-42ED-400A-A264-39C692E71308@vidyo.com> References: <51A65017.4090502@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se>, <51A9A7E2.7000907@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C380AA2@ESESSMB209.ericsson.se> <51ACFF31.9090607@alum.mit.edu> In-Reply-To: <51ACFF31.9090607@alum.mit.edu> 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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 22:07:54 -0000 On Jun 3, 2013, at 4:40 PM, Paul Kyzivat wrote: > +1 >=20 > The more we dig into this the more it looks like Plan B. >=20 > Thanks, > Paul I think No Plan and Plan B are largely isomorphic in a WebRTC context. The= primary difference is that rather than using a=3Dssrc and a=3Dreceive-ssrc= (and whatever other Plan B attributes would be needed) to control sources = within an m-line, instead direct Javascript APIs are used for the same sema= ntics. It's up to the application to communicate the relevant information e= nd-to-end, in parallel to however it communicates the SDP blob. As I see it, the primary advantages of No Plan, then, are that: a) It allows "implicit" signaling of sources -- where that's sufficient -- = by just sending RTP traffic. This prevents problems related to the timing = and synchronization between signaling and media. (Note that Plan B probabl= y actually needs this as well, for legacy interop.) b) It carves a Comment 22 corner out of the SDP-based APIs, thus decoupling= source signaling from SDP offer/answer. This is for a scenario where ther= e aren't any issues of legacy compatibility, and there isn't any (or at lea= st much) existing IETF standardization -- as best I can recall, legacy comp= atibility and existing standardization were the primary motivations for usi= ng SDP as the WebRTC API. Other than that, I think the two proposals are pretty similar for WebRTC, a= nd it would probably be a Simple Matter of Programming to translate between= the two (though you have to worry about the O/A state on the Plan B side). In particular, if you have disaggregated media, you need multiple m-lines o= f the same type. The No Plan document's suggestion that you offer only one= m-line of a given media type is guidance on how to avoid interop failures = on initial offers to legacy devices, I think, not an essential aspect of th= e proposal. In a SIP context, No Plan requires defining a separate signaling channel fo= r this source information, in scenarios where something beyond implicit sig= naling is needed. As Emil has stated, I think that something like the SIP/= XCon conference package, or something like the CLUE channel, would be the o= bvious places to start. I think SIP, even more than RTCWeb, is where you'd want something lighter-w= eight and better-designed than SDP offer/answer to signal source changes. > On 6/1/13 7:05 AM, Christer Holmberg wrote: >>=20 >> Hi, >>=20 >>>> The draft says: >>>>=20 >>>> "For the sake of interoperability this specification strongly ad= vises >>>> against the use of multiple m=3D lines for a single media type." >>>=20 >>> This should probably be clarified. The above referred mostly to a >>> browser's expectations and default offers. Multiple m=3D lines can conf= use >>> a number of existing legacy endpoints which is why they should be >>> avoided when initiating a session that could reach a similar device (an= d >>> by default this should be assumed for any session). >>>=20 >>> If applications *know* that they need to have multiple m=3D lines of a >>> given type they can request this the same way they could do it with Pla= n B: >>>=20 >>> If the application wishes, it can request that a given >>> media source be placed onto a separate m=3D line, by setting a new >>> .content property on the desired MediaStreamTrack; the values for th= e >>> .content property are those defined for the a=3Dcontent attribute in >>> [RFC4796]. >>>=20 >>> I'll make sure this is part of the next version. >>>=20 >>> Does this make sense? >>=20 >> I have nothing against a general recommendation to, for a given media ty= pe, have as few m- lines as possible. >>=20 >> But, I do think the draft need to point out that it is not always possib= le, e.g. because: >>=20 >> 1) m- lines have different characteristics (normally indicated using SDP= attributes) that does not "fit" all content for the given media type; >> 2) different protocols are used for different m- lines, even if the medi= a type is the same; or >> 3) the remote endpoint only supports a single (or, another given number)= of sources per m- line. >>=20 >> Etc. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >>> My understanding is that the usage of multiple m=3D lines for a single = media type would not affect the mechanism as such, but I just want to verif= y that :) >>>=20 >>> Also, there ARE "legacy" implementations that use multiple m=3D lines f= or a single media type (e.g. video enabled devices using two video m=3D lin= es: one for camera content, and one for slides). >>>=20 >>> So, while I definitely think that legacy interoperability shall be take= n into consideration, I would not like to make such strong statements. In m= y opinion (the draft also talks about it), the usage of multiple simultaneo= us SSRCs per m- line is a much bigger issue when it comes to legacy interop= erability. >>>=20 >>> Also, in CLUE we have been working on signaling scenarios with multiple= m=3D lines per media type. >>>=20 >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behal= f Of Emil Ivov >>> Sent: 29. toukokuuta 2013 22:00 >>> To: rtcweb@ietf.org >>> Subject: [rtcweb] No Plan >>>=20 >>> Hey all, >>>=20 >>> Based on many of the discussions that we've had here, as well as many o= thers that we've had offlist, it seemed like a good idea to investigate a n= egotiation alternative that relies on SDP and Offer/Answer just a little bi= t less. >>>=20 >>> The following "no plan" draft attempts to present one such approach: >>>=20 >>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>=20 >>> The draft relies on conventional use of SDP O/A but leaves the intricac= ies of multi-source scenarios to application-specific signalling, with pote= ntially a little help from RTP. >>>=20 >>> Hopefully, proponents of Plans A and B would find that the interoperabi= lity requirements that concerned them can still be met with "no plan". Of c= ourse they would have to be addressed by application-specific signalling an= d/or signalling gateways. >>>=20 >>> Comments are welcome! >>>=20 >>> Cheers, >>> Emil >>>=20 >>> -- >>> https://jitsi.org >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> . >>>=20 >>=20 >> -- >> https://jitsi.org >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 -- Jonathan Lennox jonathan@vidyo.com From ron.even.tlv@gmail.com Mon Jun 3 15:11:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B3C11E812B for ; Mon, 3 Jun 2013 15:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcCStcIiFyb6 for ; Mon, 3 Jun 2013 15:10:50 -0700 (PDT) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id C3F2611E8130 for ; Mon, 3 Jun 2013 15:06:27 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id e52so401335eek.38 for ; Mon, 03 Jun 2013 15:06:27 -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=WPzdyRhDK4HwaWxVe/19R+3o/JWqOBOp2iNk77efwHw=; b=vgIoMC40cDApD4HoJTyO/vtnZkV4jX+qmUT/LwKlNElcH1np7Kjux5xcpkUr+6JQDP mAGWJUKab/hIS7GpNEmgZT3DKdXsj1fevG868HD4h+RyEZe8Iq+rvLNdmg1WEFuJtr39 GIjfzjmxlpgqqATKUAE6mmf1oOBRjHFZiLyFI7q+brzhoISrMEx957RNFq0gzxUfeFe3 YHFWZUQdusY+GpfTU1g1KRrgbsziMfyLYoCc8np0wetie2hZgSZPR02K8N5UF2cWFRzi vQUjg8zmIqTnXTCOsnDfvGCRl0x1vxXOVSNi4/qGwLbkBzm5ZNSptZ0erraWBpyS6jF4 wGNw== X-Received: by 10.14.176.66 with SMTP id a42mr14200046eem.150.1370297186941; Mon, 03 Jun 2013 15:06:26 -0700 (PDT) Received: from RoniE ([109.64.225.31]) by mx.google.com with ESMTPSA id s43sm87435679eem.13.2013.06.03.15.06.25 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Jun 2013 15:06:26 -0700 (PDT) From: "Roni Even" To: "'Emil Ivov'" References: <020e01ce6045$4b07dee0$e1179ca0$@gmail.com> <51AC73EE.5080603@jitsi.org> In-Reply-To: <51AC73EE.5080603@jitsi.org> Date: Tue, 4 Jun 2013 01:05:12 +0300 Message-ID: <026201ce60a6$6d406f20$47c14d60$@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: AQHEV3fVemrzw+HEHjK3xmr9l9tOLgGVpZeUmSvwXdA= Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan - SDP offer/answer clarification X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 22:11:11 -0000 Hi Emil, My understanding is that you propose to de-multiplex by the pt number so you cannot have two rtp streams with the same payload type number Roni > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: 03 June, 2013 1:46 PM > To: Roni Even > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] No Plan - SDP offer/answer clarification > > Hey Roni, > > On 03.06.13, 13:29, Roni Even wrote: > > Hi, > > I read the draft and the email thread and I think I have similar > > questions to the ones Cullen made. > > My understanding was that the proposal is to do one SDP offer/ answer > > exchange and add remove streams using other means (not specified) > > Yes, this is exactly it. > > > I looked at the offer example is section 3 and it has > > > > a=max-send-ssrc:{*:1} // declaring maximum > > a=max-recv-ssrc:{*:4} // number of SSRCs > > > > I have some clarifying questions? > > > > 1. Is the proposal to always offer max-send-ssrc=1? > > > > 2. What is the answer in this case can it be max-send-ssrc=4? > > The max-ssrc in the SDP was just an example for capabilities that the offerer > could add to SDP (could be useful for mobile devices for example). It is by no > means essential to the approach. > > > 3. If max-send-ssrc >1 in the answer and the m-line has, for example, > > support for H.264 and VP8 with max-send-ssrc=2 and de-multiplexing is > > based on pt number, it will require four pt in the m-line since there > > can be two > > VP8 or two H.264 RTP streams > > > > m=video 5002 RTP/SAVPF 97 98 99 100 > > a=mid:video > > a=rtcp-mux > > a=rtpmap:97 VP8/90000 > > a=rtpmap:98 VP8/90000 > > a=rtpmap:99 H264/90000 > > a=rtpmap:100 H264/90000 > > Is my understanding correct? > > Can you help me understand why you need the PT duplication? Is this just so > that you could understand distinguish between two sources? If so, then it > wouldn't be necessary. > > With No Plan you would just send: > > m=video 5002 RTP/SAVPF 97 99 > a=mid:video > a=rtcp-mux > a=rtpmap:97 VP8/90000 > a=rtpmap:99 H264/90000 > > If then you want to have one of the VP8 streams rendered on the left screen > and the other on the right, you will add this in application-specific signalling. A > web application could do this like this: > > { > "leftSSRC": "1234", > "rightSSRC": "5678" > } > > An WebRTC-to-SIP gateway could transform this into SDP or whatever that > target devices need. > > Does this answer your question? > > Emil > > > > > > > > > Roni > > > > > > > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Emil Ivov > >> Sent: 29 May, 2013 10:00 PM > >> To: rtcweb@ietf.org > >> Subject: [rtcweb] No Plan > >> > >> Hey all, > >> > >> Based on many of the discussions that we've had here, as well as many > >> others that we've had offlist, it seemed like a good idea to investigate a > >> negotiation alternative that relies on SDP and Offer/Answer just a little > > bit > >> less. > >> > >> The following "no plan" draft attempts to present one such approach: > >> > >> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan > >> > >> The draft relies on conventional use of SDP O/A but leaves the intricacies > > of > >> multi-source scenarios to application-specific signalling, with > > potentially a > >> little help from RTP. > >> > >> Hopefully, proponents of Plans A and B would find that the > > interoperability > >> requirements that concerned them can still be met with "no plan". Of > > course > >> they would have to be addressed by application-specific signalling and/or > >> signalling gateways. > >> > >> Comments are welcome! > >> > >> Cheers, > >> Emil > >> > >> -- > >> https://jitsi.org > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > -- > https://jitsi.org From jim.barnett@genesyslab.com Mon Jun 3 15:25:21 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A107F11E80FD for ; Mon, 3 Jun 2013 15:25:21 -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=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQny9BMh-3oo for ; Mon, 3 Jun 2013 15:25:06 -0700 (PDT) Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1F65811E80EE for ; Mon, 3 Jun 2013 15:16:28 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.3 [168.75.250.3]) (Using TLS) by service108-us.mimecast.com; Mon, 03 Jun 2013 18:16:26 -0400 Received: from GENSJZMBX02.msg.int.genesyslab.com ([fe80::64cd:bb44:81d2:5bca]) by GENSJZFE01.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 15:16:20 -0700 From: Jim Barnett To: Jonathan Lennox , Paul Kyzivat Thread-Topic: [rtcweb] No Plan Thread-Index: AQHOXJ6v5WcceEZDY0uDAnr1q0B+epkdzxyAgAMmgACAADZlgIADxTeAgAAXIID//42+cA== Date: Mon, 3 Jun 2013 22:16:19 +0000 Message-ID: <57A15FAF9E58F841B2B1651FFE16D2810437BF@GENSJZMBX02.msg.int.genesyslab.com> References: <51A65017.4090502@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se>, <51A9A7E2.7000907@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C380AA2@ESESSMB209.ericsson.se> <51ACFF31.9090607@alum.mit.edu> <7426877E-42ED-400A-A264-39C692E71308@vidyo.com> In-Reply-To: <7426877E-42ED-400A-A264-39C692E71308@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.7.220.231] MIME-Version: 1.0 X-MC-Unique: 113060318162603802 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 22:25:21 -0000 Just checking if I understand No Plan: since the bundling is added via JS = APIs, and not SDP, then if the app looks at=20 The localDescription and remoteDescription attributes of the PeerConnection= , it won't be able to tell if sources are bundled or not (since localDescri= ption and remoteDescription are defined to contain SDP) - Jim -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Jonathan Lennox Sent: Monday, June 03, 2013 6:03 PM To: Paul Kyzivat Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan On Jun 3, 2013, at 4:40 PM, Paul Kyzivat wrote: > +1 >=20 > The more we dig into this the more it looks like Plan B. >=20 > =09Thanks, > =09Paul I think No Plan and Plan B are largely isomorphic in a WebRTC context. The= primary difference is that rather than using a=3Dssrc and a=3Dreceive-ssrc= (and whatever other Plan B attributes would be needed) to control sources = within an m-line, instead direct Javascript APIs are used for the same sema= ntics. It's up to the application to communicate the relevant information e= nd-to-end, in parallel to however it communicates the SDP blob. As I see it, the primary advantages of No Plan, then, are that: a) It allows "implicit" signaling of sources -- where that's sufficient -- = by just sending RTP traffic. This prevents problems related to the timing = and synchronization between signaling and media. (Note that Plan B probabl= y actually needs this as well, for legacy interop.) b) It carves a Comment 22 corner out of the SDP-based APIs, thus decoupling= source signaling from SDP offer/answer. This is for a scenario where ther= e aren't any issues of legacy compatibility, and there isn't any (or at lea= st much) existing IETF standardization -- as best I can recall, legacy comp= atibility and existing standardization were the primary motivations for usi= ng SDP as the WebRTC API. Other than that, I think the two proposals are pretty similar for WebRTC, a= nd it would probably be a Simple Matter of Programming to translate between= the two (though you have to worry about the O/A state on the Plan B side). In particular, if you have disaggregated media, you need multiple m-lines o= f the same type. The No Plan document's suggestion that you offer only one= m-line of a given media type is guidance on how to avoid interop failures = on initial offers to legacy devices, I think, not an essential aspect of th= e proposal. In a SIP context, No Plan requires defining a separate signaling channel fo= r this source information, in scenarios where something beyond implicit sig= naling is needed. As Emil has stated, I think that something like the SIP/= XCon conference package, or something like the CLUE channel, would be the o= bvious places to start. I think SIP, even more than RTCWeb, is where you'd want something lighter-w= eight and better-designed than SDP offer/answer to signal source changes. > On 6/1/13 7:05 AM, Christer Holmberg wrote: >>=20 >> Hi, >>=20 >>>> The draft says: >>>>=20 >>>> "For the sake of interoperability this specification strongly ad= vises >>>> against the use of multiple m=3D lines for a single media type." >>>=20 >>> This should probably be clarified. The above referred mostly to a=20 >>> browser's expectations and default offers. Multiple m=3D lines can=20 >>> confuse a number of existing legacy endpoints which is why they=20 >>> should be avoided when initiating a session that could reach a=20 >>> similar device (and by default this should be assumed for any session). >>>=20 >>> If applications *know* that they need to have multiple m=3D lines of a= =20 >>> given type they can request this the same way they could do it with Pla= n B: >>>=20 >>> If the application wishes, it can request that a given >>> media source be placed onto a separate m=3D line, by setting a new >>> .content property on the desired MediaStreamTrack; the values for th= e >>> .content property are those defined for the a=3Dcontent attribute in >>> [RFC4796]. >>>=20 >>> I'll make sure this is part of the next version. >>>=20 >>> Does this make sense? >>=20 >> I have nothing against a general recommendation to, for a given media ty= pe, have as few m- lines as possible. >>=20 >> But, I do think the draft need to point out that it is not always possib= le, e.g. because: >>=20 >> 1) m- lines have different characteristics (normally indicated using=20 >> SDP attributes) that does not "fit" all content for the given media=20 >> type; >> 2) different protocols are used for different m- lines, even if the=20 >> media type is the same; or >> 3) the remote endpoint only supports a single (or, another given number)= of sources per m- line. >>=20 >> Etc. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >>> My understanding is that the usage of multiple m=3D lines for a single= =20 >>> media type would not affect the mechanism as such, but I just want=20 >>> to verify that :) >>>=20 >>> Also, there ARE "legacy" implementations that use multiple m=3D lines f= or a single media type (e.g. video enabled devices using two video m=3D lin= es: one for camera content, and one for slides). >>>=20 >>> So, while I definitely think that legacy interoperability shall be take= n into consideration, I would not like to make such strong statements. In m= y opinion (the draft also talks about it), the usage of multiple simultaneo= us SSRCs per m- line is a much bigger issue when it comes to legacy interop= erability. >>>=20 >>> Also, in CLUE we have been working on signaling scenarios with multiple= m=3D lines per media type. >>>=20 >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >>> Behalf Of Emil Ivov >>> Sent: 29. toukokuuta 2013 22:00 >>> To: rtcweb@ietf.org >>> Subject: [rtcweb] No Plan >>>=20 >>> Hey all, >>>=20 >>> Based on many of the discussions that we've had here, as well as many o= thers that we've had offlist, it seemed like a good idea to investigate a n= egotiation alternative that relies on SDP and Offer/Answer just a little bi= t less. >>>=20 >>> The following "no plan" draft attempts to present one such approach: >>>=20 >>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>=20 >>> The draft relies on conventional use of SDP O/A but leaves the intricac= ies of multi-source scenarios to application-specific signalling, with pote= ntially a little help from RTP. >>>=20 >>> Hopefully, proponents of Plans A and B would find that the interoperabi= lity requirements that concerned them can still be met with "no plan". Of c= ourse they would have to be addressed by application-specific signalling an= d/or signalling gateways. >>>=20 >>> Comments are welcome! >>>=20 >>> Cheers, >>> Emil >>>=20 >>> -- >>> https://jitsi.org >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> . >>>=20 >>=20 >> -- >> https://jitsi.org >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 -- Jonathan Lennox jonathan@vidyo.com _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From ron.even.tlv@gmail.com Mon Jun 3 15:34:41 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAE711E811B for ; Mon, 3 Jun 2013 15:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLj7tnAgQH5D for ; Mon, 3 Jun 2013 15:34:29 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4320811E812E for ; Mon, 3 Jun 2013 15:29:00 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id o14so1709311eaj.35 for ; Mon, 03 Jun 2013 15:28:59 -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=ZICQi42slqLYa20TOukU6MRxWgtt06RKkuVEK4QpQlw=; b=jcKcaoRe8QfJvsqaozFEjj7y3umGOuKfaiJCdr/ml5XTVC1AfTc9eQHYlEjH6BoI0I KMttcTTyRawZKIjruJPCVo65i1B0n1Go36du4cLoQOKFcO6umaH+fe7BTAuKOglIHvii R7s91AEk514zLHcq+PdJaz4eK+4Vud9AtAsn6wpcGLacaCe1JDExPuOMPzf45PDS0wL4 fgTQq6+LNBlv3mJ75pRNWD+64WoNFZ6dot7JTBHafY/zpqYObJTy/wHgH8DRZJEgmD/p a2dLzC1NOfjAqJG1g/GMuwWyNq14uzNk3zsZ7NaWxowavvM8+/NwHJoeI0lrtOi40f++ g6TQ== X-Received: by 10.14.2.199 with SMTP id 47mr24378831eef.131.1370298539349; Mon, 03 Jun 2013 15:28:59 -0700 (PDT) Received: from RoniE ([109.64.225.31]) by mx.google.com with ESMTPSA id g7sm87817863eew.15.2013.06.03.15.28.57 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Jun 2013 15:28:58 -0700 (PDT) From: "Roni Even" To: "'Emil Ivov'" , "'Cullen Jennings \(fluffy\)'" References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> In-Reply-To: <51ACD224.8080100@jitsi.org> Date: Tue, 4 Jun 2013 01:27:44 +0300 Message-ID: <026601ce60a9$935dca60$ba195f20$@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: AQKY1+pHnunKeTVQ57jkMHJdmrnDtABcFAfPAX32L6oBX6G4ywHAYU4IAr9kYt0CEayFy5dBR3yg Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 22:34:41 -0000 Emil, I assume that in the example of no-plan the m-video section should have a=max-send-ssrc:{*:3} and a=max-recv-ssrc:{*:3} I had the other thread about the de-mux but this also shows my question, the document says " This specification uses demuxing based on RTP payload types." But in this example they are not unique, you may have three RTP streams with the same pt number to de-mux using only pt-number. If you use max-send-ssrc to indicate the number of send streams, if you add a stream you need to update the max-send-ssrc Roni > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Emil Ivov > Sent: 03 June, 2013 8:28 PM > To: Cullen Jennings (fluffy) > Cc: rtcweb@ietf.org > Subject: [rtcweb] Translating Plan A into No Plan (Was: No Plan) > > Hey Cullen, Paul, all > > On 31.05.13, 22:19, Cullen Jennings (fluffy) wrote: > > On 31.05.2013, at 12:23 PM, Emil Ivov wrote: > > > >> Certainly. Could you please post the SDP that you would like to see > >> translated in a way that's compatible with "No Plan"? > >> > >> Emil > > > > We can start with the SDP in plan A > > The example in "7.3. Many Videos" looks like a good start: > > http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00#section-7.3 > > Here it is: > > v=0 > o=- 20518 0 IN IP4 198.51.100.1 > s= > t=0 0 > c=IN IP4 203.0.113.1 > a=ice-ufrag:F7gI > a=ice-pwd:x9cml/YzichV2+XlhiMu8g > a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7 > a=group:BUNDLE m0 m1 m2 m3 > > m=audio 56600 RTP/SAVPF 0 96 > a=mid:m0 > a=rtpmap:0 PCMU/8000 > a=rtpmap:96 opus/48000 > a=ptime:20 > a=sendrecv > a=rtcp-mux > [ICE Candidates] > > m=video 0 RTP/SAVPF 97 98 > a=mid:m1 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 > a=rtpmap:98 VP8/90000 > a=sendrecv > a=rtcp-mux > a=bundle-only > a=ssrc:11111 cname:45:5f:fe:cb:81:e9 > > m=video 0 RTP/SAVPF 97 98 > a=mid:m2 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 > a=rtpmap:98 VP8/90000 > a=sendrecv > a=rtcp-mux > a=bundle-only > a=ssrc:22222 cname:45:5f:fe:cb:81:e9 > > m=video 0 RTP/SAVPF 97 98 > a=mid:m3 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 > a=rtpmap:98 VP8/90000 > a=sendrecv > a=rtcp-mux > a=bundle-only > a=ssrc:333333 cname:45:5f:fe:cb:81:e9 > > > An offer generated by a "No Plan" browser in this case would look something > like this: > > v=0 > o=- 20518 0 IN IP4 198.51.100.1 > s= > t=0 0 > c=IN IP4 203.0.113.1 > a=ice-ufrag:F7gI > a=ice-pwd:x9cml/YzichV2+XlhiMu8g > a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7 > a=group:BUNDLE m0 m1 > > m=audio 56600 RTP/SAVPF 96 0 > a=mid:m0 > a=rtpmap:96 opus/48000 > a=rtpmap:0 PCMU/8000 > a=ptime:20 > a=sendrecv > a=rtcp-mux > [ICE candidates] > > m=video 56602 RTP/SAVPF 97 98 > a=mid:m1 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 > a=rtpmap:98 VP8/90000 > a=sendrecv > a=rtcp-mux > [ICE candidates] > > I. Talking to legacy > > In case you need to talk to an actual legacy (as in widely deployed SIP) > endpoint, the above would translate into a regular two-stream call. Both Plan > A and No Plan would lead to essentially the same result (if we accept that > older endpoints won't throw an exception at the sight of 4 m= lines) so not > much to discuss here. > > II. Talking to Plan A style endpoints > > If you need to talk to a Plan A endpoint you basically have the following > options: > > 1. You use JavaScript to prettify the "No Plan" SDP and turn it into something > that looks like "Plan A". Not my favourite option, but I am sure some would > like to use it. Maybe vendors of Plan A equipment would even distribute JS > libs that do this. It would basically all come down to generating one ssrc > attribute and two additional m=lines and appending this to the existing SDP > string. > > 2. The application retrieves SSRCs from the browser, adds additional > application-specific signalling to it and then sends the whole thing to a > signalling gateway. The gateway (which you would also have with Plan > A) would convert the SDP into what it needs it to be. > > The application specific signalling can look like this: > > { > "firstStream": > { > "SSRC": "11111", > "CNAME": "45:5f:fe:cb:81:e9" > }, > "secondStream": > { > "SSRC": "22222", > "CNAME": "45:5f:fe:cb:81:e9" > }, > "thirdStream": > { > "SSRC": "333333", > "CNAME": "45:5f:fe:cb:81:e9" > }, > } > > 3. In Plan B, section 3.1 talks about generating "Plan A" style SDP with the > help of .content properties. If browser vendors are willing to implement > support for this then I suppose it would be a third option. > > III. Talking to other WebRTC applications > > This is the fun case and the one we should be most concerned with. Let's > imagine that the answerer needs to add a fourth video stream. To make this > work endpoints would need to do the following: > > a) with Plan A and draft-roach-rtcweb-glareless-add: > - send application specific signalling to the offerer > - have a new O/A exchange > > b) with Plan A: > - have a new O/A exchange > - potentially risk glare with some impact on user experience > > c) with No Plan: > ... nothing > > I am intentionally not going into how all plans would require additional > metadata that would place SSRC 1 left and 2 right as I don't think this conveys > any meaningful differences. > > Comments on the above are welcome. We could also move to another > scenario from the Plan A draft, if you believe that 7.3 is not representative > enough. > > Emil > > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Mon Jun 3 15:53:56 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A618221F9811 for ; Mon, 3 Jun 2013 15:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.698 X-Spam-Level: X-Spam-Status: No, score=-100.698 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNMnmOIB4bH8 for ; Mon, 3 Jun 2013 15:53:41 -0700 (PDT) Received: from blu0-omc1-s9.blu0.hotmail.com (blu0-omc1-s9.blu0.hotmail.com [65.55.116.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5518021F96F5 for ; Mon, 3 Jun 2013 15:50:17 -0700 (PDT) Received: from BLU169-W120 ([65.55.116.8]) by blu0-omc1-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Jun 2013 15:50:17 -0700 X-TMN: [tGbyj8NB041ow7cFKRtOIYLl5CKX2HaEGtxxgrwo+mc=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_24ae2d5c-8e9e-4330-89b3-e5312c0823c9_" From: Bernard Aboba To: Jonathan Lennox Date: Mon, 3 Jun 2013 15:50:16 -0700 Importance: Normal In-Reply-To: <7426877E-42ED-400A-A264-39C692E71308@vidyo.com> References: <51A65017.4090502@jitsi.org>, <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se>, , <51A9A7E2.7000907@jitsi.org>, <7594FB04B1934943A5C02806D1A2204B1C380AA2@ESESSMB209.ericsson.se>, <51ACFF31.9090607@alum.mit.edu>, <7426877E-42ED-400A-A264-39C692E71308@vidyo.com> MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2013 22:50:17.0084 (UTC) FILETIME=[B7932BC0:01CE60AC] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 22:53:56 -0000 --_24ae2d5c-8e9e-4330-89b3-e5312c0823c9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jonathan said: =20 "I think No Plan and Plan B are largely isomorphic in a WebRTC context. Th= e primary difference is that rather than using a=3Dssrc and a=3Dreceive-ssr= c (and whatever other Plan B attributes would be needed) to control sources= within an m-line=2C instead direct Javascript APIs are used for the same s= emantics. It's up to the application to communicate the relevant informatio= n end-to-end=2C in parallel to however it communicates the SDP blob." =20 [BA] The use of O/A to turn sources on/off is definitely one thing that "No= Plan" avoids=2C and that's something in its favor. However=2C I don't thi= nk that's the only difference.=20 =20 As I see it=2C No Plan=2C when added to Plan B=2C results in simplification= s along several dimensions. I don't think that No Plan prohibits use of a= =3Dssrc lines either in the API or over the wire=2C but it does makes it cl= ear that they cannot be required for de-multiplexing (which No Plan handles= via PTs) or rendering of incoming streams (which can be handled via APIs w= ithout MSID declarations). Basically=2C No Plan says "Don't try to Bundle = more things than you can de-multiplex using PTs". It's a bit like telling = a snake "don't eat an elephant whole=2C chop it up into bit sized pieces". = Yes=2C you could try it the other way=2C=2C but is the added complexity (a= nd indigestion) really worth it?=20 =20 Personally I wouldn't say it is a "No Plan" no-no if createOffer were to pr= oduce SDP with a=3Dssrc lines=2C or if setRemoteDescription were to process= a=3Dssrc lines included by the remote peer. What I think No Plan would ha= ve a problem with is if undeclared sources couldn't be rendered=2C or if O/= A were required to turn already declared sources on/off=2C which can happen= so rapidly that O/A couldn't possibly handle it. Also=2C requiring O/A fo= r dropping streams breaks congestion control because in a highly congested = situation=2C the signaling packets would probably get dropped along with th= e media=2C so that the signaling to drop streams couldn't get through. A s= ender MUST be able to drop streams in that circumstance.=20 =20 In answer to questions about "whether you can declare separate streams for = screen sharing versus other video" I would think that No Plan could allow a= =3Dssrc lines for that=2C but if you just wanted to send them and have the = application figure out which was which (e.g. via app-specific signaling) yo= u could do that too. =20 =20 One area where I think all the Plans are weak is handling simulcast/layere= d streams. I don't think max*sssrc makes sense because it groups together = sources=2C and streams (including simulcast=2C layered streams and FEC). A= receiver really needs to be able to declare the maximum number of sources = it can receive and the maximum number of streams it can send=2C as well as = declaring the simulcast and layering schemes it can handle. This is NOT th= e same as actually stating what it will be sending or receiving at any give= n moment. In general=2C it will be up to the sender to make the decision b= ased on the feedback it is getting. =20 =20 Another comment on "No Plan" relates to the need for an RTP extension to de= clare things like simulcast and layered stream dependencies. These depende= ncies can be expressed in SDP as alluded to in Plan B=2C and they also can= be described within some codecs (e.g. H.264/SVC allows this). IMHO=2C SDP= O/A does have a role here=2C in describing the receiver capabilities (what= simulcast/layered streams it can support) as well as the sender capabiliti= es (what the sender is capable of sending). Since neither an RTP extension= nor individual payloads can provide reliability=2C having this done in O/A= via reliable signaling has an advantage. But as long as the streams sent = by the codec is self-describing=2C I don't think an RTP extension is needed= . =20 =20 However=2C the case of FEC is a bit trickier for No Plan. If you don't de= clare the FEC SSRCs and dependencies in SDP=2C then you do need to encode t= his in RTP=2C and the codec-specific route may not be sufficient (opinions?= ). Also=2C doing this purely in RTP could create some problems if the desc= riptions were lost because the receiver could end up trying to render a FEC= stream=2C with bizarre results. So this is one area where it seems to me = that "No Plan" may need some additional thought.=20 = --_24ae2d5c-8e9e-4330-89b3-e5312c0823c9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Jonathan said:
 =3B"I think No Plan and Plan B are largely isomorphic in a WebRTC context. = The primary difference is that rather than using a=3Dssrc and a=3Dreceive-s= src (and whatever other Plan B attributes would be needed) to control sourc= es within an m-line=2C instead direct Javascript APIs are used for the same= semantics. It's up to the application to communicate the relevant informat= ion end-to-end=2C in parallel to however it communicates the SDP blob."
=  =3B
[BA] The use of O/A to turn sources on/off is definitely one th= ing that "No Plan" avoids=2C and that's something in its favor. =3B How= ever=2C I don't think that's the only difference.
 =3B
As I see = it=2C No Plan=2C when added to Plan B=2C results in simplifications along s= everal dimensions. =3B I don't think that No Plan prohibits use of a=3D= ssrc lines either in the API or over the wire=2C but it does makes it clear= that they cannot be required for de-multiplexing (which No Plan handles vi= a PTs) =3Bor rendering of incoming streams (which can be handled via AP= Is without MSID declarations). =3B =3BBasically=2C No Plan says "Do= n't try to Bundle more things than you can de-multiplex using PTs". =3B= It's a bit like =3Btelling a snake "don't eat an elephant whole=2C cho= p it up into bit sized pieces". =3B Yes=2C you could try it the other w= ay=2C=2C but is the added complexity (and indigestion) really worth it?  =3B
Personally I wouldn't say it is =3Ba "No Plan" no-no if cr= eateOffer were to produce SDP with a=3Dssrc lines=2C or if setRemoteDescrip= tion were to process a=3Dssrc lines included by the remote peer. =3B Wh= at I think No Plan would have a problem with is if undeclared sources could= n't be rendered=2C or if O/A were required to turn already declared sources= on/off=2C which can happen so rapidly that O/A couldn't possibly handle it= . =3B Also=2C requiring O/A for dropping streams breaks congestion cont= rol because in a highly congested situation=2C the signaling packets would = probably get dropped along with the media=2C so that the signaling to drop = streams couldn't get through. =3B A sender MUST be able to drop streams= in that circumstance.
 =3B
In =3Banswer to questions about = "whether you can declare separate streams for screen sharing versus other v= ideo" I would think that No Plan could allow a=3Dssrc lines for that=2C but= if you just wanted to send them and have the application figure out which = was which (e.g. via app-specific signaling) you could do that too. =3B =
 =3B
One area where I think all the =3B Plans are weak is ha= ndling simulcast/layered streams. =3B I don't think max*sssrc makes sen= se because it groups together sources=2C and streams (including simulcast= =2C layered streams and FEC). =3B A receiver really needs to be able to= declare the maximum number of sources it can receive and the maximum numbe= r of streams it can send=2C as well as declaring the simulcast and layering= schemes it can handle. =3B This is NOT the same as actually stating wh= at it will be sending or receiving at any given moment. =3B In general= =2C it will be up to the sender to make the decision based on the feedback = it is getting. =3B
 =3B
Another =3Bcomment on "No Plan" = relates to the need for an RTP extension to declare things like simulcast a= nd layered stream dependencies. =3B These dependencies can be expressed= in SDP as alluded to in =3B Plan B=2C and they also can be described w= ithin some codecs (e.g. H.264/SVC allows this). =3B IMHO=2C SDP O/A doe= s have a role here=2C in describing the receiver capabilities (what simulca= st/layered streams it can support) as well as the sender capabilities (what= the sender is capable of sending). =3B Since neither an RTP extension = nor individual payloads can provide reliability=2C having this done in O/A = via reliable signaling has an advantage. =3B But as long as =3Bthe = streams sent by the codec is self-describing=2C I don't think an RTP extens= ion is needed. =3B
 =3B
However=2C the case of FEC is a bit = trickier for No Plan. =3B =3B If you don't declare the FEC SSRCs an= d dependencies in SDP=2C then you do need to encode this in RTP=2C and the = codec-specific route may not be sufficient (opinions?). =3B Also=2C doi= ng this purely in RTP could create some problems if the descriptions were l= ost because the receiver could end up trying to render a FEC stream=2C with= bizarre results. =3B So this is one area where it seems to me that "No= Plan" may need some additional thought.
= --_24ae2d5c-8e9e-4330-89b3-e5312c0823c9_-- From emil@sip-communicator.org Tue Jun 4 05:04:43 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF93221F9C32 for ; Tue, 4 Jun 2013 05:04:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta67lRSqGchN for ; Tue, 4 Jun 2013 05:04:29 -0700 (PDT) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DE89021F9C6F for ; Tue, 4 Jun 2013 03:42:23 -0700 (PDT) Received: by mail-bk0-f42.google.com with SMTP id jk13so30266bkc.29 for ; Tue, 04 Jun 2013 03:42:22 -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=6P4xnrvwlUBSP8+z1QTpo4bu4lRn76s6FXf7Hs3U7sA=; b=QGbkCifDMb9L3YSg87VstfbP/xJLaL5hVnVp65BJrIhphmvpUbnRbR7zUgcuNCAlwj zN1KtSG2DJp1wxgCrh4xmLgQujUyu6AUpRs3QFJwGbQ6d1zlyUlzEOx+QuQysiaDVSH1 dICx0R2OIqqkOwZVZmZq4tpmnARk2/jjOBA+lqUznMv1B2ma7S0iFnrwDpotUEEYENvx By6nxp/bM+3+N87fbk6J2maTzdKdOyQn0HsX6RZYxEapK/i08gK66XvYbqoiO5azftRr e31eYx168KUFKsjEX5njEPUxAAaSTRsv6eh0wyH9UOZkZbSFxz+2FBYLcA+YNz+Rfvqa OFUQ== X-Received: by 10.204.170.200 with SMTP id e8mr7764729bkz.168.1370342542249; Tue, 04 Jun 2013 03:42:22 -0700 (PDT) Received: from camionet.local ([82.137.105.222]) by mx.google.com with ESMTPSA id rj5sm21508964bkb.1.2013.06.04.03.42.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 03:42:21 -0700 (PDT) Message-ID: <51ADC48C.8070500@jitsi.org> Date: Tue, 04 Jun 2013 13:42:20 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jonathan Lennox References: <51A65017.4090502@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se>, <51A9A7E2.7000907@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C380AA2@ESESSMB209.ericsson.se> <51ACFF31.9090607@alum.mit.edu> <7426877E-42ED-400A-A264-39C692E71308@vidyo.com> In-Reply-To: <7426877E-42ED-400A-A264-39C692E71308@vidyo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlcK6HB3td+FCxX8F0hedX4gB6xmGZE+d8Bzxysy+cdApk9xUgGRnmdntmkVuSFtd13LHkD Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 12:04:44 -0000 On 04.06.13, 01:03, Jonathan Lennox wrote: > In particular, if you have disaggregated media, you need multiple > m-lines of the same type. The No Plan document's suggestion that you > offer only one m-line of a given media type is guidance on how to > avoid interop failures on initial offers to legacy devices, I think, > not an essential aspect of the proposal. Yes, this is correct. Emil -- https://jitsi.org From christer.holmberg@ericsson.com Tue Jun 4 07:11:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C10A21F9AC9 for ; Tue, 4 Jun 2013 07:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.575 X-Spam-Level: X-Spam-Status: No, score=-5.575 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x33-sdScD+96 for ; Tue, 4 Jun 2013 07:10:51 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2D40321F9CEE for ; Tue, 4 Jun 2013 05:35:13 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-b5-51addeffb41b Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D5.AA.15700.FFEDDA15; Tue, 4 Jun 2013 14:35:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Tue, 4 Jun 2013 14:35:11 +0200 From: Christer Holmberg To: Paul Kyzivat , Emil Ivov Thread-Topic: [rtcweb] No Plan Thread-Index: AQHOXJ6w4pPZWNQxOUWhx5DufiT5nZkdWAeQgAMGtQCAAFWpzoADpfOAgAARKwCAAAHKAIABGQng Date: Tue, 4 Jun 2013 12:35:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C38275A@ESESSMB209.ericsson.se> References: <51A65017.4090502@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se>, <51A9A7E2.7000907@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C380AA2@ESESSMB209.ericsson.se> <51ACFF31.9090607@alum.mit.edu> <51AD0D98.2080302@jitsi.org> <51AD0F18.5020202@alum.mit.edu> In-Reply-To: <51AD0F18.5020202@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvre7/e2sDDX6eNbdYs3MCi8WKDQdY Ldb+a2d3YPb4+/4Dk8eSJT+ZPP6/CQxgjuKySUnNySxLLdK3S+DK+PJzN2PBFJ2Kvn3NrA2M t5W7GDk5JARMJC4f7GODsMUkLtxbD2RzcQgJHGaUmL5uLTtIQkhgMaPEgQnaXYwcHGwCFhLd /8BMEQFXiXnPFEEqmAXUJe4sPgdWLSwgK7Fl8gwmEFtEQE7i+s99bBB2lMSHFSfAbBYBFYlp z78zg9i8Ar4SmyZcZIFYu5FJ4l73G0aQBKeAjsS8HXfBbEag276fWsMEsUxc4taT+UwQNwtI LNlznhnCFpV4+fgfK8htEgKKEsv75SDKdSQW7P7EBmFrSyxb+Bpqr6DEyZlPWCYwis1CMnUW kpZZSFpmIWlZwMiyipE9NzEzJ73ccBMjMGIObvmtu4Px1DmRQ4zSHCxK4rx6vIsDhQTSE0tS s1NTC1KL4otKc1KLDzEycXBKNTCqL489cHmK48Ov3RI/OecvZmSXWXg7/2bP0anC9fqmfh3L 0zaqtbExL/5Xrbo9Qpyvk8nmYfWRlXcWngmWq38i/HO24yulj1fv+hTqHt/Gzl5+flV3xOIJ Tf9cT397E9msob+1JfoU78pHK1WM29eteX7pwNwPFecUPoeULP+74ay1ZemPPxv8lViKMxIN tZiLihMBP0kQpWYCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 14:11:06 -0000 Hi, >> I am not sure exactly what you mean by this. I did try to make it=20 >> clear that "No Plan" has a lot in common with "Plan B". The main=20 >> differences are that there is no expectation for SSRCs to be=20 >> pre-announced and there are requirements for WebRTC APIs to provide=20 >> the tools necessary for apps to control individual streams themselves. > > I now think that it is enough like plan B that the two should be collapse= d together. Make the signaling of the explicit SSRCs optional when there is= some other mechanism to agree upon them. When you say "signaling", do you refer to what is sent on the wire? As others have said, we still need API support to control things - no matte= r whether it's done using SDP or some other mechanism. Regards, Christer >> On 6/1/13 7:05 AM, Christer Holmberg wrote: >>> >>> Hi, >>> >>>>> The draft says: >>>>> >>>>> "For the sake of interoperability this specification=20 >>>>> strongly advises >>>>> against the use of multiple m=3D lines for a single media typ= e." >>>> >>>> This should probably be clarified. The above referred mostly to a=20 >>>> browser's expectations and default offers. Multiple m=3D lines can=20 >>>> confuse a number of existing legacy endpoints which is why they=20 >>>> should be avoided when initiating a session that could reach a=20 >>>> similar device (and by default this should be assumed for any=20 >>>> session). >>>> >>>> If applications *know* that they need to have multiple m=3D lines of=20 >>>> a given type they can request this the same way they could do it=20 >>>> with Plan B: >>>> >>>> If the application wishes, it can request that a given >>>> media source be placed onto a separate m=3D line, by setting a ne= w >>>> .content property on the desired MediaStreamTrack; the values=20 >>>> for the >>>> .content property are those defined for the a=3Dcontent attribute= in >>>> [RFC4796]. >>>> >>>> I'll make sure this is part of the next version. >>>> >>>> Does this make sense? >>> >>> I have nothing against a general recommendation to, for a given=20 >>> media type, have as few m- lines as possible. >>> >>> But, I do think the draft need to point out that it is not always=20 >>> possible, e.g. because: >>> >>> 1) m- lines have different characteristics (normally indicated using=20 >>> SDP attributes) that does not "fit" all content for the given media=20 >>> type; >>> 2) different protocols are used for different m- lines, even if the=20 >>> media type is the same; or >>> 3) the remote endpoint only supports a single (or, another given >>> number) of sources per m- line. >>> >>> Etc. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>>> My understanding is that the usage of multiple m=3D lines for a=20 >>>> single media type would not affect the mechanism as such, but I=20 >>>> just want to verify that :) >>>> >>>> Also, there ARE "legacy" implementations that use multiple m=3D lines= =20 >>>> for a single media type (e.g. video enabled devices using two video=20 >>>> m=3D lines: one for camera content, and one for slides). >>>> >>>> So, while I definitely think that legacy interoperability shall be=20 >>>> taken into consideration, I would not like to make such strong=20 >>>> statements. In my opinion (the draft also talks about it), the=20 >>>> usage of multiple simultaneous SSRCs per m- line is a much bigger=20 >>>> issue when it comes to legacy interoperability. >>>> >>>> Also, in CLUE we have been working on signaling scenarios with=20 >>>> multiple m=3D lines per media type. >>> > >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >>>> Behalf Of Emil Ivov >>>> Sent: 29. toukokuuta 2013 22:00 >>>> To: rtcweb@ietf.org >>>> Subject: [rtcweb] No Plan >>>> >>>> Hey all, >>>> >>>> Based on many of the discussions that we've had here, as well as=20 >>>> many others that we've had offlist, it seemed like a good idea to=20 >>>> investigate a negotiation alternative that relies on SDP and=20 >>>> Offer/Answer just a little bit less. >>>> >>>> The following "no plan" draft attempts to present one such approach: >>>> >>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>> >>>> The draft relies on conventional use of SDP O/A but leaves the=20 >>>> intricacies of multi-source scenarios to application-specific=20 >>>> signalling, with potentially a little help from RTP. >>>> >>>> Hopefully, proponents of Plans A and B would find that the=20 >>>> interoperability requirements that concerned them can still be met=20 >>>> with "no plan". Of course they would have to be addressed by=20 >>>> application-specific signalling and/or signalling gateways. >>>> >>>> Comments are welcome! >>>> >>>> Cheers, >>>> Emil >>>> >>>> -- >>>> https://jitsi.org >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> . >>>> >>> >>> -- >>> https://jitsi.org >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> _______________________________________________ >> 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 emil@sip-communicator.org Tue Jun 4 09:12:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF8121E80E7 for ; Tue, 4 Jun 2013 09:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAzj4E9oSNJC for ; Tue, 4 Jun 2013 09:12:30 -0700 (PDT) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 37CEE21F9B06 for ; Tue, 4 Jun 2013 07:02:17 -0700 (PDT) Received: by mail-bk0-f52.google.com with SMTP id e11so173309bkh.25 for ; Tue, 04 Jun 2013 07:02:16 -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=WPxse0wNNGtIo1RljEur+vtd/r5vacDrb3cNNXIkkAM=; b=bREhDMTmn2NIwHKP49rSnr2E/nW0V0lF2S3pIvwGEgKofWGBIA6KrJMGbiOHTI/ZPf 3BvgHBjZCWIJh4Htlq46tpvJQmuzxcj7yv3Vx1FLyUis8qYGz8/Ee3xszv8bWs1P1Mea AkSfEkvbqeUx6g4Oav/A4gQGiaVNeVoKC4z2WjuLbYaaHRU5ypfDwtEDMEERyIcYFLuL Xf8q01ocJzI6NMIPFb1p1WterkAu7QNBXeIoXVghEdsmhJdmRiMx/AXxKAfqTz+Cs5qW 5fYF/0G1hwHmD4QE21kOj3JDiUuGgBfg6DqwZoxn2bvSlNIW0O/nI4+qEbeadJFAwpqT MZqA== X-Received: by 10.205.25.6 with SMTP id rg6mr8098737bkb.101.1370354536691; Tue, 04 Jun 2013 07:02:16 -0700 (PDT) Received: from camionet.local ([88.128.80.7]) by mx.google.com with ESMTPSA id da16sm23059034bkb.2.2013.06.04.07.02.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 07:02:15 -0700 (PDT) Message-ID: <51ADD69E.2000708@jitsi.org> Date: Tue, 04 Jun 2013 14:59:26 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bernard Aboba References: <51A65017.4090502@jitsi.org>, <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se>, , <51A9A7E2.7000907@jitsi.org>, <7594FB04B1934943A5C02806D1A2204B1C380AA2@ESESSMB209.ericsson.se>, <51ACFF31.9090607@alum.mit.edu>, <7426877E-42ED-400A-A264-39C692E71308@vidyo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmPFs6Lh4BaQC7WvGXkemnTFd64/VDknBr195FP4FdbBYOZMKiPN4w6r2X3zfJbUaW4t7z/ Cc: Jonathan Lennox , rtcweb@ietf.org Subject: [rtcweb] Repair Flows and No Plan (Was: No Plan) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:12:44 -0000 Hey Bernard, I obviously agree with what you are saying. Just one clarification regarding your layering and FEC comments: I don't think we are likely to come up with one generic mechanism that would work and should be used with all possible kinds of repair flows and scenarios. As you have pointed on occasion: these mechanisms vary largely. Some, like SVC, handle it within codec. Others, such as 1-D Interleaved Parity [RFC6015] need a payload type of their own. Others yet require that NACKs be sent over signalling and of course there are those whose relation can be specified in Plan B style SDP [RFC5956]. No Plan is not explicitly incompatible with any of them. I don't see a reason why someone shouldn't be able to specify a simulcast relation between SSRCs in SDP. This is is totally fine. What No Plan argues against is that this could be considered as enough of a reason to mandate that SSRCs should always be present in SDP. This argument has already been made and I think many here wouldn't agree with it because of the diversity in repair mechanisms that I mentioned above. In that sense the RTP header extension in the draft is just one example where such information could be delivered without any signalling. I personally believe such a mechanism could be quite useful in a number of cases. It can also be designed in such a way that browsers would use it transparently from applications, without bothering them with the exchange of O/A blobs. Still this is only a possibility and not really a No Plan requirement. Now, there is indeed something that we need to specify here and that is: how exactly does an application know whether it would need to worry about repair semantics and if so, would they work transparently or require the exchange of O/A blobs. Not only can this change from one browser to the next but it can even vary across peer connections. Handling this could require some adaptations in the WebRTC API. I might be wrong but I don't think any of the WebRTC supporting browsers currently send repair flows which is why all this is still hypothetical and now is probably the right time to think about it. Cheers, Emil On 04.06.13, 01:50, Bernard Aboba wrote: > > Jonathan said: > > "I think No Plan and Plan B are largely isomorphic in a WebRTC context. > The primary difference is that rather than using a=ssrc and > a=receive-ssrc (and whatever other Plan B attributes would be needed) to > control sources within an m-line, instead direct Javascript APIs are > used for the same semantics. It's up to the application to communicate > the relevant information end-to-end, in parallel to however it > communicates the SDP blob." > > [BA] The use of O/A to turn sources on/off is definitely one thing that > "No Plan" avoids, and that's something in its favor. However, I don't > think that's the only difference. > > As I see it, No Plan, when added to Plan B, results in simplifications > along several dimensions. I don't think that No Plan prohibits use of > a=ssrc lines either in the API or over the wire, but it does makes it > clear that they cannot be required for de-multiplexing (which No Plan > handles via PTs) or rendering of incoming streams (which can be handled > via APIs without MSID declarations). Basically, No Plan says "Don't try > to Bundle more things than you can de-multiplex using PTs". It's a bit > like telling a snake "don't eat an elephant whole, chop it up into bit > sized pieces". Yes, you could try it the other way,, but is the added > complexity (and indigestion) really worth it? > > Personally I wouldn't say it is a "No Plan" no-no if createOffer were to > produce SDP with a=ssrc lines, or if setRemoteDescription were to > process a=ssrc lines included by the remote peer. What I think No Plan > would have a problem with is if undeclared sources couldn't be rendered, > or if O/A were required to turn already declared sources on/off, which > can happen so rapidly that O/A couldn't possibly handle it. Also, > requiring O/A for dropping streams breaks congestion control because in > a highly congested situation, the signaling packets would probably get > dropped along with the media, so that the signaling to drop streams > couldn't get through. A sender MUST be able to drop streams in that > circumstance. > > In answer to questions about "whether you can declare separate streams > for screen sharing versus other video" I would think that No Plan could > allow a=ssrc lines for that, but if you just wanted to send them and > have the application figure out which was which (e.g. via app-specific > signaling) you could do that too. > > One area where I think all the Plans are weak is handling > simulcast/layered streams. I don't think max*sssrc makes sense because > it groups together sources, and streams (including simulcast, layered > streams and FEC). A receiver really needs to be able to declare the > maximum number of sources it can receive and the maximum number of > streams it can send, as well as declaring the simulcast and layering > schemes it can handle. This is NOT the same as actually stating what it > will be sending or receiving at any given moment. In general, it will > be up to the sender to make the decision based on the feedback it is > getting. > > Another comment on "No Plan" relates to the need for an RTP extension to > declare things like simulcast and layered stream dependencies. These > dependencies can be expressed in SDP as alluded to in Plan B, and they > also can be described within some codecs (e.g. H.264/SVC allows this). > IMHO, SDP O/A does have a role here, in describing the receiver > capabilities (what simulcast/layered streams it can support) as well as > the sender capabilities (what the sender is capable of sending). Since > neither an RTP extension nor individual payloads can provide > reliability, having this done in O/A via reliable signaling has an > advantage. But as long as the streams sent by the codec is > self-describing, I don't think an RTP extension is needed. > > However, the case of FEC is a bit trickier for No Plan. If you don't > declare the FEC SSRCs and dependencies in SDP, then you do need to > encode this in RTP, and the codec-specific route may not be sufficient > (opinions?). Also, doing this purely in RTP could create some problems > if the descriptions were lost because the receiver could end up trying > to render a FEC stream, with bizarre results. So this is one area where > it seems to me that "No Plan" may need some additional thought. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- https://jitsi.org From emil@sip-communicator.org Tue Jun 4 09:12:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F2321F96F2 for ; Tue, 4 Jun 2013 09:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qo49AlU9VcSp for ; Tue, 4 Jun 2013 09:12:44 -0700 (PDT) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1D821F9BA2 for ; Tue, 4 Jun 2013 07:02:28 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id 6so174821bkj.8 for ; Tue, 04 Jun 2013 07:02:27 -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=ddKkBxmcHOOBLwj1WWEdl9KYxGgmbmFC4Ciy1Ch+6g0=; b=EC78pDnINRvzlwwAnrpDdcCLRKdG3Ss5M0vX6GdWIV0LMI6IQmhPmxCTP1cvxxHCKz UNGXFzpAASKQk7rVisavBewJnXRA5gHOI4lXVH0jBjgx4Y6E0xUcYXPdikNitHMICr5H Lpwp1zhQHsQ7STmkPxhBgp7b/5sjNpK/xL9E33aSBixNg+7ER8hObHspAT/4Mztp1y5j Kv1l4iUSTgOyClakNZDyBJFHYUQoyJf39UnbpXIIV505QWI8aqzfMzJ+w0Omi79WNFN7 ULcq9H5Vk8axOkLQthdpR8GjAMIjSTPwgJEWXWpEu7d3i23N/HI/iUIwbjTNeGVvhCyg 74wA== X-Received: by 10.204.172.136 with SMTP id l8mr8070991bkz.49.1370354547461; Tue, 04 Jun 2013 07:02:27 -0700 (PDT) Received: from camionet.local ([88.128.80.7]) by mx.google.com with ESMTPSA id tl1sm23091853bkb.7.2013.06.04.07.02.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 07:02:26 -0700 (PDT) Message-ID: <51ADD8D1.1040306@jitsi.org> Date: Tue, 04 Jun 2013 15:08:49 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jim Barnett References: <51A65017.4090502@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se>, <51A9A7E2.7000907@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C380AA2@ESESSMB209.ericsson.se> <51ACFF31.9090607@alum.mit.edu> <7426877E-42ED-400A-A264-39C692E71308@vidyo.com> <57A15FAF9E58F841B2B1651FFE16D2810437BF@GENSJZMBX02.msg.int.genesyslab.com> In-Reply-To: <57A15FAF9E58F841B2B1651FFE16D2810437BF@GENSJZMBX02.msg.int.genesyslab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlI0bIkRH8qs16QU1/yvn6i8BihS6PrF/qz5eQTdbkSdc90Mvf9FNjEJdKDufrpb0G6nlq+ Cc: Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:12:59 -0000 Hey Jim, On 04.06.13, 01:16, Jim Barnett wrote: > Just checking if I understand No Plan: since the bundling is added via JS APIs, and not SDP, I am not sure where you got this. No Plan does depend on the browser to provide support for BUNDLE and to generate the SDP accordingly. Emil > then if the app looks at > The localDescription and remoteDescription attributes of the PeerConnection, it won't be able to tell if sources are bundled or not (since localDescription and remoteDescription are defined to contain SDP) > > - Jim > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Jonathan Lennox > Sent: Monday, June 03, 2013 6:03 PM > To: Paul Kyzivat > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] No Plan > > > On Jun 3, 2013, at 4:40 PM, Paul Kyzivat wrote: > >> +1 >> >> The more we dig into this the more it looks like Plan B. >> >> Thanks, >> Paul > > I think No Plan and Plan B are largely isomorphic in a WebRTC context. The primary difference is that rather than using a=ssrc and a=receive-ssrc (and whatever other Plan B attributes would be needed) to control sources within an m-line, instead direct Javascript APIs are used for the same semantics. It's up to the application to communicate the relevant information end-to-end, in parallel to however it communicates the SDP blob. > > As I see it, the primary advantages of No Plan, then, are that: > > a) It allows "implicit" signaling of sources -- where that's sufficient -- by just sending RTP traffic. This prevents problems related to the timing and synchronization between signaling and media. (Note that Plan B probably actually needs this as well, for legacy interop.) > > b) It carves a Comment 22 corner out of the SDP-based APIs, thus decoupling source signaling from SDP offer/answer. This is for a scenario where there aren't any issues of legacy compatibility, and there isn't any (or at least much) existing IETF standardization -- as best I can recall, legacy compatibility and existing standardization were the primary motivations for using SDP as the WebRTC API. > > Other than that, I think the two proposals are pretty similar for WebRTC, and it would probably be a Simple Matter of Programming to translate between the two (though you have to worry about the O/A state on the Plan B side). > > In particular, if you have disaggregated media, you need multiple m-lines of the same type. The No Plan document's suggestion that you offer only one m-line of a given media type is guidance on how to avoid interop failures on initial offers to legacy devices, I think, not an essential aspect of the proposal. > > > In a SIP context, No Plan requires defining a separate signaling channel for this source information, in scenarios where something beyond implicit signaling is needed. As Emil has stated, I think that something like the SIP/XCon conference package, or something like the CLUE channel, would be the obvious places to start. > > I think SIP, even more than RTCWeb, is where you'd want something lighter-weight and better-designed than SDP offer/answer to signal source changes. > >> On 6/1/13 7:05 AM, Christer Holmberg wrote: >>> >>> Hi, >>> >>>>> The draft says: >>>>> >>>>> "For the sake of interoperability this specification strongly advises >>>>> against the use of multiple m= lines for a single media type." >>>> >>>> This should probably be clarified. The above referred mostly to a >>>> browser's expectations and default offers. Multiple m= lines can >>>> confuse a number of existing legacy endpoints which is why they >>>> should be avoided when initiating a session that could reach a >>>> similar device (and by default this should be assumed for any session). >>>> >>>> If applications *know* that they need to have multiple m= lines of a >>>> given type they can request this the same way they could do it with Plan B: >>>> >>>> If the application wishes, it can request that a given >>>> media source be placed onto a separate m= line, by setting a new >>>> .content property on the desired MediaStreamTrack; the values for the >>>> .content property are those defined for the a=content attribute in >>>> [RFC4796]. >>>> >>>> I'll make sure this is part of the next version. >>>> >>>> Does this make sense? >>> >>> I have nothing against a general recommendation to, for a given media type, have as few m- lines as possible. >>> >>> But, I do think the draft need to point out that it is not always possible, e.g. because: >>> >>> 1) m- lines have different characteristics (normally indicated using >>> SDP attributes) that does not "fit" all content for the given media >>> type; >>> 2) different protocols are used for different m- lines, even if the >>> media type is the same; or >>> 3) the remote endpoint only supports a single (or, another given number) of sources per m- line. >>> >>> Etc. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>>> My understanding is that the usage of multiple m= lines for a single >>>> media type would not affect the mechanism as such, but I just want >>>> to verify that :) >>>> >>>> Also, there ARE "legacy" implementations that use multiple m= lines for a single media type (e.g. video enabled devices using two video m= lines: one for camera content, and one for slides). >>>> >>>> So, while I definitely think that legacy interoperability shall be taken into consideration, I would not like to make such strong statements. In my opinion (the draft also talks about it), the usage of multiple simultaneous SSRCs per m- line is a much bigger issue when it comes to legacy interoperability. >>>> >>>> Also, in CLUE we have been working on signaling scenarios with multiple m= lines per media type. >>>> >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>> Behalf Of Emil Ivov >>>> Sent: 29. toukokuuta 2013 22:00 >>>> To: rtcweb@ietf.org >>>> Subject: [rtcweb] No Plan >>>> >>>> Hey all, >>>> >>>> Based on many of the discussions that we've had here, as well as many others that we've had offlist, it seemed like a good idea to investigate a negotiation alternative that relies on SDP and Offer/Answer just a little bit less. >>>> >>>> The following "no plan" draft attempts to present one such approach: >>>> >>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>> >>>> The draft relies on conventional use of SDP O/A but leaves the intricacies of multi-source scenarios to application-specific signalling, with potentially a little help from RTP. >>>> >>>> Hopefully, proponents of Plans A and B would find that the interoperability requirements that concerned them can still be met with "no plan". Of course they would have to be addressed by application-specific signalling and/or signalling gateways. >>>> >>>> Comments are welcome! >>>> >>>> Cheers, >>>> Emil >>>> >>>> -- >>>> https://jitsi.org >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> . >>>> >>> >>> -- >>> https://jitsi.org >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > -- > Jonathan Lennox > jonathan@vidyo.com > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- https://jitsi.org From emil@sip-communicator.org Tue Jun 4 09:13:43 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62F321F991F for ; Tue, 4 Jun 2013 09:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n40qADW9hiaD for ; Tue, 4 Jun 2013 09:13:33 -0700 (PDT) Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2F84E21F9D8C for ; Tue, 4 Jun 2013 07:02:49 -0700 (PDT) Received: by mail-bk0-f46.google.com with SMTP id na10so175765bkb.5 for ; Tue, 04 Jun 2013 07:02:48 -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=nRbWCUl6OYcJnnQCl2UacT35O6l5oPv8GvGRtcfvx9E=; b=a/68ddRVv6h4BC79a+Md+Bh13u0O9d7Z+tr0EXtN4ObCnxMCZMhlSfZ70zwwN+AiDm EijHWkoShgIuDbw6caQRDZjt+xmPgo9L5/4F+aUr5hh1Ju5PlCb+kMUnlbKwymVsPZSa RYaFFmdom/5iQ7t/KCRpeKYjeUwSsCxA3KkV0oHE8sUm6V/hT5mM7Gn2ecgvFK3oN2Rk 5u6ZL+gjEbNMpB0KoGyt4ayiQNoP+8N1qepiekYtDXve3QQ0BUbCKBszVqOEpYK6JdfQ 8D4DRXVtpW7rcvvqRAooQHjofXpYzZXlWzjd2uh72ka4imdKBOApxIhmG1An3KtjbYMR qM0Q== X-Received: by 10.204.186.135 with SMTP id cs7mr8167992bkb.146.1370354568100; Tue, 04 Jun 2013 07:02:48 -0700 (PDT) Received: from camionet.local ([88.128.80.7]) by mx.google.com with ESMTPSA id hh3sm10431596bkc.5.2013.06.04.07.02.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 07:02:47 -0700 (PDT) Message-ID: <51ADD8DD.1060409@jitsi.org> Date: Tue, 04 Jun 2013 15:09:01 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Roni Even References: <020e01ce6045$4b07dee0$e1179ca0$@gmail.com> <51AC73EE.5080603@jitsi.org> <026201ce60a6$6d406f20$47c14d60$@gmail.com> In-Reply-To: <026201ce60a6$6d406f20$47c14d60$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkPH8tAf1/gMJBKyIA8fLRvSNu/ISK6QK66bb/m1N6YDYDz6W47y1071zxKtQVfO+mcEuRh Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan - SDP offer/answer clarification X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:13:44 -0000 Hey Roni, On 04.06.13, 01:05, Roni Even wrote: > Hi Emil, > My understanding is that you propose to de-multiplex by the pt number so you > cannot have two rtp streams with the same payload type number A PT number is only used to pick a codec/processing chain. Different SSRCs would then be used as an indication that packets belong to different RTP flows and that they have to end-up in different MediaStream-s and eventually
We've had a lot of = discussions on the list about this over the past couple years.  I = thought the general feeling was at this point we needed to discuss it = live - either in person or on a con call - because it was hard to follow = all the arguments in email.  Maybe that was just my feeling, but I = could swear some other people said the same thing at the last IETF 86 = meeting or Boston = interim.

-hadriel

= --Apple-Mail=_56605741-7CC2-46C1-9DC2-82E913F319CA-- From martin.thomson@gmail.com Wed Jun 12 10:08:13 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F1621E808A for ; Wed, 12 Jun 2013 10:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMKCNoDcKpbD for ; Wed, 12 Jun 2013 10:08:12 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6DA21E8082 for ; Wed, 12 Jun 2013 10:08:05 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so6232397wes.18 for ; Wed, 12 Jun 2013 10:08:05 -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=DlPgT1ZKpbMS/XPWECFmXhg7BeQW64T4vixkYyFCvyc=; b=aylZXFfmzJjVDk2BA9R66jOqwcjYARUuuuQLSozCv2A6JcqCn2lPSIq0NujVkIgcxo tw4yUAbr7/Qop+esboTZcd4wMkIdCrf8hr8yaoQN2GTO+0pknd/7SDIQht+VUlx2LHVx ATtweuLwupQzm4zuffXsodYu6GiGKX0Nvbk03Xz4CgTyCMeW4Xxw7sNOlhKR3M/Yzn4C XTWZ3r4G+UgR+2/FEbR9P8APMPPXhlUW71uvYJNvwHdvpXZv2+wvFF4ByT3I1xNCWNuf LQBzsJ52MGP63DANV4DYqedthg1OBQ7Rj1ZpF5Cm51BYFr0dgKNCWLomakYe6do01L4H kYjw== MIME-Version: 1.0 X-Received: by 10.180.87.162 with SMTP id az2mr5168429wib.10.1371056885017; Wed, 12 Jun 2013 10:08:05 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 12 Jun 2013 10:08:04 -0700 (PDT) In-Reply-To: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> Date: Wed, 12 Jun 2013 10:08:04 -0700 Message-ID: From: Martin Thomson To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Jun 2013 17:08:13 -0000 On 12 June 2013 09:29, Hadriel Kaplan wrote: > We've had a lot of discussions on the list about this over the past couple > years. I thought the general feeling was at this point we needed to discuss > it live - either in person or on a con call - because it was hard to follow > all the arguments in email. Maybe that was just my feeling, but I could > swear some other people said the same thing at the last IETF 86 meeting or > Boston interim. That's consistent with my understanding. This seems far less contentious than the video MTI discussion, but continuously deferring discussion hasn't helped. From partha@parthasarathi.co.in Wed Jun 12 10:55:05 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6851E21E8084 for ; Wed, 12 Jun 2013 10:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwLTqhk8VdSX for ; Wed, 12 Jun 2013 10:55:01 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.231]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5FD21E804C for ; Wed, 12 Jun 2013 10:55:00 -0700 (PDT) Received: from userPC (unknown [122.166.142.102]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id A4CB719084AD; Wed, 12 Jun 2013 17:54:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1371059691; bh=c6Vx9IyDqYThIsokzwFCMEINnNMYW/rXT2foUNbVEBU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=VmCH1HFvxjvXZ8iYkXURQ93hHnGskKesbC4KW8CmnhfKl/zjW8WatgwE6CPkBBwji JjhroyjPjtjOiZT34W7fiuwO60QD+CCxoNV8j1nOX2gxEoDvU/eqBhsngDU5f2rD64 yZkHcn05VRgzuI+zpqE+wEx/xT3T1JJ0vgw/+FTU= From: "Parthasarathi R" To: References: <20130612173723.20266.87116.idtracker@ietfa.amsl.com> In-Reply-To: <20130612173723.20266.87116.idtracker@ietfa.amsl.com> Date: Wed, 12 Jun 2013 23:24:40 +0530 Message-ID: <004601ce6795$ee3546a0$ca9fd3e0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5nk3+ps46dBqooTTyECIsVCFaIQwAAUnbQ Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0207.51B8B5EB.0019, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: 'Elangovan Manickam' Subject: [rtcweb] Offer & Answer interworking between JSEP & SIP draft for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Jun 2013 17:55:05 -0000 Hi all, Offer/answer Interworking between JSEP & SIP IETF draft is written as = JSEP (O/A) model is different from SIP O/A and there is a need of = mapping document. This draft will act as a building block for = developing the O/A interwork between SIP & JSEP. The draft is available = at = http://www.ietf.org/internet-drafts/draft-partha-rtcweb-jsep-sip-00.txt. = Could you please provide your valuable review comments. Thanks Partha > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, June 12, 2013 11:07 PM > To: Uwe Rauschenbach; Elangovan Manickam; Parthasarathi Ravindran > Subject: New Version Notification for draft-partha-rtcweb-jsep-sip- > 00.txt >=20 >=20 > A new version of I-D, draft-partha-rtcweb-jsep-sip-00.txt > has been successfully submitted by Parthasarathi Ravindran and posted > to the > IETF repository. >=20 > Filename: draft-partha-rtcweb-jsep-sip > Revision: 00 > Title: Offer & Answer interworking between JSEP & SIP > Creation date: 2013-06-12 > Group: Individual Submission > Number of pages: 13 > URL: http://www.ietf.org/internet-drafts/draft-partha- > rtcweb-jsep-sip-00.txt > Status: http://datatracker.ietf.org/doc/draft-partha-rtcweb- > jsep-sip > Htmlized: http://tools.ietf.org/html/draft-partha-rtcweb-jsep- > sip-00 >=20 >=20 > Abstract: > Real time communcation Web (RTCWeb) workgroup defines the real time > commmunication using JavaScript Session establishment protocol > (JSEP) > as an offer/answer mechanism. Session Initiation protocol (SIP) is > IETF defined and well deployed protocol for real time = communication. > This document provides offer & answer interworking between JSEP and > SIP. >=20 >=20 >=20 >=20 > The IETF Secretariat From prvs=18750f8074=christer.holmberg@ericsson.com Wed Jun 12 11:11:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1485721E8084 for ; Wed, 12 Jun 2013 11:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.695 X-Spam-Level: X-Spam-Status: No, score=-5.695 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X8xjlC9UGN3 for ; Wed, 12 Jun 2013 11:11:32 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 15B4521E8056 for ; Wed, 12 Jun 2013 11:11:31 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-a4-51b8b9d27844 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E6.2A.15700.2D9B8B15; Wed, 12 Jun 2013 20:11:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Wed, 12 Jun 2013 20:11:30 +0200 From: Christer Holmberg To: Parthasarathi R , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Offer & Answer interworking between JSEP & SIP draft for review Thread-Index: Ac5nmEmmXFOwKCwpR1e2EqmBZUP0kQ== Date: Wed, 12 Jun 2013 18:11:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3893F6@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvre7lnTsCDab8ZLWYP/Mou8XkT32s Fmv/tbM7MHssWfKTyePn+qvsHh/mf2EPYI7itklKLCkLzkzP07dL4M64vm8WY8Ea8Yp3+++z NDC2CHcxcnJICJhI3L32gxHCFpO4cG89WxcjF4eQwGFGiRU3r0M5Sxgl3rbNAnI4ONgELCS6 /2mDNIgIhEu8eX6ZGcRmFjCVmPjwIDtIiTBQ/N7yKoiSCIn/658wgoRFBPQkVrRpgZgsAqoS 1/qyQCp4BXwlFnVOARvCCHTB91NrmCAGikt8OHidGeIyAYkle85D2aISLx//Y4WwlSR+bLjE AlGvJ3Fj6hQ2CFtbYtnC18wQ8wUlTs58wjKBUWQWkrGzkLTMQtIyC0nLAkaWVYzsuYmZOenl hpsYgTFwcMtv3R2Mp86JHGKU5mBREueNV90RKCSQnliSmp2aWpBaFF9UmpNafIiRiYMTRHBJ NTAm/mRdzytVFar2SfxFgJgkT8zE0AVzmbmOL/gQYlxbX8zq8r2juV+3RW/V3H//+Pg3SGSf C43lPrAi+X38fu7ve9Qs/zEekbXrCfhz65zNpaD3ClliF/S2Gd452Rj8xmuGoE+79fypf9hn 7Fz0VaEwzeIt65QP36I8FsU2rvvle+50R2Np6m8lluKMREMt5qLiRAAAgrfnVAIAAA== Cc: 'Elangovan Manickam' Subject: Re: [rtcweb] Offer & Answer interworking between JSEP & SIP draft for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Jun 2013 18:11:38 -0000 Hi, I have some issues with your way of solving forking. In sections 5.5 and 5.6, you are mapping SIP Answers to JSEP Offer. I think= that is a very bad thing to do, because what happens if something has chan= ged in the associated JSEP Answer? Then you'll have to map that into a SIP = Offer, and then again map the associated SIP Answer into a JSEP Offer. Etc = etc etc.=20 I do like that fact that you are not using PRANSWER, but unfortunately I do= n't think the suggested way will work :) My suggestion is still that we should support some kind of "cloning" (I use= that as a generic term), in order to support forking. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] P= uolesta Parthasarathi R L=E4hetetty: 12. kes=E4kuuta 2013 20:55 Vastaanottaja: rtcweb@ietf.org Kopio: 'Elangovan Manickam' Aihe: [rtcweb] Offer & Answer interworking between JSEP & SIP draft for rev= iew Hi all, Offer/answer Interworking between JSEP & SIP IETF draft is written as JSEP = (O/A) model is different from SIP O/A and there is a need of mapping docume= nt. This draft will act as a building block for developing the O/A interwo= rk between SIP & JSEP. The draft is available at http://www.ietf.org/intern= et-drafts/draft-partha-rtcweb-jsep-sip-00.txt. Could you please provide you= r valuable review comments. Thanks Partha > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, June 12, 2013 11:07 PM > To: Uwe Rauschenbach; Elangovan Manickam; Parthasarathi Ravindran > Subject: New Version Notification for draft-partha-rtcweb-jsep-sip-=20 > 00.txt >=20 >=20 > A new version of I-D, draft-partha-rtcweb-jsep-sip-00.txt > has been successfully submitted by Parthasarathi Ravindran and posted=20 > to the IETF repository. >=20 > Filename: draft-partha-rtcweb-jsep-sip > Revision: 00 > Title: Offer & Answer interworking between JSEP & SIP > Creation date: 2013-06-12 > Group: Individual Submission > Number of pages: 13 > URL: http://www.ietf.org/internet-drafts/draft-partha- > rtcweb-jsep-sip-00.txt > Status: http://datatracker.ietf.org/doc/draft-partha-rtcweb- > jsep-sip > Htmlized: http://tools.ietf.org/html/draft-partha-rtcweb-jsep- > sip-00 >=20 >=20 > Abstract: > Real time communcation Web (RTCWeb) workgroup defines the real time > commmunication using JavaScript Session establishment protocol > (JSEP) > as an offer/answer mechanism. Session Initiation protocol (SIP) is > IETF defined and well deployed protocol for real time communication. > This document provides offer & answer interworking between JSEP and > SIP. >=20 >=20 >=20 >=20 > The IETF Secretariat _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From matthew.kaufman@skype.net Wed Jun 12 16:12:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2990611E80FD for ; Wed, 12 Jun 2013 16:12:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i73p7Rfer+md for ; Wed, 12 Jun 2013 16:12:52 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFB311E80F8 for ; Wed, 12 Jun 2013 16:12:51 -0700 (PDT) Received: from BN1AFFO11FD010.protection.gbl (10.58.52.203) by BN1BFFO11HUB024.protection.gbl (10.58.53.134) with Microsoft SMTP Server (TLS) id 15.0.707.0; Wed, 12 Jun 2013 23:11:37 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD010.mail.protection.outlook.com (10.58.52.70) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Wed, 12 Jun 2013 23:11:36 +0000 Received: from TK5EX14MBXC274.redmond.corp.microsoft.com ([169.254.3.236]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0136.001; Wed, 12 Jun 2013 23:11:34 +0000 From: "Matthew Kaufman (SKYPE)" To: Parthasarathi R Thread-Topic: [rtcweb] Offer & Answer interworking between JSEP & SIP draft for review Thread-Index: Ac5nk3+ps46dBqooTTyECIsVCFaIQwAAUnbQAAo/lwA= Date: Wed, 12 Jun 2013 23:11:34 +0000 Message-ID: <9515CA24-1B11-4D40-AC5F-0E54D977C470@skype.net> References: <20130612173723.20266.87116.idtracker@ietfa.amsl.com> <004601ce6795$ee3546a0$ca9fd3e0$@co.in> In-Reply-To: <004601ce6795$ee3546a0$ca9fd3e0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <79B80949A2B99D43800DB23B9B405F50@microsoft.com> 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:(189002)(377454002)(199002)(24454002)(377424003)(51704005)(13464003)(53754005)(56816003)(6806003)(54316002)(36756003)(23726002)(81542001)(77096001)(74502001)(79102001)(74662001)(33656001)(56776001)(74366001)(47976001)(47446002)(50986001)(46102001)(76786001)(31966008)(51856001)(76482001)(49866001)(77982001)(54356001)(76796001)(47736001)(53806001)(50466002)(59766001)(4396001)(80022001)(74706001)(65816001)(69226001)(47776003)(20776003)(46406003)(63696002)(81342001)(15202345002)(16406001)(74876001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB024; H:TK5EX14MLTC103.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08756AC3C8 Cc: Elangovan Manickam , "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer & Answer interworking between JSEP & SIP draft for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Jun 2013 23:12:57 -0000 I have a meta review comment: does the fact that the content of this docume= nt is not null mean that the reasoning for choosing SDP O/A as the API surf= ace was faulty? Matthew Kaufman (Sent from my iPhone) On Jun 12, 2013, at 10:55 AM, "Parthasarathi R" wrote: > Hi all, >=20 > Offer/answer Interworking between JSEP & SIP IETF draft is written as JSE= P (O/A) model is different from SIP O/A and there is a need of mapping docu= ment. This draft will act as a building block for developing the O/A inter= work between SIP & JSEP. The draft is available at http://www.ietf.org/inte= rnet-drafts/draft-partha-rtcweb-jsep-sip-00.txt. Could you please provide y= our valuable review comments. >=20 > Thanks > Partha >=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, June 12, 2013 11:07 PM >> To: Uwe Rauschenbach; Elangovan Manickam; Parthasarathi Ravindran >> Subject: New Version Notification for draft-partha-rtcweb-jsep-sip- >> 00.txt >>=20 >>=20 >> A new version of I-D, draft-partha-rtcweb-jsep-sip-00.txt >> has been successfully submitted by Parthasarathi Ravindran and posted >> to the >> IETF repository. >>=20 >> Filename: draft-partha-rtcweb-jsep-sip >> Revision: 00 >> Title: Offer & Answer interworking between JSEP & SIP >> Creation date: 2013-06-12 >> Group: Individual Submission >> Number of pages: 13 >> URL: http://www.ietf.org/internet-drafts/draft-partha- >> rtcweb-jsep-sip-00.txt >> Status: http://datatracker.ietf.org/doc/draft-partha-rtcweb- >> jsep-sip >> Htmlized: http://tools.ietf.org/html/draft-partha-rtcweb-jsep- >> sip-00 >>=20 >>=20 >> Abstract: >> Real time communcation Web (RTCWeb) workgroup defines the real time >> commmunication using JavaScript Session establishment protocol >> (JSEP) >> as an offer/answer mechanism. Session Initiation protocol (SIP) is >> IETF defined and well deployed protocol for real time communication. >> This document provides offer & answer interworking between JSEP and >> SIP. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From roman@telurix.com Wed Jun 12 16:27:17 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C130721E80BE for ; Wed, 12 Jun 2013 16:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfgybrkHbr7T for ; Wed, 12 Jun 2013 16:27:16 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id C81F921E80BA for ; Wed, 12 Jun 2013 16:27:15 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so5758359wgh.16 for ; Wed, 12 Jun 2013 16:27:15 -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=8dSDQaOG2YtXVlwocxePKjjatilKzDEN41I3mp+n3AM=; b=oL9w5up/vnRqokKuBDaPFkyOom2nF7VWloK9G3B2SWIZV8rQGM5PIB1ELWWxREOWu7 I/7Bl21/WlzRBrHNNhxuu6a0RoIg7EoJ1YTJZFZlIbli01ZRC7wPHbbqSkt9qja/pxlT ePLErtVxi5VZvchlpgzPID7BQqI+hoELpSsriqbz5A77mKHr6eF93u9OMWJDO6dOHBxW ZhmMJZNhUN4posMcI6u5XPIWNrJQT5EYDdS71XwZgymFy0aZyVrU7qNTUjg3YNQBxgqk IVid0r4Z0n1axuRdo5p4dl2pHK0QmkOMG1xo6uLLmDNEWjspcWGonNhMzrUfiEQmVoN+ ddSw== X-Received: by 10.194.238.199 with SMTP id vm7mr3262354wjc.37.1371079634912; Wed, 12 Jun 2013 16:27:14 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [2a00:1450:400c:c00::22d]) by mx.google.com with ESMTPSA id b19sm27921702wik.10.2013.06.12.16.27.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Jun 2013 16:27:14 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so2088177wgh.0 for ; Wed, 12 Jun 2013 16:27:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.87.71 with SMTP id v7mr13238315wjz.33.1371079633322; Wed, 12 Jun 2013 16:27:13 -0700 (PDT) Received: by 10.216.52.134 with HTTP; Wed, 12 Jun 2013 16:27:13 -0700 (PDT) In-Reply-To: <9515CA24-1B11-4D40-AC5F-0E54D977C470@skype.net> References: <20130612173723.20266.87116.idtracker@ietfa.amsl.com> <004601ce6795$ee3546a0$ca9fd3e0$@co.in> <9515CA24-1B11-4D40-AC5F-0E54D977C470@skype.net> Date: Wed, 12 Jun 2013 19:27:13 -0400 Message-ID: From: Roman Shpount To: "Matthew Kaufman (SKYPE)" Content-Type: multipart/alternative; boundary=047d7bf10ab080cd5404defd5adf X-Gm-Message-State: ALoCoQnUBd5oXWIJDycK2M92jHNAEG7StJZKQhkHJNDpzFXGEqxL7Es8yClKPOAIcIUVynJ/HCnl Cc: Elangovan Manickam , "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer & Answer interworking between JSEP & SIP draft for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Jun 2013 23:27:17 -0000 --047d7bf10ab080cd5404defd5adf Content-Type: text/plain; charset=ISO-8859-1 To be honest, the whole SDP O/A affair reminds me the verse from Haddock's Eyes song by Lewis Carroll: But I was thinking of a plan To dye one's whiskers green,And always use so large a fan That they could not be seen. The whole thing would be easier to use, simpler to standardize, and much simpler to interop with SIP if instead of O/A underlying C++ API's from Voice and Video engines were mapped to JavaScript. _____________ Roman Shpount On Wed, Jun 12, 2013 at 7:11 PM, Matthew Kaufman (SKYPE) < matthew.kaufman@skype.net> wrote: > I have a meta review comment: does the fact that the content of this > document is not null mean that the reasoning for choosing SDP O/A as the > API surface was faulty? > > Matthew Kaufman > > (Sent from my iPhone) > > On Jun 12, 2013, at 10:55 AM, "Parthasarathi R" < > partha@parthasarathi.co.in> wrote: > > > Hi all, > > > > Offer/answer Interworking between JSEP & SIP IETF draft is written as > JSEP (O/A) model is different from SIP O/A and there is a need of mapping > document. This draft will act as a building block for developing the O/A > interwork between SIP & JSEP. The draft is available at > http://www.ietf.org/internet-drafts/draft-partha-rtcweb-jsep-sip-00.txt. > Could you please provide your valuable review comments. > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Wednesday, June 12, 2013 11:07 PM > >> To: Uwe Rauschenbach; Elangovan Manickam; Parthasarathi Ravindran > >> Subject: New Version Notification for draft-partha-rtcweb-jsep-sip- > >> 00.txt > >> > >> > >> A new version of I-D, draft-partha-rtcweb-jsep-sip-00.txt > >> has been successfully submitted by Parthasarathi Ravindran and posted > >> to the > >> IETF repository. > >> > >> Filename: draft-partha-rtcweb-jsep-sip > >> Revision: 00 > >> Title: Offer & Answer interworking between JSEP & SIP > >> Creation date: 2013-06-12 > >> Group: Individual Submission > >> Number of pages: 13 > >> URL: http://www.ietf.org/internet-drafts/draft-partha- > >> rtcweb-jsep-sip-00.txt > >> Status: http://datatracker.ietf.org/doc/draft-partha-rtcweb- > >> jsep-sip > >> Htmlized: http://tools.ietf.org/html/draft-partha-rtcweb-jsep- > >> sip-00 > >> > >> > >> Abstract: > >> Real time communcation Web (RTCWeb) workgroup defines the real time > >> commmunication using JavaScript Session establishment protocol > >> (JSEP) > >> as an offer/answer mechanism. Session Initiation protocol (SIP) is > >> IETF defined and well deployed protocol for real time communication. > >> This document provides offer & answer interworking between JSEP and > >> SIP. > >> > >> > >> > >> > >> The IETF Secretariat > > > > _______________________________________________ > > 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 > --047d7bf10ab080cd5404defd5adf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable To be honest, the whole SDP O/A affair reminds me the verse from Haddock= 9;s Eyes song by Lewis Carroll:

But I was thinking of a plan
=A0=A0=A0=A0To dye one's = whiskers green,
And always use so large a fan
=A0=A0=A0=A0That they could not be seen.

The whole = thing would be easier to use, simpler to standardize, and much simpler to i= nterop with SIP if instead of O/A underlying C++ API's from Voice and V= ideo engines were mapped to JavaScript.
_____________
Roman Shpount


On Wed, Jun 12, 2013 at 7:11 PM, Matthew= Kaufman (SKYPE) <matthew.kaufman@skype.net> wrote:<= br>
I have a meta review comment: does the fact = that the content of this document is not null mean that the reasoning for c= hoosing SDP O/A as the API surface was faulty?

Matthew Kaufman

(Sent from my iPhone)

On Jun 12, 2013, at 10:55 AM, "Parthasarathi R" <partha@parthasarathi.co.in> wrote:<= br>
> Hi all,
>
> Offer/answer Interworking between JSEP & SIP IETF draft is written= as JSEP (O/A) model is different from SIP O/A and there is a need of mappi= ng document. This draft will act =A0as a building block for developing the = O/A interwork between SIP & JSEP. The draft is available at http://www.ietf.org/internet-drafts/draft-partha-rtcweb-jse= p-sip-00.txt. Could you please provide your valuable review comments. >
> Thanks
> Partha
>
>> -----Original Message-----
>> From: internet-drafts@= ietf.org [mailto:internet-d= rafts@ietf.org]
>> Sent: Wednesday, June 12, 2013 11:07 PM
>> To: Uwe Rauschenbach; Elangovan Manickam; Parthasarathi Ravindran<= br> >> Subject: New Version Notification for draft-partha-rtcweb-jsep-sip= -
>> 00.txt
>>
>>
>> A new version of I-D, draft-partha-rtcweb-jsep-sip-00.txt
>> has been successfully submitted by Parthasarathi Ravindran and pos= ted
>> to the
>> IETF repository.
>>
>> Filename: =A0 =A0 draft-partha-rtcweb-jsep-sip
>> Revision: =A0 =A0 00
>> Title: =A0 =A0 =A0 =A0 Offer & Answer interworking between JSE= P & SIP
>> Creation date: =A0 =A0 2013-06-12
>> Group: =A0 =A0 =A0 =A0 Individual Submission
>> Number of pages: 13
>> URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-dra= fts/draft-partha-
>> rtcweb-jsep-sip-00.txt
>> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc= /draft-partha-rtcweb-
>> jsep-sip
>> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-= partha-rtcweb-jsep-
>> sip-00
>>
>>
>> Abstract:
>> =A0 Real time communcation Web (RTCWeb) workgroup defines the real= time
>> =A0 commmunication using JavaScript Session establishment protocol=
>> (JSEP)
>> =A0 as an offer/answer mechanism. =A0Session Initiation protocol (= SIP) is
>> =A0 IETF defined and well deployed protocol for real time communic= ation.
>> =A0 This document provides offer & answer interworking between= JSEP and
>> =A0 SIP.
>>
>>
>>
>>
>> The IETF Secretariat
>
> _______________________________________________
> 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

--047d7bf10ab080cd5404defd5adf-- From elagerway@gmail.com Wed Jun 12 17:17:37 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFAA21F99B6 for ; Wed, 12 Jun 2013 17:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ib9Pl2mruxPL for ; Wed, 12 Jun 2013 17:17:36 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8C80121F99B2 for ; Wed, 12 Jun 2013 17:17:35 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so7541577wes.12 for ; Wed, 12 Jun 2013 17:17:29 -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=l45H5DwRwQn1snim20AelPLcfVvtoqPEZMA5sgoWIQo=; b=nr4uKduxSG97FiDwX81IUvpI3j4XZfuNS4CiTTNHk4/u910KV7sQArz9C7EFMryiGr c1FIxboE3wlmfT/WcG9FtBQl6/ejJcnjRVztMEsoMrnE/zvzsIerUxYw/0IW+6XNxk1s rlSFUvD0MfaUycxVy4qJUAAV2ZgCgAHtVnknOcJwfQ1ok9kunIJRwEgVRj6dBJEAOKY+ NXUr+4uq5Omm+nlS77kYm1LgJ/ZeP658O4K2ZvhOuFIKmd0MYU5VlicE2FOCQweJM3tw +XBOT74AF8o1RdPA8dB8kAwkJsvzkOEO2LHwuvUmSaYDppVTacS1OQsdn4nQsJMHf1+C +1OA== MIME-Version: 1.0 X-Received: by 10.180.99.232 with SMTP id et8mr6013524wib.17.1371082649893; Wed, 12 Jun 2013 17:17:29 -0700 (PDT) Sender: elagerway@gmail.com Received: by 10.216.22.132 with HTTP; Wed, 12 Jun 2013 17:17:29 -0700 (PDT) In-Reply-To: References: <20130612173723.20266.87116.idtracker@ietfa.amsl.com> <004601ce6795$ee3546a0$ca9fd3e0$@co.in> <9515CA24-1B11-4D40-AC5F-0E54D977C470@skype.net> Date: Wed, 12 Jun 2013 17:17:29 -0700 X-Google-Sender-Auth: AzcqtVlC3cUYZRyK8rFDn6wv60o Message-ID: From: Erik Lagerway To: Roman Shpount Content-Type: multipart/alternative; boundary=f46d041825ac4e023f04defe0e64 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer & Answer interworking between JSEP & SIP draft for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 00:17:37 -0000 --f46d041825ac4e023f04defe0e64 Content-Type: text/plain; charset=ISO-8859-1 +1 Roman *Erik Lagerway | *Hookflash * * **** On Wed, Jun 12, 2013 at 4:27 PM, Roman Shpount wrote: > To be honest, the whole SDP O/A affair reminds me the verse from Haddock's > Eyes song by Lewis Carroll: > > But I was thinking of a plan To dye one's whiskers green, And always > use so large a fan That they could not be seen. > > The whole thing would be easier to use, simpler to standardize, and much > simpler to interop with SIP if instead of O/A underlying C++ API's from > Voice and Video engines were mapped to JavaScript. > _____________ > Roman Shpount > > > On Wed, Jun 12, 2013 at 7:11 PM, Matthew Kaufman (SKYPE) < > matthew.kaufman@skype.net> wrote: > >> I have a meta review comment: does the fact that the content of this >> document is not null mean that the reasoning for choosing SDP O/A as the >> API surface was faulty? >> >> Matthew Kaufman >> >> (Sent from my iPhone) >> >> On Jun 12, 2013, at 10:55 AM, "Parthasarathi R" < >> partha@parthasarathi.co.in> wrote: >> >> > Hi all, >> > >> > Offer/answer Interworking between JSEP & SIP IETF draft is written as >> JSEP (O/A) model is different from SIP O/A and there is a need of mapping >> document. This draft will act as a building block for developing the O/A >> interwork between SIP & JSEP. The draft is available at >> http://www.ietf.org/internet-drafts/draft-partha-rtcweb-jsep-sip-00.txt. >> Could you please provide your valuable review comments. >> > >> > Thanks >> > Partha >> > >> >> -----Original Message----- >> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> >> Sent: Wednesday, June 12, 2013 11:07 PM >> >> To: Uwe Rauschenbach; Elangovan Manickam; Parthasarathi Ravindran >> >> Subject: New Version Notification for draft-partha-rtcweb-jsep-sip- >> >> 00.txt >> >> >> >> >> >> A new version of I-D, draft-partha-rtcweb-jsep-sip-00.txt >> >> has been successfully submitted by Parthasarathi Ravindran and posted >> >> to the >> >> IETF repository. >> >> >> >> Filename: draft-partha-rtcweb-jsep-sip >> >> Revision: 00 >> >> Title: Offer & Answer interworking between JSEP & SIP >> >> Creation date: 2013-06-12 >> >> Group: Individual Submission >> >> Number of pages: 13 >> >> URL: http://www.ietf.org/internet-drafts/draft-partha- >> >> rtcweb-jsep-sip-00.txt >> >> Status: http://datatracker.ietf.org/doc/draft-partha-rtcweb- >> >> jsep-sip >> >> Htmlized: http://tools.ietf.org/html/draft-partha-rtcweb-jsep- >> >> sip-00 >> >> >> >> >> >> Abstract: >> >> Real time communcation Web (RTCWeb) workgroup defines the real time >> >> commmunication using JavaScript Session establishment protocol >> >> (JSEP) >> >> as an offer/answer mechanism. Session Initiation protocol (SIP) is >> >> IETF defined and well deployed protocol for real time communication. >> >> This document provides offer & answer interworking between JSEP and >> >> SIP. >> >> >> >> >> >> >> >> >> >> The IETF Secretariat >> > >> > _______________________________________________ >> > 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 > > --f46d041825ac4e023f04defe0e64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 Roman


Erik Lagerway | = = Hookflash<= span style=3D"color:rgb(0,0,0);font-weight:normal;font-size:13px">=A0
<= /span>


On Wed, Jun 12, 2013 at 4:27 PM, Roman S= hpount <roman@telurix.com> wrote:
To be honest, the whole SDP O/A affair reminds me the verse from Haddock= 9;s Eyes song by Lewis Carroll:

But I was thinking of a plan
=A0=A0=A0=A0To dye one's whiskers green,
And always use so lar= ge a fan
=A0=A0=A0=A0That they could not be seen.

The whole = thing would be easier to use, simpler to standardize, and much simpler to i= nterop with SIP if instead of O/A underlying C++ API's from Voice and V= ideo engines were mapped to JavaScript.
_____________
Roman = Shpount


On Wed, Jun 12, 2013 at 7:11 PM, Matthew= Kaufman (SKYPE) <matthew.kaufman@skype.net> wrote:<= br>
I have a meta review comment: does the fact = that the content of this document is not null mean that the reasoning for c= hoosing SDP O/A as the API surface was faulty?

Matthew Kaufman

(Sent from my iPhone)

On Jun 12, 2013, at 10:55 AM, "Parthasarathi R" <partha@parthasarathi.co.= in> wrote:

> Hi all,
>
> Offer/answer Interworking between JSEP & SIP IETF draft is written= as JSEP (O/A) model is different from SIP O/A and there is a need of mappi= ng document. This draft will act =A0as a building block for developing the = O/A interwork between SIP & JSEP. The draft is available at http://www.ietf.org/internet-drafts/draft-partha-rtcweb-jse= p-sip-00.txt. Could you please provide your valuable review comments. >
> Thanks
> Partha
>
>> -----Original Message-----
>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> Sent: Wednesday, June 12, 2013 11:07 PM
>> To: Uwe Rauschenbach; Elangovan Manickam; Parthasarathi Ravindran<= br> >> Subject: New Version Notification for draft-partha-rtcweb-jsep-sip= -
>> 00.txt
>>
>>
>> A new version of I-D, draft-partha-rtcweb-jsep-sip-00.txt
>> has been successfully submitted by Parthasarathi Ravindran and pos= ted
>> to the
>> IETF repository.
>>
>> Filename: =A0 =A0 draft-partha-rtcweb-jsep-sip
>> Revision: =A0 =A0 00
>> Title: =A0 =A0 =A0 =A0 Offer & Answer interworking between JSE= P & SIP
>> Creation date: =A0 =A0 2013-06-12
>> Group: =A0 =A0 =A0 =A0 Individual Submission
>> Number of pages: 13
>> URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-dra= fts/draft-partha-
>> rtcweb-jsep-sip-00.txt
>> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc= /draft-partha-rtcweb-
>> jsep-sip
>> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-= partha-rtcweb-jsep-
>> sip-00
>>
>>
>> Abstract:
>> =A0 Real time communcation Web (RTCWeb) workgroup defines the real= time
>> =A0 commmunication using JavaScript Session establishment protocol=
>> (JSEP)
>> =A0 as an offer/answer mechanism. =A0Session Initiation protocol (= SIP) is
>> =A0 IETF defined and well deployed protocol for real time communic= ation.
>> =A0 This document provides offer & answer interworking between= JSEP and
>> =A0 SIP.
>>
>>
>>
>>
>> The IETF Secretariat
>
> _______________________________________________
> 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


--f46d041825ac4e023f04defe0e64-- From andrew.hutton@siemens-enterprise.com Thu Jun 13 03:56:35 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E81621F99F0 for ; Thu, 13 Jun 2013 03:56:35 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mPFoy74Ort3 for ; Thu, 13 Jun 2013 03:56:31 -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 2879821F99EF for ; Thu, 13 Jun 2013 03:56:31 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id A53F823F0624; Thu, 13 Jun 2013 12:56:29 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Thu, 13 Jun 2013 12:56:29 +0200 From: "Hutton, Andrew" To: Martin Thomson , Hadriel Kaplan Thread-Topic: [rtcweb] No Interim on SDES at this juncture Thread-Index: AQHOZ49miZ7m4NUb00izoZsadWUrCZkzd5ww Date: Thu, 13 Jun 2013 10:56:28 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115C8A0F@MCHP04MSX.global-ad.net> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> 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] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 10:56:35 -0000 Also agree with Hadriel and Martin here we seem to have been talking about = an interim to discuss SDES for a long time and the IETF86 minutes stated th= at a virtual interim was the way forward. The last time we actually discuss= ed this was at IETF83 about 15 months ago. Personally I think we need to find a way to accommodate SDES in RTCWEB even= if it requires some user authorization and/or indication in the browser re= garding the risks. It is probably the primary interop issue that exists tod= ay regarding interop of WebRTC with the rest of the VoIP world. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Martin Thomson > Sent: 12 June 2013 18:08 > To: Hadriel Kaplan > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] No Interim on SDES at this juncture >=20 > On 12 June 2013 09:29, Hadriel Kaplan > wrote: > > We've had a lot of discussions on the list about this over the past > couple > > years. I thought the general feeling was at this point we needed to > discuss > > it live - either in person or on a con call - because it was hard to > follow > > all the arguments in email. Maybe that was just my feeling, but I > could > > swear some other people said the same thing at the last IETF 86 > meeting or > > Boston interim. >=20 > That's consistent with my understanding. This seems far less > contentious than the video MTI discussion, but continuously deferring > discussion hasn't helped. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From tim@phonefromhere.com Thu Jun 13 04:07:46 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B7F21F99E9 for ; Thu, 13 Jun 2013 04:07:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svNZ54-PkOiZ for ; Thu, 13 Jun 2013 04:07:41 -0700 (PDT) Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1219E21F9A5C for ; Thu, 13 Jun 2013 04:07:40 -0700 (PDT) Received: (qmail 45320 invoked from network); 13 Jun 2013 11:07:39 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp003.apm-internet.net with SMTP; 13 Jun 2013 11:07:39 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 8320718A01DC; Thu, 13 Jun 2013 12:07:39 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 5DD5D18A0169; Thu, 13 Jun 2013 12:07:39 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115C8A0F@MCHP04MSX.global-ad.net> Date: Thu, 13 Jun 2013 12:07:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115C8A0F@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1283) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 11:07:46 -0000 I fear it just _looks_like_ the primary interop issue. As I recall when we last , the main reason that SDES is required is to = facilitate sane multiuser conference video switching without the hub box having to decrypt-encrypt every channel. (I vaguely remember = Hadriel had a centerbox with flames coming out of it in his diagram in = Paris) Unfortunately the plan-a-plan-b-no-plan discussion shows that usecase = isn't gonna work trivially even if we do have SDES. The other reason I can see is that there is an additional round-trip in = the call setup, which does add some delay. I'm not convinced by the 'interop with older devices' argument. Anything = that has been upgraded to deal with ICE and the fattened SDP can also = have DTLS added at the same time. Anything that isn't upgraded isn't = going to work anyway. Based on my experience adding DTLS isn't a huge amount of work. ICE and = SDP changes were much more time consuming. Tim. On 13 Jun 2013, at 11:56, Hutton, Andrew wrote: > Also agree with Hadriel and Martin here we seem to have been talking = about an interim to discuss SDES for a long time and the IETF86 minutes = stated that a virtual interim was the way forward. The last time we = actually discussed this was at IETF83 about 15 months ago. >=20 > Personally I think we need to find a way to accommodate SDES in RTCWEB = even if it requires some user authorization and/or indication in the = browser regarding the risks. It is probably the primary interop issue = that exists today regarding interop of WebRTC with the rest of the VoIP = world. >=20 > Regards > Andy >=20 >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Martin Thomson >> Sent: 12 June 2013 18:08 >> To: Hadriel Kaplan >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] No Interim on SDES at this juncture >>=20 >> On 12 June 2013 09:29, Hadriel Kaplan >> wrote: >>> We've had a lot of discussions on the list about this over the past >> couple >>> years. I thought the general feeling was at this point we needed to >> discuss >>> it live - either in person or on a con call - because it was hard to >> follow >>> all the arguments in email. Maybe that was just my feeling, but I >> could >>> swear some other people said the same thing at the last IETF 86 >> meeting or >>> Boston interim. >>=20 >> That's consistent with my understanding. This seems far less >> contentious than the video MTI discussion, but continuously deferring >> discussion hasn't helped. >> _______________________________________________ >> 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 harald@alvestrand.no Thu Jun 13 05:59:58 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0009421F9385 for ; Thu, 13 Jun 2013 05:59:57 -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, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4v+3htn6bmT for ; Thu, 13 Jun 2013 05:59:52 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 03F8421F940D for ; Thu, 13 Jun 2013 05:59:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AE4E039E172 for ; Thu, 13 Jun 2013 14:59:49 +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 eWq8xihu-P0j for ; Thu, 13 Jun 2013 14:59:49 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E472E39E058 for ; Thu, 13 Jun 2013 14:59:48 +0200 (CEST) Message-ID: <51B9C244.9050705@alvestrand.no> Date: Thu, 13 Jun 2013 14:59:48 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115C8A0F@MCHP04MSX.global-ad.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 12:59:58 -0000 On 06/13/2013 01:07 PM, Tim Panton wrote: > I fear it just _looks_like_ the primary interop issue. > > As I recall when we last , the main reason that SDES is required is to facilitate sane multiuser conference video switching without > the hub box having to decrypt-encrypt every channel. (I vaguely remember Hadriel had a centerbox with flames coming out of it in his diagram in Paris) > Unfortunately the plan-a-plan-b-no-plan discussion shows that usecase isn't gonna work trivially even if we do have SDES. > > The other reason I can see is that there is an additional round-trip in the call setup, which does add some delay. > > I'm not convinced by the 'interop with older devices' argument. Anything that has been upgraded to deal with ICE and the fattened SDP can also have DTLS added at the same time. Anything that isn't upgraded isn't going to work anyway. > Based on my experience adding DTLS isn't a huge amount of work. ICE and SDP changes were much more time consuming. My impression from Paris was that if the WebRTC world supports EKT, then gatewaying into an SDES realm requires some fancy key-shuffling, nothing more. If the WebRTC world does not support EKT, then decrypt/encrypt will work in all cases. My impression from the performance numbers people have quoted is that the CPU cost of decrypt/encrypt doesn't cost enough to be the deal-breaker between "viable solution" and "not viable solution"; other things weigh far more on capex/opex. The architectural/non-cost argument I see against decrypt/encrypt is "the gateway wants to be able to disclaim the ability to look at the bits". Agree with Tim about the relative difficulty of adding the needed features. From ibc@aliax.net Thu Jun 13 07:55:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268B621F941D for ; Thu, 13 Jun 2013 07:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLJOK7qYjSKZ for ; Thu, 13 Jun 2013 07:55:26 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id E885E21F91A5 for ; Thu, 13 Jun 2013 07:55:25 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 5so4143944qeb.31 for ; Thu, 13 Jun 2013 07:55:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=l2AZRKp2fc4pHK/DpTR5IBPBrCJifB3HeNfYY0EETJs=; b=FNpXjK8GDS//QNrrPjxb14J/Sv0ht+sYCrlVROV8/C+9NC3ufEUnlWdH9f8a/G55KF SSUwKNA357YgFff07PvsHZnFcHA2DC27fHoE4kotNMtHStWxsB8CIf7tSijEajvSgv+c sN/G+gIM6HhCaq4V1wVY7S58X0uqqH9vAMD8SMEaayeGWS0pvgOIv53lZRe6V8k69/Az bZuGBymYp2gklMtwl6mRPLHDbb+SWRuUNvpx0Uxz3eXX0MRN7IN4S7vC5K34YplaqmNk MU4uf+SA/aiLo8EX7P/qllJ9mCkOnRmX+rbMc6dfxjII77kTF+1jlt+8KGGCFk37l74t ugXA== X-Received: by 10.224.187.129 with SMTP id cw1mr3450140qab.68.1371135323117; Thu, 13 Jun 2013 07:55:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Thu, 13 Jun 2013 07:55:03 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 13 Jun 2013 16:55:03 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlfilbUhK6cNpI5a4e/Sf2RmjTApvmXpH5wl4xYf4QZq7xa8Qm36/jgqGP/t86dY7CMwyr1 Subject: [rtcweb] Why is required to have local streams before running ICE gathering? (another SDP limitation?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 14:55:31 -0000 Hi, let me expose the following simple case: 1) SIP application in the web. 2) Alice receives INVITE from Bob with audio and video. 3) Alice JS UA is ringing, Alice does not answer or reject the call yet. 4) Alice JS UA does not know whether Alice would answer with audio and/or v= ideo. 5) Alice JS UA starts ICE gathering and obtains all its ICE candidates. 6) Alice presses "Answer with audio and video". 7) Alice JS UA calls getUserMedia, creates the PC, gets the SDP and passes it to Bob JS UA in a SIP 200 response. Well, this is not possible in WebRTC due to step 5. Unfortunately before ICE gathering, the local PC must be set with the local SDP, so getUserMedia is required to happen before ICE gathering. But we cannot prompt Alice with the getUserMedia pop-up while she has not yet decided to answer the incoming call. The fact is that both the audio and video will use the same UDP channel/transport, so having ICE candidates for the audio and the video m lines is just unneeded. So IMHO this is another issue due to the usage of SDP, right? or may be I am wrong? If so please let me know a use case in which the browser would mantain two different UDP channels/transports for the same "call" (a single SDP O/A). This is just for "legacy interoperability", right? this is, for the case in which the remote peer is a not-full-WebRTC device and uses different UDP channels/transports for each m line in the SDP. If so, would not be MUCH easier just to *require* as per WebRTC specs that two peers MUST use a single UDP channel/transport for each SDP O/A? Thanks a lot. -- I=C3=B1aki Baz Castillo From ekr@rtfm.com Thu Jun 13 08:22:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB0621F99CD for ; Thu, 13 Jun 2013 08:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.166 X-Spam-Level: X-Spam-Status: No, score=-99.166 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dd58e1cst5-m for ; Thu, 13 Jun 2013 08:21:56 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 893DC21F99C5 for ; Thu, 13 Jun 2013 08:21:53 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id n1so2419453qcw.2 for ; Thu, 13 Jun 2013 08:21:53 -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=7vxE87QVYYgybifqTeWZPnVKe3aDSX9LNG6v3GtBD1E=; b=EatcxizKRaxBRvZWup1XhGWVWpiQFOo5yrESBB9Vql+yQhAknUqnx1WL72vv13W8Bg o7uK9tjRCYl0NQxoFJZ703IHC0RR8Lcp+9gLgC7j9ccnGH2d53h6t/NxWDFs4u6ZrK31 JLlzO7WJW4XzcMHpbv4fsgjHUGLoTUw8LZEKSw7oORq7qWw9G4h9WCbQP5p7lta6tR54 33oYbyyp32Wr2w1bP6zej6uIy7E2XXdEORKT3qe3c0sC0bXcwq/jXSOW3Gmg6kZOg/HI OvTAOD6Ut8KWj9nD5YPpQpsdel3RCSnirh2rsOlrfYSkGkjqjH3EQUBMrF892dua3BV4 6GZA== X-Received: by 10.224.205.8 with SMTP id fo8mr3528784qab.62.1371136912927; Thu, 13 Jun 2013 08:21:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.0.163 with HTTP; Thu, 13 Jun 2013 08:21:12 -0700 (PDT) X-Originating-IP: [74.95.2.170] In-Reply-To: References: From: Eric Rescorla Date: Thu, 13 Jun 2013 08:21:12 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=20cf3005dc0aa2497504df0ab06b X-Gm-Message-State: ALoCoQlhBirH9dOHoWhBFHqkcHvwJvxsCEv9qFiAnaKQYFKuT3Rjf45rk5922SI+4PS8jZpUeYwN Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Why is required to have local streams before running ICE gathering? (another SDP limitation?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:22:02 -0000 --20cf3005dc0aa2497504df0ab06b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 13, 2013 at 7:55 AM, I=F1aki Baz Castillo wrote= : > Hi, let me expose the following simple case: > > > 1) SIP application in the web. > > 2) Alice receives INVITE from Bob with audio and video. > > 3) Alice JS UA is ringing, Alice does not answer or reject the call yet. > > 4) Alice JS UA does not know whether Alice would answer with audio and/or > video. > > 5) Alice JS UA starts ICE gathering and obtains all its ICE candidates. > > 6) Alice presses "Answer with audio and video". > > 7) Alice JS UA calls getUserMedia, creates the PC, gets the SDP and > passes it to Bob JS UA in a SIP 200 response. > > > Well, this is not possible in WebRTC due to step 5. Unfortunately > before ICE gathering, the local PC must be set with the local SDP, so > getUserMedia is required to happen before ICE gathering. > I don't think that there is an intention that ICE gathering must not happen prior to setLocal: 1. There is agreement that there should be a mechanism to pre-specify the size of a candidate pool to gather, though I just glanced in the spec and I didn't see it. (May have missed it though). 2. Firefox, at least, gathers some candidates as soon as the PC is created, and I don't think this should be forbidden. (Though there is some disagreement about this.) > But we cannot prompt Alice with the getUserMedia pop-up while she has > not yet decided to answer the incoming call. > > The fact is that both the audio and video will use the same UDP > channel/transport, so having ICE candidates for the audio and the > video m lines is just unneeded. > > So IMHO this is another issue due to the usage of SDP, right? or may > be I am wrong? If so please let me know a use case in which the > browser would mantain two different UDP channels/transports for the > same "call" (a single SDP O/A). > It's not a matter of using SDP, it's a matter of being able to interop at all with endpoints which don't bundle. -Ekr --20cf3005dc0aa2497504df0ab06b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 13, 2013 at 7:55 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
Hi, let me expose the following simple case:=


1) SIP application in the web.

2) Alice receives INVITE from Bob with audio and video.

3) Alice JS UA is ringing, Alice does not answer or reject the call yet.
4) Alice JS UA does not know whether Alice would answer with audio and/or v= ideo.

5) Alice JS UA starts ICE gathering and obtains all its ICE candidates.

6) Alice presses "Answer with audio and video".

7) Alice JS UA calls getUserMedia, creates the PC, gets the SDP and
passes it to Bob JS UA in a SIP 200 response.


Well, this is not possible in WebRTC due to step 5. Unfortunately
before ICE gathering, the local PC must be set with the local SDP, so
getUserMedia is required to happen before ICE gathering.


2. Firefox, at least, gathers some candidat= es as soon as the PC is
created, and I don't think this= should be forbidden. (Though there is
some disagreement ab= out this.)


=A0
But we cannot prompt Alice with the getUserMedia pop-up while she has
not yet decided to answer the incoming call.

The fact is that both the audio and video will use the same UDP
channel/transport, so having ICE candidates for the audio and the
video m lines is just unneeded.

So IMHO this is another issue due to the usage of SDP, right? or may
be I am wrong? If so please let me know a use case in which the
browser would mantain two different UDP channels/transports for the
same "call" (a single SDP O/A).

It's not a matter of using SDP, it's a matter of being abl= e to interop
= --20cf3005dc0aa2497504df0ab06b-- From ekr@rtfm.com Thu Jun 13 08:23:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17D321F99D2 for ; Thu, 13 Jun 2013 08:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.645 X-Spam-Level: X-Spam-Status: No, score=-99.645 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05sLngJ6HPS3 for ; Thu, 13 Jun 2013 08:23:46 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id DD5EF21F99CD for ; Thu, 13 Jun 2013 08:23:45 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c10so5499878qcz.14 for ; Thu, 13 Jun 2013 08:23:45 -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=9s6huKtweRLjrlYZmVRMX6F55FKOLqre0G3VRyNPjuI=; b=FQT44mXv7H6oMAcaIiAzvd1Rd1MR97cS7ih8w9bxdbuD2bwP/N+6M5j7/aEqxQkHbI 57mdfYFzkoP65EBKStI48yDQKoCmQxb0VZH/JYLNEXUQ65wOkaeotMi5EtjlSd9HNdIF 7BCVmvuP/MXEGeA9AsR77nQkmJ/1/Nz8k+ImCyj3sZdNMNf9gWSz3DGHcjHnFEnJp4tI L9tUHuib1MhKL9t23ZLBmLe694zzykyaVdZMQpJ/aa+0pM4z7EcukZJ3PtBXy207t5gD EmMKcHmOaQ+dU62GhOlwyfQxUlmuigTET+LPRtGTlqidEA7bxR+0kprDrJ1VLpP7pqA9 aYyw== X-Received: by 10.49.71.203 with SMTP id x11mr2037634qeu.19.1371137025389; Thu, 13 Jun 2013 08:23:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.0.163 with HTTP; Thu, 13 Jun 2013 08:23:05 -0700 (PDT) X-Originating-IP: [74.95.2.170] In-Reply-To: References: From: Eric Rescorla Date: Thu, 13 Jun 2013 08:23:05 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b6dc47456489204df0ab78a X-Gm-Message-State: ALoCoQmdtrSnU6hYa9+yj+M0xXwEKY4JSGRg7dATvhpSm4lxRKJRXW8DWsTEOaKExmLdTjucM4IA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Why is required to have local streams before running ICE gathering? (another SDP limitation?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:23:52 -0000 --047d7b6dc47456489204df0ab78a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 13, 2013 at 8:21 AM, Eric Rescorla wrote: > > > > On Thu, Jun 13, 2013 at 7:55 AM, I=F1aki Baz Castillo wro= te: > >> Hi, let me expose the following simple case: >> >> >> 1) SIP application in the web. >> >> 2) Alice receives INVITE from Bob with audio and video. >> >> 3) Alice JS UA is ringing, Alice does not answer or reject the call yet. >> >> 4) Alice JS UA does not know whether Alice would answer with audio and/o= r >> video. >> >> 5) Alice JS UA starts ICE gathering and obtains all its ICE candidates. >> >> 6) Alice presses "Answer with audio and video". >> >> 7) Alice JS UA calls getUserMedia, creates the PC, gets the SDP and >> passes it to Bob JS UA in a SIP 200 response. >> >> >> Well, this is not possible in WebRTC due to step 5. Unfortunately >> before ICE gathering, the local PC must be set with the local SDP, so >> getUserMedia is required to happen before ICE gathering. >> > > I don't think that there is an intention that ICE gathering must not happ= en > prior to setLocal: > > 1. There is agreement that there should be a mechanism to pre-specify > the size of a candidate pool to gather, though I just glanced in the spec > and I didn't see it. (May have missed it though). > I see that there still is some (not quite up to date) text here: 1. Create an ICE Agent as defined in [ICE] and let connection's RTCPeerConnection ICE Agent be that ICE Agent and provide it the STUN and TURN servers from the configuration array. The I= CE Agent will proceed with gathering as soon as the IceTransports constrain= t is not set to "none". At this point the ICE Agent does not know how many ICE components it needs (and hence the number of candidates to gather), = but it can make a reasonable assumption such as 2. As the RTCPeerConnection object gets more information, the ICE Agent can adjust the number of components= . -Ekr > 2. Firefox, at least, gathers some candidates as soon as the PC is > created, and I don't think this should be forbidden. (Though there is > some disagreement about this.) > > > > >> But we cannot prompt Alice with the getUserMedia pop-up while she has >> not yet decided to answer the incoming call. >> >> The fact is that both the audio and video will use the same UDP >> channel/transport, so having ICE candidates for the audio and the >> video m lines is just unneeded. >> >> So IMHO this is another issue due to the usage of SDP, right? or may >> be I am wrong? If so please let me know a use case in which the >> browser would mantain two different UDP channels/transports for the >> same "call" (a single SDP O/A). >> > > It's not a matter of using SDP, it's a matter of being able to interop > at all with endpoints which don't bundle. > > -Ekr > > --047d7b6dc47456489204df0ab78a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 13, 2013 at 8:21 AM, Eric Rescorla &l= t;ekr@rtfm.com> wrote:



On Thu, Jun 13, 2013 at 7:55 AM, I=F1aki Baz Castillo <ibc@a= liax.net> wrote:
Hi, let me expose the following simple case:


1) SIP application in the web.

2) Alice receives INVITE from Bob with audio and video.

3) Alice JS UA is ringing, Alice does not answer or reject the call yet.
4) Alice JS UA does not know whether Alice would answer with audio and/or v= ideo.

5) Alice JS UA starts ICE gathering and obtains all its ICE candidates.

6) Alice presses "Answer with audio and video".

7) Alice JS UA calls getUserMedia, creates the PC, gets the SDP and
passes it to Bob JS UA in a SIP 200 response.


Well, this is not possible in WebRTC due to step 5. Unfortunately
before ICE gathering, the local PC must be set with the local SDP, so
getUserMedia is required to happen before ICE gathering.

I don't think that there is an intention that I= CE gathering must not happen
prior to setLocal:

1. There is agreement that there should be a mechanism to pr= e-specify
the size of a candidate pool to gather, though I just g= lanced in the spec
and I didn't see it. (May have missed it t= hough).

I see that there s= till is some (not quite up to date) text here:

  • Create an ICE Agent as defined in [ICE] and let=A0connection's=A0RTCPeerConnection=A0ICE Agent be that ICE Agent= and provide it the STUN and TURN servers from the configuration array. The= ICE Agent will proceed with gathering as soon as the IceTransports constra= int is not set to "none". At this point the ICE Agent does not kn= ow how many ICE components it needs (and hence the number of candidates to = gather), but it can make a reasonable assumption such as 2. As the=A0RTCPeerConnection=A0object gets more i= nformation, the ICE Agent can adjust the number of components.



    -Ekr


    • =A0
    2. Firefox, at least, gathers some candidates as soon as the PC is
    created, and I don't think this should be forbidden. (Though there i= s
    some disagreement about this.)


    =A0
    But we cannot prompt Alice with the getUserMedia pop-up while she has
    not yet decided to answer the incoming call.

    The fact is that both the audio and video will use the same UDP
    channel/transport, so having ICE candidates for the audio and the
    video m lines is just unneeded.

    So IMHO this is another issue due to the usage of SDP, right? or may
    be I am wrong? If so please let me know a use case in which the
    browser would mantain two different UDP channels/transports for the
    same "call" (a single SDP O/A).

    It's not a matter of using SDP, it's a matter of being abl= e to interop
    at all with endpoints which don't bundle.

    -Ekr


    --047d7b6dc47456489204df0ab78a-- From tim@phonefromhere.com Thu Jun 13 08:30:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB0B21F8F3A for ; Thu, 13 Jun 2013 08:30:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFFaoZkU0zIb for ; Thu, 13 Jun 2013 08:30:49 -0700 (PDT) Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8317721F8AE8 for ; Thu, 13 Jun 2013 08:30:48 -0700 (PDT) Received: (qmail 16464 invoked from network); 13 Jun 2013 15:30:46 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp003.apm-internet.net with SMTP; 13 Jun 2013 15:30:46 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 77EBF18A061E; Thu, 13 Jun 2013 16:30:46 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 5F48718A03AA; Thu, 13 Jun 2013 16:30:46 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <51B9C244.9050705@alvestrand.no> Date: Thu, 13 Jun 2013 16:30:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115C8A0F@MCHP04MSX.global-ad.net> <51B9C244.9050705@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1283) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:30:57 -0000 On 13 Jun 2013, at 13:59, Harald Alvestrand wrote: >=20 >=20 > The architectural/non-cost argument I see against decrypt/encrypt is = "the gateway wants to be able to disclaim the ability to look at the = bits". Which is implausible because it will probably have to have the DES keys = to be able to decode RTCP at least. I'm not sure how much implausible deniability is worth these days. T.= From partha@parthasarathi.co.in Thu Jun 13 09:41:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F30721F930C for ; Thu, 13 Jun 2013 09:41:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kE+kg9geUh+H for ; Thu, 13 Jun 2013 09:41:26 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.153]) by ietfa.amsl.com (Postfix) with ESMTP id 3C64D21F9473 for ; Thu, 13 Jun 2013 09:41:25 -0700 (PDT) Received: from userPC (unknown [122.179.62.1]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 329FF868D3A; Thu, 13 Jun 2013 16:41:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1371141684; bh=VsMXk58Oxg55GneYfgZuIxdsHkEUhujvsupxDrRRy6Y=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=LQXVinjHz9NjNTT7h50eI/H44AfjUxNzMX3+0R/VjqNMxcggDg+m9o/0p9OxySTEo oKQuGXkal8O3qkRvTS5rwajya+uAcMlcTM0IqKqkchtSJUniGa5JMTdMFtszj892xN C1KoKX0VRb2lfzwSOgVi5l9MdvyaB+RfPeqzSSjM= From: "Parthasarathi R" To: "'Christer Holmberg'" , References: <7594FB04B1934943A5C02806D1A2204B1C3893F6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3893F6@ESESSMB209.ericsson.se> Date: Thu, 13 Jun 2013 22:11:16 +0530 Message-ID: <008101ce6854$d509bd90$7f1d38b0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5nmEmmXFOwKCwpR1e2EqmBZUP0kQAuVoPw Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0203.51B9F634.0106, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.156 Subject: Re: [rtcweb] Offer & Answer interworking between JSEP & SIP draft for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 16:41:31 -0000 Hi Christer, I understand your concern about forking solution with two O/A and it is documented in sec 5.5 as=20 " The assumption in Fig 5 is that ANSWER2 and ANSWER4 are same. In case they are different, there is a need of extra offer-answer between JSEP-SIP GW and SIP UA3" As you indicated, "PRANSWER" state is not used in the callflow because=20 1) PRANSWER related states don't allow for second "OFFER" 2) SIP Parallel forking is not possible with JSEP as of now I agree with you that some sort of cloning resolves SIP forking issue. Unfortunately JSEP does not support cloning which forces to map SIP = ANSWER to JSEP OFFER during forking.=20 Thanks Partha=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, June 12, 2013 11:41 PM > To: Parthasarathi R; rtcweb@ietf.org > Cc: 'Elangovan Manickam' > Subject: VS: [rtcweb] Offer & Answer interworking between JSEP & SIP > draft for review >=20 > Hi, >=20 > I have some issues with your way of solving forking. >=20 > In sections 5.5 and 5.6, you are mapping SIP Answers to JSEP Offer. I > think that is a very bad thing to do, because what happens if = something > has changed in the associated JSEP Answer? Then you'll have to map = that > into a SIP Offer, and then again map the associated SIP Answer into a > JSEP Offer. Etc etc etc. >=20 > I do like that fact that you are not using PRANSWER, but unfortunately > I don't think the suggested way will work :) >=20 > My suggestion is still that we should support some kind of "cloning" = (I > use that as a generic term), in order to support forking. >=20 > Regards, >=20 > Christer >=20 >=20 > -----Alkuper=E4inen viesti----- > L=E4hett=E4j=E4: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] > Puolesta Parthasarathi R > L=E4hetetty: 12. kes=E4kuuta 2013 20:55 > Vastaanottaja: rtcweb@ietf.org > Kopio: 'Elangovan Manickam' > Aihe: [rtcweb] Offer & Answer interworking between JSEP & SIP draft = for > review >=20 > Hi all, >=20 > Offer/answer Interworking between JSEP & SIP IETF draft is written as > JSEP (O/A) model is different from SIP O/A and there is a need of > mapping document. This draft will act as a building block for > developing the O/A interwork between SIP & JSEP. The draft is = available > at http://www.ietf.org/internet-drafts/draft-partha-rtcweb-jsep-sip- > 00.txt. Could you please provide your valuable review comments. >=20 > Thanks > Partha >=20 > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Wednesday, June 12, 2013 11:07 PM > > To: Uwe Rauschenbach; Elangovan Manickam; Parthasarathi Ravindran > > Subject: New Version Notification for draft-partha-rtcweb-jsep-sip- > > 00.txt > > > > > > A new version of I-D, draft-partha-rtcweb-jsep-sip-00.txt > > has been successfully submitted by Parthasarathi Ravindran and = posted > > to the IETF repository. > > > > Filename: draft-partha-rtcweb-jsep-sip > > Revision: 00 > > Title: Offer & Answer interworking between JSEP & SIP > > Creation date: 2013-06-12 > > Group: Individual Submission > > Number of pages: 13 > > URL: http://www.ietf.org/internet-drafts/draft-partha- > > rtcweb-jsep-sip-00.txt > > Status: = http://datatracker.ietf.org/doc/draft-partha-rtcweb- > > jsep-sip > > Htmlized: = http://tools.ietf.org/html/draft-partha-rtcweb-jsep- > > sip-00 > > > > > > Abstract: > > Real time communcation Web (RTCWeb) workgroup defines the real > time > > commmunication using JavaScript Session establishment protocol > > (JSEP) > > as an offer/answer mechanism. Session Initiation protocol (SIP) > is > > IETF defined and well deployed protocol for real time > communication. > > This document provides offer & answer interworking between JSEP > and > > SIP. > > > > > > > > > > The IETF Secretariat >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From partha@parthasarathi.co.in Thu Jun 13 10:08:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF2421F99C5 for ; Thu, 13 Jun 2013 10:08:39 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nM5sbXlIj-1 for ; Thu, 13 Jun 2013 10:08:35 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.155]) by ietfa.amsl.com (Postfix) with ESMTP id 023DC21F99C2 for ; Thu, 13 Jun 2013 10:08:35 -0700 (PDT) Received: from userPC (unknown [122.179.62.1]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id F3310868A5A; Thu, 13 Jun 2013 17:08:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1371143314; bh=MXwN2YWZV9FYNOH9eGmMbi2+PWQA9/6NlZHSKpmdh/I=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=jxA3MgrEU/69zpdMgu0DJqc8jXb4v87TOLPCzD50pZ/IR1hsXHUumCKLKyD6rBR88 /00MDFTc6119zS42hBeRn3bGKzp7JYpmH2hIjfoXEccIEyzw2LETVqHDANNPOHqQL9 ZjVN+09g6DByYtQe7lpA32SpyQjhoeNVrK/rBXlk= From: "Parthasarathi R" To: "'Erik Lagerway'" , "'Roman Shpount'" , References: <20130612173723.20266.87116.idtracker@ietfa.amsl.com> <004601ce6795$ee3546a0$ca9fd3e0$@co.in> <9515CA24-1B11-4D40-AC5F-0E54D977C470@skype.net> In-Reply-To: Date: Thu, 13 Jun 2013 22:38:22 +0530 Message-ID: <008901ce6858$a04aa3e0$e0dfeba0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008A_01CE6886.BA02DFE0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5ny2+tmJMPMPfDTdiVwALdqSQQcAAisZiA Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0204.51B9FC92.0102, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.156 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Offer & Answer interworking between JSEP & SIP draft for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 17:08:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008A_01CE6886.BA02DFE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, This draft is written as per the current JSEP draft. This draft will be updated inline with future revision of JSEP. Thanks Partha From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Erik Lagerway Sent: Thursday, June 13, 2013 5:47 AM To: Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Offer & Answer interworking between JSEP & SIP draft for review +1 Roman Erik Lagerway | Hookflash On Wed, Jun 12, 2013 at 4:27 PM, Roman Shpount wrote: To be honest, the whole SDP O/A affair reminds me the verse from Haddock's Eyes song by Lewis Carroll: But I was thinking of a plan To dye one's whiskers green, And always use so large a fan That they could not be seen. The whole thing would be easier to use, simpler to standardize, and much simpler to interop with SIP if instead of O/A underlying C++ API's from Voice and Video engines were mapped to JavaScript. _____________ Roman Shpount On Wed, Jun 12, 2013 at 7:11 PM, Matthew Kaufman (SKYPE) wrote: I have a meta review comment: does the fact that the content of this document is not null mean that the reasoning for choosing SDP O/A as the API surface was faulty? Matthew Kaufman (Sent from my iPhone) On Jun 12, 2013, at 10:55 AM, "Parthasarathi R" wrote: > Hi all, > > Offer/answer Interworking between JSEP & SIP IETF draft is written as JSEP (O/A) model is different from SIP O/A and there is a need of mapping document. This draft will act as a building block for developing the O/A interwork between SIP & JSEP. The draft is available at http://www.ietf.org/internet-drafts/draft-partha-rtcweb-jsep-sip-00.txt. Could you please provide your valuable review comments. > > Thanks > Partha > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, June 12, 2013 11:07 PM >> To: Uwe Rauschenbach; Elangovan Manickam; Parthasarathi Ravindran >> Subject: New Version Notification for draft-partha-rtcweb-jsep-sip- >> 00.txt >> >> >> A new version of I-D, draft-partha-rtcweb-jsep-sip-00.txt >> has been successfully submitted by Parthasarathi Ravindran and posted >> to the >> IETF repository. >> >> Filename: draft-partha-rtcweb-jsep-sip >> Revision: 00 >> Title: Offer & Answer interworking between JSEP & SIP >> Creation date: 2013-06-12 >> Group: Individual Submission >> Number of pages: 13 >> URL: http://www.ietf.org/internet-drafts/draft-partha- >> rtcweb-jsep-sip-00.txt >> Status: http://datatracker.ietf.org/doc/draft-partha-rtcweb- >> jsep-sip >> Htmlized: http://tools.ietf.org/html/draft-partha-rtcweb-jsep- >> sip-00 >> >> >> Abstract: >> Real time communcation Web (RTCWeb) workgroup defines the real time >> commmunication using JavaScript Session establishment protocol >> (JSEP) >> as an offer/answer mechanism. Session Initiation protocol (SIP) is >> IETF defined and well deployed protocol for real time communication. >> This document provides offer & answer interworking between JSEP and >> SIP. >> >> >> >> >> The IETF Secretariat > > _______________________________________________ > 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 ------=_NextPart_000_008A_01CE6886.BA02DFE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi all,

     

    This draft is written as per the current JSEP draft. This = draft will be updated inline with future revision of JSEP. =

     

    Thanks

    Partha

     

     

    From:= rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Erik Lagerway
    Sent: Thursday, June 13, 2013 5:47 AM
    To: Roman Shpount
    Cc: rtcweb@ietf.org
    Subject: Re: [rtcweb] Offer & Answer interworking between = JSEP & SIP draft for review

     

    +1 Roman

     


     

    On Wed, Jun 12, 2013 at 4:27 PM, Roman Shpount = <roman@telurix.com> wrote:

    To be honest, the whole SDP O/A affair reminds me = the verse from Haddock's Eyes song by Lewis Carroll:

     

    But I was thinking of a = plan

        To dye one's = whiskers green,

    And always use so large a = fan

        That they = could not be seen.

     

    The whole thing would = be easier to use, simpler to standardize, and much simpler to interop with SIP if = instead of O/A underlying C++ API's from Voice and Video engines were mapped to JavaScript.

    _____________
    Roman Shpount

     

    On Wed, Jun 12, 2013 = at 7:11 PM, Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net> = wrote:

    I have a meta review = comment: does the fact that the content of this document is not null mean that = the reasoning for choosing SDP O/A as the API surface was faulty?

    Matthew Kaufman

    (Sent from my iPhone)


    On Jun 12, 2013, at 10:55 AM, "Parthasarathi R" <partha@parthasarathi.co.in> wrote:

    > Hi all,
    >
    > Offer/answer Interworking between JSEP & SIP IETF draft is = written as JSEP (O/A) model is different from SIP O/A and there is a need of = mapping document. This draft will act  as a building block for developing = the O/A interwork between SIP & JSEP. The draft is available at http://www.ietf.org/internet-drafts/draft-partha-rtcweb= -jsep-sip-00.txt. Could you please provide your valuable review comments.
    >
    > Thanks
    > Partha
    >
    >> -----Original Message-----
    >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
    >> Sent: Wednesday, June 12, 2013 11:07 PM
    >> To: Uwe Rauschenbach; Elangovan Manickam; Parthasarathi = Ravindran
    >> Subject: New Version Notification for = draft-partha-rtcweb-jsep-sip-
    >> 00.txt
    >>
    >>
    >> A new version of I-D, draft-partha-rtcweb-jsep-sip-00.txt
    >> has been successfully submitted by Parthasarathi Ravindran and = posted
    >> to the
    >> IETF repository.
    >>
    >> Filename:     draft-partha-rtcweb-jsep-sip
    >> Revision:     00
    >> Title:         Offer & Answer = interworking between JSEP & SIP
    >> Creation date:     2013-06-12
    >> Group:         Individual Submission
    >> Number of pages: 13
    >> URL:             http://www.ietf.org/internet-drafts/draft-partha- >> rtcweb-jsep-sip-00.txt
    >> Status:          http://datatracker.ietf.org/doc/draft-partha-rtcweb-
    >> jsep-sip
    >> Htmlized:            http://tools.ietf.org/html/draft-partha-rtcweb-jsep-
    >> sip-00
    >>
    >>
    >> Abstract:
    >>   Real time communcation Web (RTCWeb) workgroup defines = the real time
    >>   commmunication using JavaScript Session establishment = protocol
    >> (JSEP)
    >>   as an offer/answer mechanism.  Session Initiation = protocol (SIP) is
    >>   IETF defined and well deployed protocol for real time communication.
    >>   This document provides offer & answer interworking = between JSEP and
    >>   SIP.
    >>
    >>
    >>
    >>
    >> The IETF Secretariat
    >
    > _______________________________________________
    > 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

     

    ------=_NextPart_000_008A_01CE6886.BA02DFE0-- From dwing@cisco.com Thu Jun 13 12:14:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CCC21F9AC8 for ; Thu, 13 Jun 2013 12:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUCaRAVb0THh for ; Thu, 13 Jun 2013 12:14:30 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id F3F7021F97CA for ; Thu, 13 Jun 2013 12:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2318; q=dns/txt; s=iport; t=1371150870; x=1372360470; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Zwr8FB4+RAHWiOpPgTyzjdvj4qr9e9ktaEXt23SyHgE=; b=aatyZm3ulkw4ky5/KmnNs8wL4cx+GtYYcldyzwr9LoO5PxxPTgkq9hdt 0QqUMjRyWXsQlPZOMnOiLPcoKGoWONs3bAMGVoownbnu/yPEDgLW1Gzjt fGzSOqRJOQr12vzHHi4C8M87dY6hECtzcSsb4Q0ANeYLNqJxzSFdePTt7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAKEZulGrRDoG/2dsb2JhbABbgwkwvwaBAhZ0giMBAQECAQEBAQE3LgYLBQsLGC4nMAYTCRKHbQUNu1COHnIzB4J/YQOJII4hkUKDLxyBLg X-IronPort-AV: E=Sophos;i="4.87,860,1363132800"; d="scan'208";a="83461405" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 13 Jun 2013 19:14:28 +0000 Received: from sjc-vpn2-277.cisco.com (sjc-vpn2-277.cisco.com [10.21.113.21]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5DJERr2011883; Thu, 13 Jun 2013 19:14:27 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <51B9C244.9050705@alvestrand.no> Date: Thu, 13 Jun 2013 12:14:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115C8A0F@MCHP04MSX.global-ad.net> <51B9C244.9050705@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1508) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 19:14:34 -0000 On Jun 13, 2013, at 5:59 AM, Harald Alvestrand = wrote: > On 06/13/2013 01:07 PM, Tim Panton wrote: >> I fear it just _looks_like_ the primary interop issue. >>=20 >> As I recall when we last , the main reason that SDES is required is = to facilitate sane multiuser conference video switching without >> the hub box having to decrypt-encrypt every channel. (I vaguely = remember Hadriel had a centerbox with flames coming out of it in his = diagram in Paris) It was my presentation at IETF83 in Paris. >> Unfortunately the plan-a-plan-b-no-plan discussion shows that usecase = isn't gonna work trivially even if we do have SDES. >>=20 >> The other reason I can see is that there is an additional round-trip = in the call setup, which does add some delay. >>=20 >> I'm not convinced by the 'interop with older devices' argument. = Anything that has been upgraded to deal with ICE and the fattened SDP = can also have DTLS added at the same time. Anything that isn't upgraded = isn't going to work anyway. >> Based on my experience adding DTLS isn't a huge amount of work. ICE = and SDP changes were much more time consuming. >=20 > My impression from Paris was that if the WebRTC world supports EKT, = then gatewaying into an SDES realm requires some fancy key-shuffling, = nothing more. Right -- EKT is what makes the flames go away. Slide 28 of = http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf shows = the flames, and the flames go away when we add EKT on slide 33. >=20 > If the WebRTC world does not support EKT, then decrypt/encrypt will = work in all cases. > My impression from the performance numbers people have quoted is that = the CPU cost of decrypt/encrypt doesn't cost enough to be the = deal-breaker between "viable solution" and "not viable solution"; other = things weigh far more on capex/opex. >=20 > The architectural/non-cost argument I see against decrypt/encrypt is = "the gateway wants to be able to disclaim the ability to look at the = bits". >=20 > Agree with Tim about the relative difficulty of adding the needed = features. -d >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dwing@cisco.com Thu Jun 13 12:14:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFFC21F9248 for ; Thu, 13 Jun 2013 12:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CA-rHMVqxKK for ; Thu, 13 Jun 2013 12:14:34 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C3E4321F9AA4 for ; Thu, 13 Jun 2013 12:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=775; q=dns/txt; s=iport; t=1371150873; x=1372360473; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=2CuCVmNfzDfuJOj68wx9gVfuXgV2BsuoD+JZ6TthZDo=; b=lHo621KTLlxgQGBe13torWB3iIVNuYxVWxTCpmZTlUBnBZDYasAHdf9k Rc58rsvek1wxGIyx3rnkpxCLsZ0Ku43XVmdNMbzsu+un3IxeNUJcywCXU yzqjUUI3rVwThUwmQIEEq/UQVyPStnUmDT6AwJ6W+Wu+46SLOhLSjKhu9 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0FADYZulGrRDoG/2dsb2JhbABbgwkwgna8EIECFnSCIwEBAQMBAQEBNzQLEAsYLicwBhOICAUNu0sEjxAzB4J/YQOJII4hkUKDLxw X-IronPort-AV: E=Sophos;i="4.87,860,1363132800"; d="scan'208";a="80372637" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 13 Jun 2013 19:14:30 +0000 Received: from sjc-vpn2-277.cisco.com (sjc-vpn2-277.cisco.com [10.21.113.21]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5DJERr3011883; Thu, 13 Jun 2013 19:14:30 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Thu, 13 Jun 2013 12:14:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115C8A0F@MCHP04MSX.global-ad.net> <51B9C244.9050705@alvestrand.no> To: Tim Panton X-Mailer: Apple Mail (2.1508) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 19:14:39 -0000 On Jun 13, 2013, at 8:30 AM, Tim Panton wrote: >=20 > On 13 Jun 2013, at 13:59, Harald Alvestrand wrote: >=20 >>=20 >>=20 >> The architectural/non-cost argument I see against decrypt/encrypt is = "the gateway wants to be able to disclaim the ability to look at the = bits". >=20 > Which is implausible because it will probably have to have the DES = keys to be able to decode RTCP at least. RTCP is usually only authenticated (not encrypted), which is the = recommendation of RFC3711 (SRTP). -d >=20 > I'm not sure how much implausible deniability is worth these days. >=20 > T. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Thu Jun 13 12:47:49 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE5321F9AD3 for ; Thu, 13 Jun 2013 12:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogCKL8IUreSZ for ; Thu, 13 Jun 2013 12:47:44 -0700 (PDT) Received: from blu0-omc1-s16.blu0.hotmail.com (blu0-omc1-s16.blu0.hotmail.com [65.55.116.27]) by ietfa.amsl.com (Postfix) with ESMTP id DEA1D21F9ACB for ; Thu, 13 Jun 2013 12:47:43 -0700 (PDT) Received: from BLU169-W85 ([65.55.116.9]) by blu0-omc1-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jun 2013 12:47:43 -0700 X-TMN: [u3YstHEvH1U7PYwx00rLBPoohP2E1BE4] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_084b0e56-8720-4161-9d87-7ab282dd5e53_" From: Bernard Aboba To: Harald Alvestrand , "rtcweb@ietf.org" Date: Thu, 13 Jun 2013 12:47:42 -0700 Importance: Normal In-Reply-To: <51B9C244.9050705@alvestrand.no> References: , , , <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com>, , <9F33F40F6F2CD847824537F3C4E37DDF115C8A0F@MCHP04MSX.global-ad.net>, , <51B9C244.9050705@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jun 2013 19:47:43.0576 (UTC) FILETIME=[DEE7FD80:01CE686E] Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 19:47:49 -0000 --_084b0e56-8720-4161-9d87-7ab282dd5e53_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harald said:=20 > The architectural/non-cost argument I see against decrypt/encrypt is=20 > "the gateway wants to be able to disclaim the ability to look at the bits= ". [BA] There are only a limited number of situations where it is possible to = "disclaim the ability to look at the bits". For example=2C a PSTN gateway= =2C PBX connecting to a SIP trunk=2C a video compositor or an audio mixer n= eed to access decrypted RTP packets in order to do their job. What non-P2P= scenarios are you imagining where that would be possible?=20 =20 > My impression from the performance numbers people have quoted is that=20 > the CPU cost of decrypt/encrypt doesn't cost enough to be the=20 > deal-breaker between "viable solution" and "not viable solution"=3B other= =20 > things weigh far more on capex/opex. =20 [BA] I believe it is correct to say that the CPU cost of SRTP encrypt/decry= pt is not the bottleneck in large membership conferences (a good MCU imple= mentation running on a high-end multicore server is likely to saturate a 1 = Gbps NIC before CPU utilization becomes a factor). Given that=2C I don't s= ee that EKT will actually have that much impact=2C compared with other deci= sions about the key exchange - whether PFS is required=2C key establishmen= t algorithms and key sizes=2C etc. For example=2C see:=20 http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html =20 =20 = --_084b0e56-8720-4161-9d87-7ab282dd5e53_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Harald said:

    >=3B The = architectural/non-cost argument I see against decrypt/encrypt is
    >=3B= "the gateway wants to be able to disclaim the ability to look at the bits"= .

    [BA] There are only a limited number of =3Bsituations where it= is possible to "disclaim the ability to look at the bits". =3B For exa= mple=2C a PSTN gateway=2C PBX connecting to a SIP trunk=2C a video composit= or or an audio mixer need to access decrypted RTP packets in order to do th= eir job. =3B What non-P2P scenarios are you imagining where that would = be possible?
     =3B
    >=3B My impression from the performance numb= ers people have quoted is that
    >=3B the CPU cost of decrypt/encrypt d= oesn't cost enough to be the
    >=3B deal-breaker between "viable soluti= on" and "not viable solution"=3B other
    >=3B things weigh far more on = capex/opex.
     =3B
    [BA] I believe it is correct to say that the CPU= cost of SRTP encrypt/decrypt =3B is not the bottleneck in large member= ship conferences (a good MCU implementation running on a high-end multicore= server is likely to saturate a 1 Gbps NIC before CPU utilization becomes a= factor). =3B Given that=2C I don't see that EKT will actually have tha= t much impact=2C compared with other decisions about the key exchange -&nbs= p=3B whether PFS is required=2C key establishment algorithms and key sizes= =2C etc. =3B For example=2C see:
    http://nmav.gnutls.org/2011/= 12/price-to-pay-for-perfect-forward.html
     =3B
     =3B
    =
    = --_084b0e56-8720-4161-9d87-7ab282dd5e53_-- From hadriel.kaplan@oracle.com Thu Jun 13 20:39:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C930521F8F6E for ; Thu, 13 Jun 2013 20:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ll9y6Me35Yb for ; Thu, 13 Jun 2013 20:39:47 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 439ED21F9133 for ; Thu, 13 Jun 2013 20:39:47 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5E3dgrc006626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Jun 2013 03:39:42 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5E3de3Q014805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Jun 2013 03:39:41 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5E3deJ5024952; Fri, 14 Jun 2013 03:39:40 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-145-49.vpn.oracle.com (/10.154.145.49) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Jun 2013 20:39:40 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51B9C244.9050705@alvestrand.no> Date: Thu, 13 Jun 2013 23:39:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <18A33FE7-21D5-4944-BB09-16FB645D8C16@oracle.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115C8A0F@MCHP04MSX.global-ad.net> <51B9C244.9050705@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 03:39:53 -0000 On Jun 13, 2013, at 8:59 AM, Harald Alvestrand = wrote: > My impression from Paris was that if the WebRTC world supports EKT, = then gatewaying into an SDES realm requires some fancy key-shuffling, = nothing more. My impression from the discussion there was: "we have this new shiny toy = no one's ever deployed so why don't we use you as the guinea pig". In = fact if I recall correctly it was you who said something along those = lines in Paris. :) > If the WebRTC world does not support EKT, then decrypt/encrypt will = work in all cases. Yup. > My impression from the performance numbers people have quoted is that = the CPU cost of decrypt/encrypt doesn't cost enough to be the = deal-breaker between "viable solution" and "not viable solution"; other = things weigh far more on capex/opex. Yes, I also think that's true, that the cost/complexity overhead of = decrypt/encrypt wouldn't break the viability. It does cost more to do = it, though, so if we can get away without having to do it (without truly = sacrificing security) then it would be a good thing. Things add up = after all, both in processing cost and time. But yes clearly it isn't as big a deal as having to transcode video, for = example, which would not be viable. > The architectural/non-cost argument I see against decrypt/encrypt is = "the gateway wants to be able to disclaim the ability to look at the = bits". I hadn't heard that one. I'm not really sure how one could prove that = anyway though, since SDES would certainly give the gateway the *ability* = to look at the bits. You would have to either check the code or believe = the logs, and if you're willing to believe them then you might as well = believe the code/logs that the gateway isn't storing/sampling the bits = when it decrypts/encrypts. > Agree with Tim about the relative difficulty of adding the needed = features. Afaict, adding SDES is trivial if you went to the trouble of doing = DTLS-SRTP already. The converse isn't true. -hadriel From martin.thomson@gmail.com Thu Jun 13 21:50:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5432F21F9AF8 for ; Thu, 13 Jun 2013 21:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niTFfvNl2Bda for ; Thu, 13 Jun 2013 21:50:53 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 860AD21F9AE5 for ; Thu, 13 Jun 2013 21:50:53 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so89589wev.0 for ; Thu, 13 Jun 2013 21:50:52 -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=xHpH7QJgjY0m5BjuUEhfi9gud7SVSlR9aG+d5fFDLmo=; b=XN5Q9yr3xToYj69pXCb1P1b0/v5Dhi4oVkpoOpQvF/jZrydazV4yAfYyPXs2i/VzwX tl6AbkCXw4dLGe2bOBU5CsEmFeOIPe9kEsvchDx7Z1CJJb6RxJi+oSGQBwtCam1HTgKC PJONI+cqXlZGfDYGYSNnWO96Q5wj4QAZ3b6wiqPfakZW/xsFF86fVNc3nfhWCR1xjBj8 i1dIXwGMpaNZ27hjTJqgBRcBrVA37qbGKfOyYro/DUMuOGI9s9uKg4bMeInGFpjnUV2i 2B8nUHp7oW0YDJ8tgulOI9VqTnlZLIMrY+/VnGLln1XAblLMJBiVm3ShNoFiOGXl0Qh9 6A2Q== MIME-Version: 1.0 X-Received: by 10.194.158.194 with SMTP id ww2mr342069wjb.3.1371185452652; Thu, 13 Jun 2013 21:50:52 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 13 Jun 2013 21:50:52 -0700 (PDT) In-Reply-To: <18A33FE7-21D5-4944-BB09-16FB645D8C16@oracle.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115C8A0F@MCHP04MSX.global-ad.net> <51B9C244.9050705@alvestrand.no> <18A33FE7-21D5-4944-BB09-16FB645D8C16@oracle.com> Date: Thu, 13 Jun 2013 21:50:52 -0700 Message-ID: From: Martin Thomson To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 04:50:54 -0000 On 13 June 2013 20:39, Hadriel Kaplan wrote: >> My impression from Paris was that if the WebRTC world supports EKT, then gatewaying into an SDES realm requires some fancy key-shuffling, nothing more. > > My impression from the discussion there was: "we have this new shiny toy no one's ever deployed so why don't we use you as the guinea pig". In fact if I recall correctly it was you who said something along those lines in Paris. :) Likewise. I also wonder what the API surface for this feature needs to look like. Clearly, someone needs to decide to push new keys into the session, but can that be the application: is this something that would have an API in the browser? (That's a serious question, BTW. Comment 22 provided that interface, because we wanted to support SDES and the same interface conveniently applies to EKT, but that leads to some interesting issues with respect to media security.) As I see this issue, it's a not a matter of "do we need SDES in addition to DTLS-SRTP", it's more a matter of "how do we solve the my-MCU-is-on-fire problem", for which there are two proposals on the table: SDES and EKT. The latter has some issues with respect to deployment, even if it has some merits from a security perspective. There are other reasons that SDES is preferable to us, though those might not be compelling to others, but I can't get over this central issue. From prvs=98771d30af=magnus.westerlund@ericsson.com Fri Jun 14 00:43:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F08F21F9C0C for ; Fri, 14 Jun 2013 00:43:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6K0Ewcd35VR for ; Fri, 14 Jun 2013 00:43:17 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0B12921F9C29 for ; Fri, 14 Jun 2013 00:43:16 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-ae-51bac993114c Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 26.0B.15700.399CAB15; Fri, 14 Jun 2013 09:43:15 +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; Fri, 14 Jun 2013 09:43:15 +0200 Message-ID: <51BAC9BC.6070708@ericsson.com> Date: Fri, 14 Jun 2013 09:43:56 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> In-Reply-To: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+Jvre7kk7sCDT5+NbT4tOkTs8Xaf+3s DkweS5b8ZPL4+PQWSwBTFLdNUmJJWXBmep6+XQJ3RuvKJraCHsGKk61N7A2M93i7GDk4JARM JKYvSexi5AQyxSQu3FvP1sXIxSEkcIpR4sy1qewQznJGiXO317GBVPEKaEvM3L6KBcRmEVCV eLZ2DTOIzSZgIXHzRyNYjahAsMSR7ZtZIOoFJU7OfMICskxEQE/i6D1OkDCzgLDEhottYCXC ApYSPd1vwMYICfwEWryMD8TmFLCTaPw4jxniOEmJLS/a2SF69SSmXG1hhLDlJZq3zobq1ZZo aOpgncAoNAvJ5llIWmYhaVnAyLyKkT03MTMnvdxwEyMwVA9u+a27g/HUOZFDjNIcLErivJZL dwYKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4AQRXFINjA0feRcYHvmaXNgroniuakfUlLz0Quam zm9LvfsX3Tay31T6XKmz7rl81P0utnducszaztH2uiqmh3yX3ddqvuwwXV2iyvXz7quyuvLT 3BktDaRSi/+EfM0K2pp2sefyjRAdQSEVyxDZ/LP7xRSfnNaKvhR4msftQrHWrl//dyok/eDf LrVBiaU4I9FQi7moOBEAyd3hlSgCAAA= Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 07:43:24 -0000 On 2013-06-12 18:29, Hadriel Kaplan wrote: > > What we had talked about back in IETF 83 (or some previous meeting) was > whether DTLS-SRTP would be the only MTI key exchange, or whether SDES > would also be MTI. > We did not come to consensus in IETF 83, and tabled it for more > discussion. Since then it has been put at the end of the agendas, > resulting in us running out of time for it. At the last IETF 86 or > Boston interim, one of the WG Chairs (I don't remember who) said we'd > have a virtual interim dedicated to cover it. Now we don't. Ergo, we > don't have a plan. It was me that said we where going to schedule an interim meeting. Which we chairs failed to to in the previous cycles between meetings which was our bad. However, this time we have proposed a time and requested people to submit agenda items to that meeting. Don't hold us WG chairs responsible because you in the WG aren't providing input into what should be discussed. I see an tendency on the mailing list to shout "Security Descriptions is important!". But, when we ask for people willing to provide a proposal for how to integrate it, or even provide input into a discussion that could reach a WG conclusion that Security Description or some other additional keying than DTLS-SRTP is desired people goes silent. Without proposals we chairs where not seeing reasons to hold this interim meeting. If you want to discuss this, write a draft describing how how your additional keying is to be integrated, what the pro and cons of it. That will enable direct discussion of a proposal. The WG clearly are opinionated on this matter, but apparently don't have energy to produce proposals. 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 ---------------------------------------------------------------------- From prvs=187771783b=christer.holmberg@ericsson.com Fri Jun 14 00:54:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C537B21F9C49 for ; Fri, 14 Jun 2013 00:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.737 X-Spam-Level: X-Spam-Status: No, score=-5.737 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oukilfKfUqwX for ; Fri, 14 Jun 2013 00:53:58 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB3121F9C46 for ; Fri, 14 Jun 2013 00:53:54 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-37-51bacc0ddda7 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 26.CB.09795.D0CCAB15; Fri, 14 Jun 2013 09:53:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Fri, 14 Jun 2013 09:53:49 +0200 From: Christer Holmberg To: Magnus Westerlund , Hadriel Kaplan Thread-Topic: [rtcweb] No Interim on SDES at this juncture Thread-Index: AQHOZrwhuAjKD2BFwkKUQ/PJIpp3+ZkxOSqAgADdvYCAAA4GAIACkewAgAAiY7A= Date: Fri, 14 Jun 2013 07:53:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C38A856@ESESSMB209.ericsson.se> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> In-Reply-To: <51BAC9BC.6070708@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+JvrS7vmV2BBj8/W1t82vSJ2WLtv3Z2 ByaPJUt+Mnl8fHqLJYApitsmKbGkLDgzPU/fLoE7Y+Oms4wFk8UrHi/Ia2C8JtTFyMkhIWAi cbdhDROELSZx4d56ti5GLg4hgcOMEueefGOCcJYwSkw6uZy1i5GDg03AQqL7nzZIg4hAisSS i5/AmpkF1CXuLD7HDmILC1hKHH+wnwmixkpi1tXvjBC2n8SuaS3MIGNYBFQlfr4BC/MK+Eos nj+HHWLVQiaJNTtegs3hFNCRuNrfzQZiMwId9/3UGqhd4hK3nsyHOlpAYsme88wQtqjEy8f/ wM6UEFCUWN4vB1GuJ3Fj6hQ2CFtbYtnC18wQewUlTs58wjKBUWwWkqmzkLTMQtIyC0nLAkaW VYzsuYmZOenl5psYgRFycMtvgx2Mm+6LHWKU5mBREuf9dGpXoJBAemJJanZqakFqUXxRaU5q 8SFGJg5OEMEl1cAY7/hg9Zx1lUU7vPfsf3Ms6xGvxcbdM95mdtlEFmvqy6nf+igfE8sVVL34 /q9XBiJOlg+eFs2rd2JOUF2tmriha3vioXOcbiFv5zUxa+3N33hs9e+0opz1LkxWlZo3/jar lOxkYuKaXCdU/4zP93rl26szJuTX1y9TW/2eOT44af6F+1p3/L2VWIozEg21mIuKEwFb7lTe YwIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 07:54:11 -0000 Hi, I agree with what Magnus says. Also, in general, in order to get most out of meetings (virtual or physical= ), it is good to have mail discussions. I don't even remember the last time= I saw an e-mail on this topic (until it was announced that the meeting won= 't be held, that is). Regards, Christer -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Magnus Westerlund Sent: 14. kes=E4kuuta 2013 10:44 To: Hadriel Kaplan Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture On 2013-06-12 18:29, Hadriel Kaplan wrote: >=20 > What we had talked about back in IETF 83 (or some previous meeting)=20 > was whether DTLS-SRTP would be the only MTI key exchange, or whether=20 > SDES would also be MTI. > We did not come to consensus in IETF 83, and tabled it for more=20 > discussion. Since then it has been put at the end of the agendas,=20 > resulting in us running out of time for it. At the last IETF 86 or=20 > Boston interim, one of the WG Chairs (I don't remember who) said we'd=20 > have a virtual interim dedicated to cover it. Now we don't. Ergo, we=20 > don't have a plan. It was me that said we where going to schedule an interim meeting. Which we= chairs failed to to in the previous cycles between meetings which was our = bad. However, this time we have proposed a time and requested people to submit a= genda items to that meeting. Don't hold us WG chairs responsible because yo= u in the WG aren't providing input into what should be discussed. I see an tendency on the mailing list to shout "Security Descriptions is im= portant!". But, when we ask for people willing to provide a proposal for ho= w to integrate it, or even provide input into a discussion that could reach= a WG conclusion that Security Description or some other additional keying = than DTLS-SRTP is desired people goes silent. Without proposals we chairs where not seeing reasons to hold this interim m= eeting. If you want to discuss this, write a draft describing how how your addition= al keying is to be integrated, what the pro and cons of it. That will enabl= e direct discussion of a proposal. The WG clearly are opinionated on this m= atter, but apparently don't have energy to produce proposals. 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 tim@phonefromhere.com Fri Jun 14 02:01:23 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE45921F9B4A for ; Fri, 14 Jun 2013 02:01:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtUYFtQ8CFU4 for ; Fri, 14 Jun 2013 02:01:17 -0700 (PDT) Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by ietfa.amsl.com (Postfix) with ESMTP id D522221F9B42 for ; Fri, 14 Jun 2013 02:01:00 -0700 (PDT) Received: (qmail 92367 invoked from network); 14 Jun 2013 09:00:59 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp003.apm-internet.net with SMTP; 14 Jun 2013 09:00:59 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 54A8318A0454; Fri, 14 Jun 2013 10:00:58 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 379A518A03FD; Fri, 14 Jun 2013 10:00:58 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <18A33FE7-21D5-4944-BB09-16FB645D8C16@oracle.com> Date: Fri, 14 Jun 2013 10:00:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0995BCD1-7A5C-4580-9570-43F0573CDE24@phonefromhere.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115C8A0F@MCHP04MSX.global-ad.net> <51B9C244.9050705@alvestrand.no> <18A33FE7-21D5-4944-BB09-16FB645D8C16@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1283) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 09:01:24 -0000 On 14 Jun 2013, at 04:39, Hadriel Kaplan wrote: >=20 > On Jun 13, 2013, at 8:59 AM, Harald Alvestrand = wrote: >=20 >> Agree with Tim about the relative difficulty of adding the needed = features. >=20 > Afaict, adding SDES is trivial if you went to the trouble of doing = DTLS-SRTP already. The converse isn't true. If you add SDES to an existing DTLS-SRTP the key and crypto stuff is = (relatively) trivial -=20 but you are adding additional valid options and paths to the SDP - making it even harder to validate and parsers even more entangled than = before. You can see that 2 ways: 1) "SDP is always going to be a loosely defined option ridden = pain to parse, thats what SIPit is for - to knock out the bugs" 2) "SDP is a mess, we should be doing everything possible to = simplify the subset we require in rtcWEB" - I'm mostly in camp 2. Having spent more time on getting the SDP right = than I did on the DTLS itself. T.= From ibc@aliax.net Fri Jun 14 04:54:17 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C2121F9C67 for ; Fri, 14 Jun 2013 04:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBmHBwWoQl04 for ; Fri, 14 Jun 2013 04:54:17 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 824C221F9C70 for ; Fri, 14 Jun 2013 04:54:16 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so580602pab.27 for ; Fri, 14 Jun 2013 04:54:16 -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=EFeUzqykwFJ2rUBbJLADRarO6JOSC/kw4UdiKlay6+I=; b=CnN/0DP59A+IJd2beCwtDG0RSuq8KxrDAqfyU5XEktOfj6tWnr9yJCqgSNyunMxJeo g/+EI96FoFCveBaoF02J+Vx8oTzUmehxzAgE7SSFwwU3+Hlc7GGHKznK6fGkKfV3yDlx wipCdQrMoeOqESkdxS7PyR4p61RMkkRVlD/62iE2Hr8W3sC4zPf7re4tGoLI8WqdSZcQ ZA+XQvaUs3+4gl8VpPPHGhEARpeNtiLxpM16/5guToCgGtBDNQkOAaHWSK/EPXH+PZLm eEU3J9RoGZhJny8a/sY7RZil3IpOtMs4s6nBzZ131Eq2ClLaMBp6hJQBQj+rNtAozgj4 oUcg== X-Received: by 10.66.82.162 with SMTP id j2mr2223417pay.168.1371210856219; Fri, 14 Jun 2013 04:54:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.78.5 with HTTP; Fri, 14 Jun 2013 04:53:56 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 14 Jun 2013 13:53:56 +0200 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmwh6YBsiUgMcSmNOY8F3pjUl/uvOp7YfEvJZWPB3Hz7SNEEfRJkNcFj2NobZsj9eIn5U+f Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Why is required to have local streams before running ICE gathering? (another SDP limitation?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 11:54:17 -0000 2013/6/13 Eric Rescorla : >> 1. There is agreement that there should be a mechanism to pre-specify >> the size of a candidate pool to gather, though I just glanced in the spe= c >> and I didn't see it. (May have missed it though). > > > I see that there still is some (not quite up to date) text here: > > Create an ICE Agent as defined in [ICE] and let connection's > RTCPeerConnection ICE Agent be that ICE Agent and provide it the STUN and > TURN servers from the configuration array. The ICE Agent will proceed wit= h > gathering as soon as the IceTransports constraint is not set to "none". A= t > this point the ICE Agent does not know how many ICE components it needs (= and > hence the number of candidates to gather), but it can make a reasonable > assumption such as 2. As the RTCPeerConnection object gets more informati= on, > the ICE Agent can adjust the number of components. Hi Eric, thanks a lot for the information you provide. Is it feasible with the current API to ask for N ICE candidates prior to having the local SDP set as local descriptor in the PeerConnection? -- I=C3=B1aki Baz Castillo From ekr@rtfm.com Fri Jun 14 07:00:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B536121F9ABB for ; Fri, 14 Jun 2013 07:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.805 X-Spam-Level: X-Spam-Status: No, score=-99.805 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8D40ZcZngoY for ; Fri, 14 Jun 2013 07:00:05 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8727321F9702 for ; Fri, 14 Jun 2013 07:00:04 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id n1so302031qcx.8 for ; Fri, 14 Jun 2013 07:00:04 -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=Wt3Z8TPQkW2Sa5rpOIeJ3BwobSSUTGDLMiEF2B6FI5w=; b=W50gyazvsW83pYN7Xzx7HXXZC2Smulg2R8bOJLgSsON77f7QdTp14apCGCS3/C8UQI USqflW5gxL51GxBkOe2W5J7GbF1x00WQo+BuJ36+vnEZYxMxXl6xGeYMWK5GsZtKWkj3 mffDJh+EyjdSZ6+UMMxcbINNoowmzRfWGoo4+8uPohgiKTgyDIUpqktEFuzMX6Kq2aNh w+yEAbQayPV7/RhYjPvzSs6SHEOL2562msdyFi4nIIvCD3Lm/20HCMEvOLMnJF010D8j hmqQWWKri86P8LtYnOM9hS6JOjl6RogC6JNNYDseSdLCSIBMFjDPzzZaRRc2WjvWQxHN 9NFg== X-Received: by 10.49.41.6 with SMTP id b6mr2764229qel.13.1371218404027; Fri, 14 Jun 2013 07:00:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.0.163 with HTTP; Fri, 14 Jun 2013 06:59:22 -0700 (PDT) X-Originating-IP: [74.95.2.170] In-Reply-To: References: From: Eric Rescorla Date: Fri, 14 Jun 2013 06:59:22 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7bea42d4e1c3d204df1da9ba X-Gm-Message-State: ALoCoQn/IE6I77aVj44y2LuUmtomlJUnvTwamzx7wQXHcyfkzJg4pVY6KTH8585IH2jyhcOUy1wc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Why is required to have local streams before running ICE gathering? (another SDP limitation?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 14:00:10 -0000 --047d7bea42d4e1c3d204df1da9ba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jun 14, 2013 at 4:53 AM, I=F1aki Baz Castillo wrote= : > 2013/6/13 Eric Rescorla : > >> 1. There is agreement that there should be a mechanism to pre-specify > >> the size of a candidate pool to gather, though I just glanced in the > spec > >> and I didn't see it. (May have missed it though). > > > > > > I see that there still is some (not quite up to date) text here: > > > > Create an ICE Agent as defined in [ICE] and let connection's > > RTCPeerConnection ICE Agent be that ICE Agent and provide it the STUN a= nd > > TURN servers from the configuration array. The ICE Agent will proceed > with > > gathering as soon as the IceTransports constraint is not set to "none". > At > > this point the ICE Agent does not know how many ICE components it needs > (and > > hence the number of candidates to gather), but it can make a reasonable > > assumption such as 2. As the RTCPeerConnection object gets more > information, > > the ICE Agent can adjust the number of components. > > > Hi Eric, thanks a lot for the information you provide. > > Is it feasible with the current API to ask for N ICE candidates prior > to having the local SDP set as local descriptor in the PeerConnection? > > That has been discussed (and I thought agreed upon) but I don't see it in the spec. -Ekr --047d7bea42d4e1c3d204df1da9ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Fri, Jun 14, 2013 at 4:53 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
    2013/6/13 Eric Rescorla <ekr@rtfm.com>:
    >> 1. There is agreement that there should be a mec= hanism to pre-specify
    >> the size of a candidate pool to gather, though I just glanced in t= he spec
    >> and I didn't see it. (May have missed it though).
    >
    >
    > I see that there still is some (not quite up to date) text here:
    >
    > Create an ICE Agent as defined in [ICE] and let connection's
    > RTCPeerConnection ICE Agent be that ICE Agent and provide it the STUN = and
    > TURN servers from the configuration array. The ICE Agent will proceed = with
    > gathering as soon as the IceTransports constraint is not set to "= none". At
    > this point the ICE Agent does not know how many ICE components it need= s (and
    > hence the number of candidates to gather), but it can make a reasonabl= e
    > assumption such as 2. As the RTCPeerConnection object gets more inform= ation,
    > the ICE Agent can adjust the number of components.


    Hi Eric, thanks a lot for the information you provide.

    Is it feasible with the current API to ask for N ICE candidates prior
    to having the local SDP set as local descriptor in the PeerConnection?

    <= br>
    That has been discussed (and I thought agreed upon) but= I don't see
    it in the spec.

    -Ekr

    --047d7bea42d4e1c3d204df1da9ba-- From hadriel.kaplan@oracle.com Fri Jun 14 09:17:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DC721F9CEA for ; Fri, 14 Jun 2013 09:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBQq9FKXWvdz for ; Fri, 14 Jun 2013 09:17:23 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4262C21F9A87 for ; Fri, 14 Jun 2013 09:17:23 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5EGHHOI015591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Jun 2013 16:17:17 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5EGHJw7021050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Jun 2013 16:17:19 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5EGHI0d021033; Fri, 14 Jun 2013 16:17:18 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Jun 2013 09:17:18 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C38A856@ESESSMB209.ericsson.se> Date: Fri, 14 Jun 2013 12:17:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1C38A856@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 16:17:28 -0000 On Jun 14, 2013, at 3:53 AM, Christer Holmberg = wrote: > Also, in general, in order to get most out of meetings (virtual or = physical), it is good to have mail discussions. I don't even remember = the last time I saw an e-mail on this topic (until it was announced that = the meeting won't be held, that is). Doing a very rough search on my email client, the last time SDES was = discussed was waaaaay back on May 10th, in this email: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07460.html Who can even remember what the Internet was like back then? But more seriously, we had a LOT of emails about the topic last year. = There was agreement to discuss it in a meeting instead, because the = discussion was too difficult for people to follow in email. So why = would people keep discussing it in email? -hadriel From hadriel.kaplan@oracle.com Fri Jun 14 09:59:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA95021F9CED for ; Fri, 14 Jun 2013 09:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ssFEgnpL3-3 for ; Fri, 14 Jun 2013 09:59:05 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 57DFB21F9CDD for ; Fri, 14 Jun 2013 09:59:05 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5EGwsWI028922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Jun 2013 16:58:55 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5EGwttU027619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Jun 2013 16:58:56 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5EGwttt006188; Fri, 14 Jun 2013 16:58:55 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Jun 2013 09:58:55 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51BAC9BC.6070708@ericsson.com> Date: Fri, 14 Jun 2013 12:58:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 16:59:11 -0000 On Jun 14, 2013, at 3:43 AM, Magnus Westerlund = wrote: > However, this time we have proposed a time and requested people to > submit agenda items to that meeting. Don't hold us WG chairs = responsible > because you in the WG aren't providing input into what should be = discussed. You can't be serious. There was exactly ONE email asking for agenda items, here: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html It was sent on May 30th. It gave a generous 6 days to respond. Luckily = no one ever goes on vacation for longer than 5 days. Instead, two people sent a response on June 10th, a tremendous 11 days = after the request. Outrageous! That's a almost twice as long as they = were given! Thank goodness the chairs detected this monstrous breach of procedure, = and thwarted the attempts of anarchy! I mean if people are allowed to = respond to emails so tardily, how can we be expected to get things = accomplished as quickly as they've so far been in this WG?!? Sure, an interim for this topic has been waiting for many months if not = a whole year, and now that people didn't respond in 6 days but took = instead 11 days the topic will be delayed indefinitely yet again... but = that's no excuse for blatantly flaunting the rules! Personally I saw the email on May 30th, and assumed Oscar and Dan would = respond to you for agenda time. I assumed that if no one had submitted = agenda items to you, that the WG Chairs would send out an email warning = about that, or perhaps even directly email the people who they expected = to submit agenda items. > If you want to discuss this, write a draft describing how how your > additional keying is to be integrated, what the pro and cons of it. = That > will enable direct discussion of a proposal. The WG clearly are > opinionated on this matter, but apparently don't have energy to = produce > proposals. There *are* drafts. http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00 http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 There are even powerpoint slides, sent to the chairs the last time this = meeting almost happened but didn't. I think the problem must be that those things weren't signed in = triplicate, sent in, sent back, queried, lost, found, subjected to = public enquiry, lost again, and finally buried in soft peat for three = months and recycled as firelighters.=20 -hadriel From ibc@aliax.net Fri Jun 14 10:17:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6980D21F9B42 for ; Fri, 14 Jun 2013 10:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq3wxIxLg620 for ; Fri, 14 Jun 2013 10:17:03 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0D421F9AF7 for ; Fri, 14 Jun 2013 10:17:03 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c11so435315qcv.23 for ; Fri, 14 Jun 2013 10:16:59 -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=BGGWqOUuk7J9jDnQnUgUWXQciMyWDD4hMAbnl080ei4=; b=Dstwxs/Gf77Ryc6ElOemRTAJU7USYT+bsrxkgA6/z/YkljhCapQc2m2FLeju08QAKv q2+tYXJYF2XLADNG7W+XrjPWYtieuGfO/+yzBjjmfwnpAgf7PKfQgdVMe5XIMhdswC1J YFcR6wdLl1/z9y7Dh3/GXCEoENDq+aNis0GvlxKKXF61VlaVpN/VO+4QqMuLtl60XYZF ioqeajN9BfyMNBUjyhYC+qgsKTIoQuKRI0YkNs9FZsB0Z35abtUWNDyS9Oa5HL7hMn8u qEzM44RHOIzmiHzVKzf/G35RklD06lVa0UyTmML+rYMf14VtusLDHeWC2QTpJ5jpriK+ /dPw== MIME-Version: 1.0 X-Received: by 10.229.147.71 with SMTP id k7mr1237795qcv.129.1371230219285; Fri, 14 Jun 2013 10:16:59 -0700 (PDT) Received: by 10.49.67.65 with HTTP; Fri, 14 Jun 2013 10:16:59 -0700 (PDT) Received: by 10.49.67.65 with HTTP; Fri, 14 Jun 2013 10:16:59 -0700 (PDT) In-Reply-To: <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> Date: Fri, 14 Jun 2013 19:16:59 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=14dae94ed80520611204df206a77 X-Gm-Message-State: ALoCoQk+b8+OsJYxD3EQb0wGSbtrr1CIzU2Ao583gFOFxHERjob/wSZFvrsr0HBENNngCwxnFXro Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 17:17:04 -0000 --14dae94ed80520611204df206a77 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I just remember that somebody wrote a draft explaining why DTLS offers NO more security than SDES. AFAIR the draft was just ignored. I'm also surprised that there is no need to discuss this subject. -- I=C3=B1aki Baz Castillo El 14/06/2013 18:59, "Hadriel Kaplan" escribi= =C3=B3: > > On Jun 14, 2013, at 3:43 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > > > However, this time we have proposed a time and requested people to > > submit agenda items to that meeting. Don't hold us WG chairs responsibl= e > > because you in the WG aren't providing input into what should be > discussed. > > You can't be serious. > There was exactly ONE email asking for agenda items, here: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html > It was sent on May 30th. It gave a generous 6 days to respond. Luckily > no one ever goes on vacation for longer than 5 days. > Instead, two people sent a response on June 10th, a tremendous 11 days > after the request. Outrageous! That's a almost twice as long as they we= re > given! > > Thank goodness the chairs detected this monstrous breach of procedure, an= d > thwarted the attempts of anarchy! I mean if people are allowed to respon= d > to emails so tardily, how can we be expected to get things accomplished a= s > quickly as they've so far been in this WG?!? > > Sure, an interim for this topic has been waiting for many months if not a > whole year, and now that people didn't respond in 6 days but took instead > 11 days the topic will be delayed indefinitely yet again... but that's no > excuse for blatantly flaunting the rules! > > Personally I saw the email on May 30th, and assumed Oscar and Dan would > respond to you for agenda time. I assumed that if no one had submitted > agenda items to you, that the WG Chairs would send out an email warning > about that, or perhaps even directly email the people who they expected t= o > submit agenda items. > > > > If you want to discuss this, write a draft describing how how your > > additional keying is to be integrated, what the pro and cons of it. Tha= t > > will enable direct discussion of a proposal. The WG clearly are > > opinionated on this matter, but apparently don't have energy to produce > > proposals. > > There *are* drafts. > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00 > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 > There are even powerpoint slides, sent to the chairs the last time this > meeting almost happened but didn't. > > I think the problem must be that those things weren't signed in > triplicate, sent in, sent back, queried, lost, found, subjected to public > enquiry, lost again, and finally buried in soft peat for three months and > recycled as firelighters. > > -hadriel > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --14dae94ed80520611204df206a77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    I just remember that somebody wrote a draft explaining why D= TLS offers NO more security than SDES. AFAIR the draft was just ignored. I&= #39;m also surprised that there is no need to discuss this subject.

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

    El 14/06/2013 18:59, "Hadriel Kaplan" = <hadriel.kaplan@oracle.com<= /a>> escribi=C3=B3:

    On Jun 14, 2013, at 3:43 AM, Magnus Westerlund <    magnus.westerlund@ericsson.com> wrote:

    > However, this time we have proposed a time and requested people to
    > submit agenda items to that meeting. Don't hold us WG chairs respo= nsible
    > because you in the WG aren't providing input into what should be d= iscussed.

    You can't be serious.
    There was exactly ONE email asking for agenda items, here:
    http://www.ietf.org/mail-archive/web/rtcweb/current/ms= g07668.html
    It was sent on May 30th. =C2=A0It gave a generous 6 days to respond. =C2=A0= Luckily no one ever goes on vacation for longer than 5 days.
    Instead, two people sent a response on June 10th, a tremendous 11 days afte= r the request. =C2=A0Outrageous! =C2=A0That's a almost twice as long as= they were given!

    Thank goodness the chairs detected this monstrous breach of procedure, and = thwarted the attempts of anarchy! =C2=A0I mean if people are allowed to res= pond to emails so tardily, how can we be expected to get things accomplishe= d as quickly as they've so far been in this WG?!?

    Sure, an interim for this topic has been waiting for many months if not a w= hole year, and now that people didn't respond in 6 days but took instea= d 11 days the topic will be delayed indefinitely yet again... but that'= s no excuse for blatantly flaunting the rules!

    Personally I saw the email on May 30th, and assumed Oscar and Dan would res= pond to you for agenda time. =C2=A0I assumed that if no one had submitted a= genda items to you, that the WG Chairs would send out an email warning abou= t that, or perhaps even directly email the people who they expected to subm= it agenda items.


    > If you want to discuss this, write a draft describing how how your
    > additional keying is to be integrated, what the pro and cons of it. Th= at
    > will enable direct discussion of a proposal. The WG clearly are
    > opinionated on this matter, but apparently don't have energy to pr= oduce
    > proposals.

    There *are* drafts.
    http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems= -00
    http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-sup= port-01
    There are even powerpoint slides, sent to the chairs the last time this mee= ting almost happened but didn't.

    I think the problem must be that those things weren't signed in triplic= ate, sent in, sent back, queried, lost, found, subjected to public enquiry,= lost again, and finally buried in soft peat for three months and recycled = as firelighters.

    -hadriel

    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    = https://www.ietf.org/mailman/listinfo/rtcweb
    --14dae94ed80520611204df206a77-- From martin.thomson@gmail.com Fri Jun 14 10:21:23 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E7D21F9B6A for ; Fri, 14 Jun 2013 10:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACifJKzzjdrg for ; Fri, 14 Jun 2013 10:21:22 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 91FD321F9CBB for ; Fri, 14 Jun 2013 10:21:22 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id l18so727191wgh.2 for ; Fri, 14 Jun 2013 10:21: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:content-transfer-encoding; bh=JU7go6ILhtl9JRBS7EYDpoMKIOEmCthjmlh2fWsJGYo=; b=r0scXGTtQ6LAmxGoqPDoKhBM6xMCiKm2F6Y1Esix5o5rOV3fmllU4hSkqbA/EWKJKA pbMNzz7rbYj0Dg728JdjBbTWoxRazGln537j6geEQqCVP04JFPXTnnuwX0IWEWJQ00I+ ILUrmA/IAK6qPQedzy8XsWxBfeubQlm4TKXQVd5jg52a4VESgMap8p/NzXHHI8VVFh2W Hz7169mMli9KeprpF6qRJCxpEM0+MCMw9R2X5pv5qMRreKM1beI4sYGUFjPMSJCXfC+A xRqGWNyiULf/fRgwIrJguwYuqujxPHalOAxQsg3G94KVwnZDPr3syVMRzuXRUPUttfUX P7vQ== MIME-Version: 1.0 X-Received: by 10.180.20.46 with SMTP id k14mr1938170wie.14.1371230481756; Fri, 14 Jun 2013 10:21:21 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Fri, 14 Jun 2013 10:21:21 -0700 (PDT) In-Reply-To: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> Date: Fri, 14 Jun 2013 10:21:21 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 17:21:23 -0000 On 14 June 2013 10:16, I=C3=B1aki Baz Castillo wrote: > somebody wrote a draft explaining why DTLS offers NO more security than > SDES. AFAIR the draft was just ignored. If someone were to claim that the sky was green, ignoring the claim would be a reasonable response. From jim.barnett@genesyslab.com Fri Jun 14 10:46:36 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825A721F9D11 for ; Fri, 14 Jun 2013 10:46: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJNYbH6vk0xJ for ; Fri, 14 Jun 2013 10:46:31 -0700 (PDT) Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id 9E77821F9D06 for ; Fri, 14 Jun 2013 10:46:30 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.3 [168.75.250.3]) (Using TLS) by service107-us.mimecast.com; Fri, 14 Jun 2013 13:46:29 -0400 Received: from GENSJZMBX02.msg.int.genesyslab.com ([fe80::64cd:bb44:81d2:5bca]) by GENSJZFE01.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Fri, 14 Jun 2013 10:46:26 -0700 From: Jim Barnett To: Eric Rescorla Thread-Topic: [rtcweb] Why is required to have local streams before running ICE gathering? (another SDP limitation?) Thread-Index: AQHOaEYPQWFF9liWoEG7x+aoa8JPBZk0OBIAgAAAh4CAAVflAIAAIwwA///KGaE= Date: Fri, 14 Jun 2013 17:46:26 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-MC-Unique: 113061413462900401 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Why is required to have local streams before running ICE gathering? (another SDP limitation?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 17:46:36 -0000 You can call updateICE at any point. I also recall us agreeing to let you = specify the number of candidates, but it's not in the spec. If it gets adde= d to updateICE then you would be able to specify the number of candidates b= efore setLocal. On Jun 14, 2013, at 10:01 AM, "Eric Rescorla" > wrote: On Fri, Jun 14, 2013 at 4:53 AM, I=F1aki Baz Castillo > wrote: 2013/6/13 Eric Rescorla >: >> 1. There is agreement that there should be a mechanism to pre-specify >> the size of a candidate pool to gather, though I just glanced in the spe= c >> and I didn't see it. (May have missed it though). > > > I see that there still is some (not quite up to date) text here: > > Create an ICE Agent as defined in [ICE] and let connection's > RTCPeerConnection ICE Agent be that ICE Agent and provide it the STUN and > TURN servers from the configuration array. The ICE Agent will proceed wit= h > gathering as soon as the IceTransports constraint is not set to "none". A= t > this point the ICE Agent does not know how many ICE components it needs (= and > hence the number of candidates to gather), but it can make a reasonable > assumption such as 2. As the RTCPeerConnection object gets more informati= on, > the ICE Agent can adjust the number of components. Hi Eric, thanks a lot for the information you provide. Is it feasible with the current API to ask for N ICE candidates prior to having the local SDP set as local descriptor in the PeerConnection? That has been discussed (and I thought agreed upon) but I don't see it in the spec. -Ekr _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From prvs=0877423fe8=christer.holmberg@ericsson.com Fri Jun 14 13:12:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649BA21F9D3F for ; Fri, 14 Jun 2013 13:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEgpjG1KtAVT for ; Fri, 14 Jun 2013 13:12:52 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B2D0D21F9D3D for ; Fri, 14 Jun 2013 13:12:51 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-13-51bb79407468 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AC.1D.09795.0497BB15; Fri, 14 Jun 2013 22:12:48 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Fri, 14 Jun 2013 22:12:48 +0200 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [rtcweb] No Interim on SDES at this juncture Thread-Index: AQHOZrwhuAjKD2BFwkKUQ/PJIpp3+ZkxOSqAgADdvYCAAA4GAIACkewAgAAiY7CAAG0KAIAAYujQ Date: Fri, 14 Jun 2013 20:12:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C38AF3B@ESESSMB209.ericsson.se> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1C38A856@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvra5D5e5Ag7aHFhafNn1itlj7r53d gcljyZKfTB4fn95iCWCK4rZJSiwpC85Mz9O3S+DO2PDgJ2vBPbaKZ/N+szYwLmftYuTkkBAw kfjz+SYbhC0mceHeeiCbi0NI4DCjxP0z68CKhASWMEpM/lrcxcjBwSZgIdH9TxvEFBHQkzh6 jxOkglkgVuL89WMsILawgKXE6+lXmUBsEQEriVlXvzNC2FESZzoWsIC0sgioSvQsTAUJ8wr4 SuycfZQZYutMZonNxz6AzeEUsJM49vI42AWMQKd9P7WGCWKXuMSHg9eZIU4WkFiy5zyULSrx 8vE/qLeUJBqXPGGFqNeRWLD7ExuErS2xbOFrZojFghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUB I8sqRvbcxMyc9HLzTYzACDm45bfBDsZN98UOMUpzsCiJ8346tStQSCA9sSQ1OzW1ILUovqg0 J7X4ECMTByeI4JJqYIxV0F1rsvXwvp3fG7Y2n7i65fWE/WUTuR14H7/7ucl6zrSom3LXDq8J m7w0PPJKB+sUk/RZa//xnnzDzJHrV5pz9Frn05d8y2Js7krG7PR5mHT66wJBI1W2dHnfCTvD 7ls0/wpxXz/Xy973wbOqyL7Mky8n6PyvEV8f52LmvENJtKbjWr/KDUUlluKMREMt5qLiRAAT 9hTEYwIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 20:12:57 -0000 Hi, >> Also, in general, in order to get most out of meetings (virtual or physi= cal), it is good to have mail discussions. I don't even remember the last t= ime I saw an e-mail on this topic (until it was announced that the meeting = won't be held, that is). > > Doing a very rough search on my email client, the last time SDES was disc= ussed was waaaaay back on May 10th, in this email: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07460.html > Who can even remember what the Internet was like back then? > > But more seriously, we had a LOT of emails about the topic last year. Th= ere was agreement to discuss it in a meeting instead, because the discussio= n was too difficult for people to follow in email. So why would people kee= p discussing it in email? Because that's what we do in IETF :) Regards, Christer From prvs=4877fa3a36=christer.holmberg@ericsson.com Fri Jun 14 14:21:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8098221F9C50; Fri, 14 Jun 2013 14:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.573 X-Spam-Level: X-Spam-Status: No, score=-5.573 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKYmXk7Ziqhv; Fri, 14 Jun 2013 14:20:57 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BBD2421F9C54; Fri, 14 Jun 2013 14:20:55 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-92-51bb89364b8a Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 94.12.18006.6398BB15; Fri, 14 Jun 2013 23:20:54 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Fri, 14 Jun 2013 23:20:53 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" , "clue@ietf.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-04 Thread-Index: Ac5pRRAaBBf0WV1bTnCmSzcH/w765Q== Date: Fri, 14 Jun 2013 21:20:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C38B30C@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/mixed; boundary="_004_7594FB04B1934943A5C02806D1A2204B1C38B30CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGfG3Vtesc3egwcGrfBb7T11mtlj7r53d gcljyZKfTAGMUdw2SYklZcGZ6Xn6dgncGc1fW1gLpupXfN23iLGBcaJWFyMnh4SAicTtnivs ELaYxIV769m6GLk4hAQOM0q03trIDOEsYZS4OusoYxcjBwebgIVE9z9tkAYRAQ+JddvOMILY wgLhErNmrmaCiIdLLHt4iBHC1pN4Pu8bK4jNIqAqsaR1JguIzSvgK3G4oxNsMSPQ4u+n1oD1 MguIS3w4eJ0Z4iARiYcXT7NB2KISLx//Y4WwlSQalzxhhajPlNi9fQkzxExBiZMzn7BMYBSa hWTULCRls5CUQcTzJV6tmsAGYetJ3Jg6BcrWlli28DVUr67EjH+HWLCJHzl/jB3CVpRo294M 1MsFZK9glLjb18kKkbCWWLDpNAtM0ZTuh+wLGHlXMbLnJmbmpJcbbWIERuXBLb9VdzDeOSdy iFGag0VJnPfjqV2BQgLpiSWp2ampBalF8UWlOanFhxiZODhBBJdUA2OL0adbllFyC6VXTOb5 +fH+jtM7V7r7vPgZJnLdwWR3dtpO0dUaBqXKQq6rPSrXR6x63X1levnmHzdDt03TnVk8K9qr 5d4dSYGYp8pKvjKL9v92FfXYdCGf42mpheNHCZtLa/nvnY6yC7KtSWxYLRP7O7u1uomDS7rw fs0xP5EUvvN81upVXEosxRmJhlrMRcWJAJuLvZydAgAA Subject: [rtcweb] FWD: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 21:21:04 -0000 --_004_7594FB04B1934943A5C02806D1A2204B1C38B30CESESSMB209erics_ Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C38B30CESESSMB209erics_" --_000_7594FB04B1934943A5C02806D1A2204B1C38B30CESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI, Christer Ps. If you have comments on the draft, please present them on the MMUSIC li= st. L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] P= uolesta Christer Holmberg L=E4hetetty: 15. kes=E4kuuta 2013 0:19 Vastaanottaja: mmusic@ietf.org Aihe: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-= 04 Dear Bundle Fans, I've submitted a new version (-04) of BUNDLE. Compared with the previous version, there are some rather big editorial cha= nges, especially in the SDP Offer/Answer sections, mostly based on the mail= discussions. I have not touched the "ICE Usage" section at all. That is one of the next = things we need to deal with. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C38B30CESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    FYI,=

     

    Christer

     

    Ps. If = you have comments on the draft, please present them on the MMUSIC list.

    &n= bsp;

    L=E4hett=E4j= =E4: mmusic-bounces@ietf.org= [mailto:mmusic-bounces@ietf.org] Puolesta Christer Holmberg
    L=E4hetetty: 15. kes=E4kuuta 2013 0:19
    Vastaanottaja: mmusic@ietf.org
    Aihe: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negot= iation-04

     

    Dear Bundle Fans,

     

    I’ve submitted a new vers= ion (-04) of BUNDLE.

     

    Compared with the previous vers= ion, there are some rather big editorial changes, especially in the SDP Off= er/Answer sections, mostly based on the mail discussions.=

     

    I have not touched the “I= CE Usage” section at all. That is one of the next things we need to d= eal with.

     

    Regards,

     

    Christer

    --_000_7594FB04B1934943A5C02806D1A2204B1C38B30CESESSMB209erics_-- --_004_7594FB04B1934943A5C02806D1A2204B1C38B30CESESSMB209erics_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Fri, 14 Jun 2013 21:18:52 GMT"; modification-date="Fri, 14 Jun 2013 21:18:52 GMT" Content-ID: <5A5801A961235E42B1408D42B6472534@ericsson.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBt YWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWMNCg== --_004_7594FB04B1934943A5C02806D1A2204B1C38B30CESESSMB209erics_-- From juberti@google.com Sat Jun 15 16:40:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB8F21E804D for ; Sat, 15 Jun 2013 16:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leh5oSwj7Tkv for ; Sat, 15 Jun 2013 16:40:51 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B6FA021E804B for ; Sat, 15 Jun 2013 16:40:50 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so1312964wiv.2 for ; Sat, 15 Jun 2013 16:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=58oVXUIYAwsljkO80P5iz6OEKG2oZnM8PeToCBDIdP4=; b=nV39FDkXzEoioMt3nEc9+UFM0miYZhi+O/csLQOzjKOq2OdJpPY7NISiqgK6qJ+jOa OqeFXRpRpkigmAVjjaXR1mjmB/TH6/+6kMVEwD0+dwnQH8MLaTcLcF+V+N5di8vSRvR/ iqC78tj5sB2q3E+MUNJWsOcgGHuQMS+Dpluzv6HwzR8Nu+FWe6MjPfaJFHDrRc1ki04B 0yaNNL+xppoCYPON1d+rPxGONIbc/vBxAb01qJTvtCRTz54KpOOO0EvZQDsmmASxvrAr Q/munJXrMAV0ltcwiu1vKrqRZ411PmUeVyXYYe03vJ5ayyZUGSAGPBCCkmY1deg/yt6w i6GA== 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=58oVXUIYAwsljkO80P5iz6OEKG2oZnM8PeToCBDIdP4=; b=VyESgqmJe09vscTCyrABsDcZqJ6JChksU9CiMxZ24ZlqyjbX66q3t5ALjR4Gkz0dno QHvinyzyMLLq0VrX1xXPzkmo71qdy4xMsfk+hhZCQBftmdWPr06uCBiwiwmdjpmHo4WJ FyGc4JMERTKpGSq/BWCzTqrRrDuIBgvlnCk4i8Q5lUVze1YFj31Ur9DDTbk9slNDgijY KwozQe/DC98UiIoA0QXYYF2JhVKQcfrSLwQtAjWAJMV/0y5Ict13e1LKN2MQXpdUj2Ld qzZv4NK12eLXqss0a6skIZ/brxQfkdlMByWJrx+C5ppVDqWhskdKhU6eZvhHulUnIryv LfSw== X-Received: by 10.180.208.49 with SMTP id mb17mr1783942wic.46.1371339648680; Sat, 15 Jun 2013 16:40:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.19.72 with HTTP; Sat, 15 Jun 2013 16:40:28 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Sat, 15 Jun 2013 16:40:28 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11c37e30a0643104df39e420 X-Gm-Message-State: ALoCoQn/ChH2t9kPXdPfV8pM9MAohqmeDZqZ73+w/wvVSc8oZeC+53DBXXMrGs7/TBjDha15f2pUFQAQbS6dmAml4JIBWg0tfgjcc+hxX4EwgkKLZ9//ZJJg3MhWV2Kk8v4sf1sRghBD8yH9yd1G5VCDGMMMrZYJDHTcz41QIS6ZmbGB3wYCFdOJP4unXXi3K0KxOw7qzO8F Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Why is required to have local streams before running ICE gathering? (another SDP limitation?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Jun 2013 23:40:52 -0000 --001a11c37e30a0643104df39e420 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 13, 2013 at 7:55 AM, I=C3=B1aki Baz Castillo wr= ote: > Hi, let me expose the following simple case: > > > 1) SIP application in the web. > > 2) Alice receives INVITE from Bob with audio and video. > > 3) Alice JS UA is ringing, Alice does not answer or reject the call yet. > > 4) Alice JS UA does not know whether Alice would answer with audio and/or > video. > > 5) Alice JS UA starts ICE gathering and obtains all its ICE candidates. > > 6) Alice presses "Answer with audio and video". > > 7) Alice JS UA calls getUserMedia, creates the PC, gets the SDP and > passes it to Bob JS UA in a SIP 200 response. > > > Well, this is not possible in WebRTC due to step 5. Unfortunately > before ICE gathering, the local PC must be set with the local SDP, so > getUserMedia is required to happen before ICE gathering. > This should be possible today. You can set the local description with no MediaStreams but the constraint OfferToReceiveVideo:true to start candidate gathering for both audio and video. When you do eventually get the stream, you can call setLocalDescription again, to indicate whether video is to be used or not. > > But we cannot prompt Alice with the getUserMedia pop-up while she has > not yet decided to answer the incoming call. > > The fact is that both the audio and video will use the same UDP > channel/transport, so having ICE candidates for the audio and the > video m lines is just unneeded. > > So IMHO this is another issue due to the usage of SDP, right? or may > be I am wrong? If so please let me know a use case in which the > browser would mantain two different UDP channels/transports for the > same "call" (a single SDP O/A). > This happens in any non-BUNDLE scenario. > > This is just for "legacy interoperability", right? this is, for the > case in which the remote peer is a not-full-WebRTC device and uses > different UDP channels/transports for each m line in the SDP. If so, > would not be MUCH easier just to *require* as per WebRTC specs that > two peers MUST use a single UDP channel/transport for each SDP O/A? > > > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c37e30a0643104df39e420 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Thu, Jun 13, 2013 at 7:55 AM, I=C3=B1aki Baz Castillo <ibc@aliax.n= et> wrote:
    Hi, let me expose the following simple case:=


    1) SIP application in the web.

    2) Alice receives INVITE from Bob with audio and video.

    3) Alice JS UA is ringing, Alice does not answer or reject the call yet.
    4) Alice JS UA does not know whether Alice would answer with audio and/or v= ideo.

    5) Alice JS UA starts ICE gathering and obtains all its ICE candidates.

    6) Alice presses "Answer with audio and video".

    7) Alice JS UA calls getUserMedia, creates the PC, gets the SDP and
    passes it to Bob JS UA in a SIP 200 response.


    Well, this is not possible in WebRTC due to step 5. Unfortunately
    before ICE gathering, the local PC must be set with the local SDP, so
    getUserMedia is required to happen before ICE gathering.

    This should be possible today. You can set the local desc= ription with no MediaStreams but the constraint OfferToReceiveVideo:true to= start candidate gathering for both audio and video.

    When you do eventually get the stream, you can call set= LocalDescription again, to indicate whether video is to be used or not.

    But we cannot prompt Alice with the getUserMedia pop-up while she has
    not yet decided to answer the incoming call.

    The fact is that both the audio and video will use the same UDP
    channel/transport, so having ICE candidates for the audio and the
    video m lines is just unneeded.

    So IMHO this is another issue due to the usage of SDP, right? or may
    be I am wrong? If so please let me know a use case in which the
    browser would mantain two different UDP channels/transports for the
    same "call" (a single SDP O/A).

    This happens in any non-BUNDLE scenario.=C2=A0

    This is just for "legacy interoperability", right? this is, for t= he
    case in which the remote peer is a not-full-WebRTC device and uses
    different UDP channels/transports for each m line in the SDP. If so,
    would not be MUCH easier just to *require* as per WebRTC specs that
    two peers MUST use a single UDP channel/transport for each SDP O/A?=C2=A0



    --
    I=C3=B1aki Baz Castillo
    <ibc@aliax.net>
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    = https://www.ietf.org/mailman/listinfo/rtcweb

    --001a11c37e30a0643104df39e420-- From partha@parthasarathi.co.in Sun Jun 16 10:01:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF4421F9CF3 for ; Sun, 16 Jun 2013 10:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaqUBSaLELLm for ; Sun, 16 Jun 2013 10:01:40 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.157]) by ietfa.amsl.com (Postfix) with ESMTP id 50F8221F9C51 for ; Sun, 16 Jun 2013 10:01:36 -0700 (PDT) Received: from userPC (unknown [122.179.30.130]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 0FEC4868981; Sun, 16 Jun 2013 17:01:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1371402095; bh=0ZKjaMb+eEFJkQ5SbEFJ9PeB1MPUJlx+IXeWivH39Sg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=jZOiOHbptmlBnFJD3fB3S47nJDSA1EmNX9+ydJoZieq1rokmtRml4Fi16FqDN3ydr rfyo2owtj24MgJewaxZMNd9cwjqDIisaR1YjE0fu8t0Fr8NsHpUm7gtGDoy4Q7cMge YSj2X78AjydB9zc5Mc0gkjSYn36bQje0o+/Ygbzw= From: "Parthasarathi R" To: "'Hadriel Kaplan'" , "'Magnus Westerlund'" References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> In-Reply-To: <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> Date: Sun, 16 Jun 2013 22:31:21 +0530 Message-ID: <004101ce6ab3$23f7b690$6be723b0$@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: Ac5pIIHtBAAeeEcrTJC2PZu6j6JGFQBkVKJQ Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0206.51BDEF6F.00F2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.156 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Jun 2013 17:01:45 -0000 Hi all, IIRC, SDES related presentation was supposed to be discussed during IETF-84 (https://datatracker.ietf.org/meeting/84/agenda/rtcweb/) as per the plan. AFAIK, those presentation are not delivered so far. In case I missed the presentation, Please send the minutes of the meeting. Thanks Partha > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Friday, June 14, 2013 10:29 PM > To: Magnus Westerlund > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] No Interim on SDES at this juncture > > > On Jun 14, 2013, at 3:43 AM, Magnus Westerlund > wrote: > > > However, this time we have proposed a time and requested people to > > submit agenda items to that meeting. Don't hold us WG chairs > responsible > > because you in the WG aren't providing input into what should be > discussed. > > You can't be serious. > There was exactly ONE email asking for agenda items, here: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html > It was sent on May 30th. It gave a generous 6 days to respond. > Luckily no one ever goes on vacation for longer than 5 days. > Instead, two people sent a response on June 10th, a tremendous 11 days > after the request. Outrageous! That's a almost twice as long as they > were given! > > Thank goodness the chairs detected this monstrous breach of procedure, > and thwarted the attempts of anarchy! I mean if people are allowed to > respond to emails so tardily, how can we be expected to get things > accomplished as quickly as they've so far been in this WG?!? > > Sure, an interim for this topic has been waiting for many months if not > a whole year, and now that people didn't respond in 6 days but took > instead 11 days the topic will be delayed indefinitely yet again... but > that's no excuse for blatantly flaunting the rules! > > Personally I saw the email on May 30th, and assumed Oscar and Dan would > respond to you for agenda time. I assumed that if no one had submitted > agenda items to you, that the WG Chairs would send out an email warning > about that, or perhaps even directly email the people who they expected > to submit agenda items. > > > > If you want to discuss this, write a draft describing how how your > > additional keying is to be integrated, what the pro and cons of it. > That > > will enable direct discussion of a proposal. The WG clearly are > > opinionated on this matter, but apparently don't have energy to > produce > > proposals. > > There *are* drafts. > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00 > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 > There are even powerpoint slides, sent to the chairs the last time this > meeting almost happened but didn't. > > I think the problem must be that those things weren't signed in > triplicate, sent in, sent back, queried, lost, found, subjected to > public enquiry, lost again, and finally buried in soft peat for three > months and recycled as firelighters. > > -hadriel > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Sun Jun 16 11:34:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED8021F9949 for ; Sun, 16 Jun 2013 11:34:24 -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, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgQ6Jni851-b for ; Sun, 16 Jun 2013 11:34:18 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAD321F9948 for ; Sun, 16 Jun 2013 11:34:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A7EC39E0FE; Sun, 16 Jun 2013 20:34:16 +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 ORXkbcAeBmuU; Sun, 16 Jun 2013 20:34:16 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C590D39E0D7; Sun, 16 Jun 2013 20:34:15 +0200 (CEST) Message-ID: <51BE0527.1080300@alvestrand.no> Date: Sun, 16 Jun 2013 20:34:15 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115C8A0F@MCHP04MSX.global-ad.net> <51B9C244.9050705@alvestrand.no> <18A33FE7-21D5-4944-BB09-16FB645D8C16@oracle.com> In-Reply-To: <18A33FE7-21D5-4944-BB09-16FB645D8C16@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Jun 2013 18:34:24 -0000 On 06/14/2013 05:39 AM, Hadriel Kaplan wrote: > >> The architectural/non-cost argument I see against decrypt/encrypt is "the gateway wants to be able to disclaim the ability to look at the bits". > I hadn't heard that one. I'm not really sure how one could prove that anyway though, since SDES would certainly give the gateway the *ability* to look at the bits. You would have to either check the code or believe the logs, and if you're willing to believe them then you might as well believe the code/logs that the gateway isn't storing/sampling the bits when it decrypts/encrypts. > I've heard Cullen mention it a number of times when talking about competitors of Cisco using WebEx for business planning. From prvs=7880b7eb98=christer.holmberg@ericsson.com Mon Jun 17 04:28:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4CA21F9B9F for ; Mon, 17 Jun 2013 04:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.735 X-Spam-Level: X-Spam-Status: No, score=-5.735 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNtLUD5lR+yI for ; Mon, 17 Jun 2013 04:28:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 973E821F9BAD for ; Mon, 17 Jun 2013 04:28:31 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-ff-51bef2dda71c Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 54.7F.09795.DD2FEB15; Mon, 17 Jun 2013 13:28:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Mon, 17 Jun 2013 13:28:29 +0200 From: Christer Holmberg To: Adam Roach , "Dale R. Worley" Thread-Topic: [rtcweb] Glare in draft-roach-rtcweb-glareless-add-00 Thread-Index: AQHOTAekTxoOx94qv0S1vaPeO+ga8pj7eRAAgD59R3A= Date: Mon, 17 Jun 2013 11:28:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3A62E8@ESESSMB209.ericsson.se> References: <201305081617.r48GHkcx4369224@shell01.TheWorld.com> <518A9872.8060100@nostrum.com> In-Reply-To: <518A9872.8060100@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3A62E8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+Jvre69T/sCDb62sljs+buI3WLtv3Z2 i5cnyhyYPSbv/8rssWTJTyaPWTufsAQwR3HbJCWWlAVnpufp2yVwZ2w695apYNtqxoqDc36z NTB+nsLYxcjJISFgIrHt5GxWCFtM4sK99WwgtpDAYUaJi3dDIexFjBKnWsS7GDk42AQsJLr/ aYOERQQ8JOb972UBsZkF1CXuLD7HDmILCzhJ7JywgB2ixlnizadmNgjbSuJu114wm0VAVWLS lMtgvbwCvhK/jy5lhliVIPHiynomEJtTQFvi1Ko/YKcxAp32/dQaJohd4hK3nsxngjhZQGLJ nvPMELaoxMvH/1hBzpQQUJRY3i8HUZ4v8ffRFGaIVYISJ2c+YZnAKDoLyaRZSMpmISmDiOtI LNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxjZcxMzc9LLzTcxAqPs4JbfBjsYN90XO8QozcGi JM776dSuQCGB9MSS1OzU1ILUovii0pzU4kOMTBycIIJLqoHR8/yHbXpfdYNYsne4Gs9VSarK mvrwscrmupuFSfOFPz0QkA6dMc80Kzr65LeIRyJpCQJev4qrnpmzqPh157Appzhtce++/CJv tU/j3csndCfF8P+Z9mZ34ux5GR6PFvLtiZkik7m4sjon8tqKgwpHXoVM3MN15vKHk6XfvDu0 fiYaeJ4N4n2sxFKckWioxVxUnAgAbxa1K4UCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Glare in draft-roach-rtcweb-glareless-add-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, 17 Jun 2013 11:28:42 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3A62E8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I agree with Dale, that a much cleaner solution would be a mechanism where = the endpoints agree which SDP Offer shall be processed in case of a glare (= instead of both SDP Offers being rejected). I do, however, realize that it would require an update to 3261 and/or 3264,= as Adam also indicated. But, if we end up needing a mechanism where only o= ne endpoint is allowed to send SDP Offers, I really think we need to ask ou= rselves whether SDP O/A is the right mechanism to begin with :) However, a couple of questions on the draft mechanism: Q1: What if the assigned Offerer receives an solicitation message, indicati= ng that the Answerer would like to add an m- line, but the Offerer knows th= at it would reject such m- line? If the Offerer rejects everything that is requested in the solicitation mes= sage, it could simply reject the solicitation message. But, what if the solicitation message also contains changes that the Offere= r would accept? Would it create the Offer based on the parts in the solicit= ation message that it agrees to, and the Answerer would then assume that wh= atever is not present in the Offer was rejected? Or, would the Offerer in the solicitation message response indicate which p= art(s) was rejected, and then create the Offer based on what it agrees to? To me it sounds like Offer/Answer on top of Offer/Answer :) Q2: What if the Answerer, after it has sent the solicitation message, "chan= ges its mind"? I guess it would have to wait for the response, and then sen= d a new solicitation message, but it may also have to reject the SDP Offer = that the previous solicitation message triggered. This of course depends on what we are going to use O/A for, but if we e.g. = use if for PAUSE/RESUME, where the state can change very frequently, I thin= k it could happened rather often. Regards, Christer From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Adam Roach Sent: 8. toukokuuta 2013 21:25 To: Dale R. Worley Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Glare in draft-roach-rtcweb-glareless-add-00 On 5/8/13 11:17, Dale R. Worley wrote: > I see that draft-roach-rtcweb-glareless-add-00 eliminates glare a > the SDP offer/answer level, but it seems to do so by having glare at > the higher "solicitation" level -- the designated answer can discover > that it has received an offer that is not correspondent with the > solicitation that it has sent. The result is that the proposal > includes a bunch of logic which has the structure of > glare-resolution logic. The logic is actually much, much simpler in that it only requires queuing o= f an outstanding operation rather than the relatively messy (and time consu= ming) business of backing off and running timers. I will also emphasize that the condition you're describing arises far, far = less frequently than general glare. In the vast majority of the cases (wher= e the number of m=3D sections is not changing), the queuing isn't even nece= ssary. The only cases requiring queuing are those in which the offerer isn'= t trying to add streams but the answerer is. > The benefit of the proposal is that it avoids "When [glare] happens > mid-session, user experience can be negatively impacted." But I > don't fully understand what the negative user experience impact is or > how this proposal eliminates it -- given that glare can still > happen. I don't think it's really fair to characterize the situation you're describ= ing as glare. It's more of a system-wide enforcement of event ordering acco= rding to the order in which they occur at a cannonical observer. We've just= arbitrarily chosen that observer to be whichever party offers first. > As far as I can tell so far, the core advantage is that this > proposal resolves glare faster than the RFC 3261 (section 14) > procedure because the designated answerer is required to process the > updated offer it receives even if that is not the updated offer it > has solicited. I think the core advantage is that the situation in which any exceptional b= ehavior arises is several orders of magnitude more rare than the situation = in which generalized glare can arise. > I haven't thought through the details, but it seems to me that the > same effect could probably be achieved by negotiating an amendment > to the RFC 3261 glare-recovery procedure with similar properties... Fixing 3261 does nothing for RTCWEB. We'd need to change 3264. :) > There's also the question how this gets negotiated across a gateway > to SIP. Section 3. /a --_000_7594FB04B1934943A5C02806D1A2204B1C3A62E8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

     <= /p>

    Hi,

     <= /p>

    I agree with Dale, that a= much cleaner solution would be a mechanism where the endpoints agree which= SDP Offer shall be processed in case of a glare (instead of both SDP Offers being rejected).

     <= /p>

    I do, however, realize th= at it would require an update to 3261 and/or 3264, as Adam also indicated. = But, if we end up needing a mechanism where only one endpoint is allowed to send SDP Offers, I really think we need to ask ourselves whe= ther SDP O/A is the right mechanism to begin with :)

     <= /p>

    However, a couple of ques= tions on the draft mechanism:

     <= /p>

    Q1: What if the assigned Offerer receives an solicitation m= essage, indicating that the Answerer would like to add an m- line, but the Offerer= knows that it would reject such m- line?

     <= /p>

    If the Offerer rejects ev= erything that is requested in the solicitation message, it could simply rej= ect the solicitation message.

     <= /p>

    But, what if the solicita= tion message also contains changes that the Offerer would accept? Would it = create the Offer based on the parts in the solicitation message that it agrees to, and the Answerer would then assume that whateve= r is not present in the Offer was rejected?

     <= /p>

    Or, would the Offerer in = the solicitation message response indicate which part(s) was rejected, and = then create the Offer based on what it agrees to?

     <= /p>

    To me it sounds like Offe= r/Answer on top of Offer/Answer :)

     <= /p>

     <= /p>

    Q2: What if the Answerer, after it has sent the solicitatio= n message, “changes its mind”? I guess it would have to wait for the resp= onse, and then send a new solicitation message, but it may also have to rej= ect the SDP Offer that the previous solicitation message triggered.

     <= /p>

    This of course depends on= what we are going to use O/A for, but if we e.g. use if for PAUSE/RESUME, = where the state can change very frequently, I think it could happened rather often.

     <= /p>

     <= /p>

    Regards,

     <= /p>

    Christer

     <= /p>

     <= /p>

     <= /p>

     <= /p>

     <= /p>

     <= /p>

     <= /p>

     <= /p>

     <= /p>

     <= /p>

     <= /p>

    From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach
    Sent: 8. toukokuuta 2013 21:25
    To: Dale R. Worley
    Cc: rtcweb@ietf.org
    Subject: Re: [rtcweb] Glare in draft-roach-rtcweb-glareless-add-00

     

    On 5/8/13 11:17, Dale R. Worley wrote:
    > I see that

          draft-roach-rtcweb-gl= areless-add-00 eliminates glare a

          > the SDP offer/an= swer level, but it seems to do so by having

          glare at

          > the higher "= ;solicitation" level -- the designated answer can

          discover

          > that it has rece= ived an offer that is not correspondent with

          the

          > solicitatio= n that it has sent.  The result is that the

          proposal

          > includes a = bunch of logic which has the structure of

          > glare-resolution= logic.

    The logic is actually much, much simpler in that it only requires queuing o= f an outstanding operation rather than the relatively messy (and time consu= ming) business of backing off and running timers.

    I will also emphasize that the condition you're describing arises far, far = less frequently than general glare. In the vast majority of the cases (wher= e the number of m=3D sections is not changing), the queuing isn't even nece= ssary. The only cases requiring queuing are those in which the offerer isn't trying to add streams but the answere= r is.

    > The benefit of the proposal is

          that it avoids "= When [glare] happens

          > mid-session= , user experience can be negatively impacted." 

          But I

          > don't fully unde= rstand what the negative user experience

          impact is or

          > how this proposa= l eliminates it -- given that glare can still

          > happen.

    I don't think it's really fair to characterize the situation you're describ= ing as glare. It's more of a system-wide enforcement of event ordering acco= rding to the order in which they occur at a cannonical observer. We've just= arbitrarily chosen that observer to be whichever party offers first.

    > As far as I can tell so far,

          the core advantage is= that this

          > proposal resolve= s glare faster than the RFC 3261 (section 14)

          > procedure becaus= e the designated answerer is required to

          process the

          > updated offer it= receives even if that is not the updated

          offer it

          > has solicited.
    I think the core advantage is that the situation in which any exceptional b= ehavior arises is several orders of magnitude more rare than the situation = in which generalized glare can arise.

    > I haven't thought through the

          details, but it seems= to me that the

          > same effect= could probably be achieved by negotiating an

          amendment

          > to the RFC 3261 = glare-recovery procedure with similar

          properties...

       
    Fixing 3261 does nothing for RTCWEB. We'd need to change 3264. :)

    > There's also the question how

          this gets negotiated = across a gateway

       &nb= sp;  > to SIP.

    Section 3.

    /a

    --_000_7594FB04B1934943A5C02806D1A2204B1C3A62E8ESESSMB209erics_-- From ibc@aliax.net Mon Jun 17 05:09:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE9221F9B5D for ; Mon, 17 Jun 2013 05:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.742 X-Spam-Level: X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuYfVUaAZeHY for ; Mon, 17 Jun 2013 05:09:57 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4FB21F9B4A for ; Mon, 17 Jun 2013 05:09:56 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ci6so1395332qab.11 for ; Mon, 17 Jun 2013 05:09: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=BWEbjxMTPsv10Voe6YBTbvc7XWK11TyaL/lV+efdTPw=; b=aAFe74XpBMqOJSwTZWycPtEuRbBpiwSTvBnvwuofCVGyJq5TyVlsyH3ylgldbhn61G rIE4FO1H8VlVO4qJr1trypg+YyGd859AWYK8y8IiUtP+0WDQbTV9psLkO/N7CHksm2dS MrQrtddA417zUXsq2H1xMVW/2i/nXjj8MedBtc+Uh0s66mHlAdOvJ3Mv7NGhShri8T3y pFnvG66gt0fnkuvhnEwHi9r2f06iEz2Ov9fVALT1974S9f6G1EANMLHdKQxy7I/Fbp9P EfwwaWFgyFAKVaEdg2OE+brvwjTQTzRk1DcUd0ZRxiosW5fenG/cMtoi5PtgWrXX5Q9E v74g== X-Received: by 10.224.60.195 with SMTP id q3mr16669663qah.82.1371470996225; Mon, 17 Jun 2013 05:09:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Mon, 17 Jun 2013 05:09:36 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3A62E8@ESESSMB209.ericsson.se> References: <201305081617.r48GHkcx4369224@shell01.TheWorld.com> <518A9872.8060100@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3A62E8@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 17 Jun 2013 14:09:36 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnnXsgf/uF1Bh6szlNwKNWVbmVbVX34wrywwhRM8O4eJPCinz0skNuy4MQtSV/c8xDk4h4q Cc: "rtcweb@ietf.org" , "Dale R. Worley" Subject: Re: [rtcweb] Glare in draft-roach-rtcweb-glareless-add-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, 17 Jun 2013 12:09:59 -0000 2013/6/17 Christer Holmberg : > I do, however, realize that it would require an update to 3261 and/or 326= 4, > as Adam also indicated. But, if we end up needing a mechanism where only = one > endpoint is allowed to send SDP Offers, > I really think we need to ask ourselves whether SDP O/A is the right mech= anism to begin with :) Well, after two years we still don't know how to use SDP to feature and satisfy WebRTC requirements (this happens when a document format is decided before spec/protocol/API requirements). So... not, SDP O/A is not the right mechanism for WebRTC. -- I=C3=B1aki Baz Castillo From pthatcher@google.com Mon Jun 17 05:57:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC6021F9B35 for ; Mon, 17 Jun 2013 05:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkwJfP+WwHtV for ; Mon, 17 Jun 2013 05:57:46 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8E63B21F8E2A for ; Mon, 17 Jun 2013 05:57:46 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj3so2857800pad.28 for ; Mon, 17 Jun 2013 05:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=r39axpO5mOrL0Esblz9jTvSALEI6258wigRIsI9M9ew=; b=Z4feHi/XDdj0ml0RjuNHC9/sorgJ4La5tByNSzYHaTJ8kP2lzGzd/XIHXlEJxP0gl5 TFDR0r5UMgPlLAOUkhasst1cOPAJmWsE0zP9VTQ9aQvO/ugo83sz7m2i5ICOhSimO4PV iryweH7K2GHwCM/sVoNsiWXvSD/2O+BUzXFeuyAm2FFhnaFJWkl6mWjbr+g4bfN+sfSr wu8HWKRTZuTMl5rCKgffHFKu9CBYtApNbUHfpvrMvIcFt811T2SL/kq+1xOva5MQWLk0 xzDMRMFJqb5hznJVrSf60egG/hrQ112rQB0+oEDESyEEyKyVTaxIp2k9ZVckLfuhK5Aw FJpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=r39axpO5mOrL0Esblz9jTvSALEI6258wigRIsI9M9ew=; b=Odt/MWuMaVdbMPJAcJTySeLJBHwgm0/ArrNlhoXW0z0CxOd/M3lYc2pfhXGp5tuiPR 1ayXRpbZgR0ljViAv5g1lj23+LJBPIPNryw65SWW/CLKdJbTFbaSjhAoz2Du+6+Fl1Ij EXo4XqsNqixL8WEblNUZtdUXzoKa8asJrMwctfSKF8yOKKMXxnw+04DIv0+6gp5Kq7CK NjPfU2yDGxyc4gt22Q2aWII90g/xuiHs3SCfdLucFaYB/HLhZFBArc4+50ZsehQISpvp XBHpyVwUSG8/i2Bdbis13Lj2OgQ/Ah6vvpAVMouPz/vdSzk4ux+cnF7SMZWcXjKp9JZA Wu4w== X-Received: by 10.66.240.70 with SMTP id vy6mr13044764pac.70.1371473865965; Mon, 17 Jun 2013 05:57:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Mon, 17 Jun 2013 05:57:05 -0700 (PDT) From: Peter Thatcher Date: Mon, 17 Jun 2013 05:57:05 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary=047d7b15aba9999a0104df592456 X-Gm-Message-State: ALoCoQnuSd1X+7u/qWqb508YSwC0SSM7Q4Jr71/l+aoz22+jjGU45wd6AL3+D7A/ySQt0fCFbjE0no3rVtaJyNBm8J6tSzaV84MSABuaLSZRr4nZ+4q2iY8OExd9niyTEF7dVuksJ59lpbtvYYkW/8A6GW6IKWlmmvqSYFmIu+OCS/KWDBn/6v5bET7DF6JOwIcQB9E31BpT Subject: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 12:57:48 -0000 --047d7b15aba9999a0104df592456 Content-Type: text/plain; charset=UTF-8 Google is in full support of "Plan B" for encoding multiple media sources in SDP, and would like to see the Plan A vs. Plan B decision resolved soon. Recently, though, a third option, called "NoPlan" has been proposed, but it lacked the details of what a JS API would look like for NoPlan. Cullen asked to see such an API proposal, and so I have worked with Emil to make one. He will be adding it to the NoPlan draft, but I will also include it in this email. Again, Google is in full support of "Plan B". But if Plan A vs. Plan B cannot be decided, then we support NoPlan with the following additions to the WebRTC JS API as an option that allows implementing either Plan A or Plan B in Javascript. And even if Plan A vs. Plan B is resolved, these API additions would still be a big improvement for those WebRTC applications that don't use SDP for signalling. It is a bit long because I have added many comments and examples, but the actually additions only include two new methods on PeerConnection and a few new dictionaries. So don't be overwhelmed :). Intro: This follows the model of createDataChannel, which has a JS method on PeerConnection that makes it possible to add data channels without going through SDP. Furthermore, just like createDataChannel allows 2 ways to handle neogitation (the "I know what I'm doing; Here's what I want to send; Let me signal everything" mode and the "please take care of it for me; send an OPEN message" mode), this also has 2 ways to handle negotiation (the "I know what I'm doing; Here's what I want to send; Let me signal everything" mode and the "please take care of it for me; send SDP back and forth" mode). Following the success of createDataChannel, this allows simple applications to Just Work and more advanced applications to easily control what they need to. In particular, it's possible to use this API to implement either Plan A or Plan B. // The following two method are added to RTCPeerConnection partial interface RTCPeerConnection { // Create a stream that is used to send a source stream. // The MediaSendStream.description can be used for signalling. // No media is sent until addStream(MediaSendStream) is called. LocalMediaStream createLocalStream(MediaStream sourceStream); // Create a stream that is used to receive media from the remote side, // given the parameters signalled from MedaiSendStream.description. MediaStream createRemoteStream(MediaStreamDescription description); } interface LocalMediaStream implements MediaStream { // This can be changed at any time, but especially before calling // PeerConnection.addStream attribute MediaStreamDescription description; } // Represents the parameters used to either send or receive a stream // over a PeerConnection. dictionary MediaStreamDescription { MediaStreamTrackDescription[] tracks; } // Represents the parameters used to either send or receive a track over // a PeerConnection. A track has many "flows", which can be grouped // together. dictionary MediaStreamTrackDescription { // Same as the MediaStreamTrack.id DOMString id; // Same as the MediaStreamTrack.kind DOMString kind; // A track can have many "flows", such as for Simulcast, FEC, etc. // And they can be grouped in arbitrary ways. MediaFlowDescription[] flows; MediaFlowGroup[] flowGroups; } // Represents the parameters used to either send or receive a "flow" // over a PeerConnection. A "flow" is a media that arrives with a // single, unique SSRC. One to many flows together make up the media // for a track. For example, there may be Simulcast, FEC, and RTX // flows. dictionay MediaFlowDescription { // The "flow id" must be unique to the track, but need not be unique // outside of the track (two tracks could both have a flow with the // same flow ID). DOMString id; // Each flow can go over its own transport. If the JS sets this to a // transportId that doesn't have a transport setup already, the // browser will use SDP negotiation to setup a transport to back that // transportId. If This is set to an MID in the SDP, then that MID's // transport is used. DOMString transportId; // The SSRC used to send the flow. unsigned int ssrc; // When used as receive parameters, this indicates the possible list // of codecs that might come in for this flow. For exmample, a given // receive flow could be setup to receive any of OPUS, ISAC, or PCMU. // When used as send parameters, this indicates that the first codec // should be used, but the browser can use send other codecs if it // needs to because of either bandwidth or CPU constraints. MediaCodecDescription[] codecs; } dictionary MediaFlowGroup { DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc DOMString[] flowids; } dictionary MediaCodecDescription { unsigned byte payloadType; DOMString name; unsigned int? clockRate; unsigned int? bitRate; // A grab bag of other fmtp that will need to be further defined. MediaCodecParam[] params; } dictionary MediaCodecParam { DOMString key; DOMString value; } Notes: - When LocalMediaStreams are added using addStream, onnegotiatedneeded is not called, and those streams are never reflected in future SDP exchanges. Indeed, it would be impossible to put them in the SDP without first resolving if that would be Plan A SDP or Plan B SDP. - Just like piles of attributes would need to be defined for Plan A and for Plan B, similar attributes would need to be defined here (Luckily, much work has already been done figuring out what those parameters are :). Pros: - Either Plan A or Plan B or could be implemented in Javascript using this API - It exposes all the same functionality to the Javascript as SDP, but in a much nicer format that is much easier to work with. - Any other signalling mechanism, such as Jingle or CLUE could be implemented using this API. - There is almost no risk of signalling glare. - Debugging errors with misconfigured descriptions should be much easier with this than with large SDP blobs. Cons: - Now there are two slightly different ways to add streams: by creating a LocalMediaStream first, and not. This is, however, analogous to setting "negotiated: true" in createDataChannel. On way is "Just Work", and the other is more advanced control. - All the options in MediaCodecDescription are a bit complicated. Really, this is only necessary because Plan A requires being able to specify codec parameters per SSRC, and set each flow on different transports. If we did not have this requirement, we could simplify. Example Usage: // Imagine I have MyApp, handles creating a PeerConnection, // signalling, and rendering streams. This is how the new API could be // used. var peerConnection = MyApp.createPeerConnection(); // On sender side: var stream = MyApp.getMediaStream(); var localStream = peerConnection.createSendStream(stream); sendStream.description = MyApp.modifyStream(localStream.description) MyApp.signalAddStream(localStream.description, function(response)) { if (!response.rejected) { // Media will not be sent. peerConnection.addStream(localStream); } } // On receiver side: MyApp.onAddStreamSignalled = function(streamDescription) { var stream = peerConnection.createReceiveStream(streamDescription); MyApp.renderStream(stream); } // In this exchange, the MediaStreamDescription signalled from the // sender to the receiver may have looked something like this: { tracks: [ { id: "audio1", kind: "audio", flows: [ { id: "main", transportId: "transport1", ssrc: 1111, codecs: [ { payloadType: 111, name: "opus", // ... more codec details }, { payloadType: 112, name: "pcmu", // ... more codec details }] }] }, { id: "video1", kind: "video", flows: [ { id: "sim0", transportId: "transport2", ssrc: 2222, codecs: [ { payloadType: 122, name: "vp8" // ... more codec details }] }, { id: "sim1", transportId: "transport2", ssrc: 2223, codecs: [ { payloadType: 122, name: "vp8", // ... more codec details }] }, { id: "sim2", transportId: "transport2", ssrc: 2224, codecs: [ { payloadType: 122, name: "vp8", // ... more codec details }] }, { id: "sim0fec", transportId: "transport2", ssrc: 2225, codecs: [ { payloadType: 122, name: "vp8", // ... }] }], flowGroups: [ { semantics: "SIM", ssrcs: [2222, 2223, 2224] }, { semantics: "FEC", ssrcs: [2222, 2225] }] }] } Constructive feedback is welcome :). --047d7b15aba9999a0104df592456 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Google is in full support of "Plan B" for en= coding multiple media sources in SDP, and would like to see the Plan A vs. = Plan B decision resolved soon. =C2=A0Recently, though, a third option, call= ed "NoPlan" has been proposed, but it lacked the details of what = a JS API would look like for NoPlan. =C2=A0Cullen asked to see such an API = proposal, and so I have worked with Emil to make one. =C2=A0He will be addi= ng it to the NoPlan draft, but I will also include it in this email.

    Again, Google is in full support of "Plan B". =C2=A0But if Pl= an A vs. Plan B cannot be decided, then we support NoPlan with the followin= g additions to the WebRTC JS API as an option that allows implementing eith= er Plan A or Plan B =C2=A0in Javascript. =C2=A0And even if Plan A vs. Plan = B is resolved, these API additions would still be a big improvement for tho= se WebRTC applications that don't use SDP for signalling.

    It is a bit long because I have added many comments and examples, but t= he actually additions only include two new methods on PeerConnection and a = few new dictionaries. =C2=A0So don't be overwhelmed :).



    Intro: This follows the m= odel of createDataChannel, which has a JS method on PeerConnection that mak= es it possible to add data channels without going through SDP. =C2=A0Furthe= rmore, just like createDataChannel allows 2 ways to handle neogitation (the= "I know what I'm doing; =C2=A0Here's what I want to send; Let= me signal everything" mode and the "please take care of it for m= e; =C2=A0send an OPEN message" mode), this also has 2 ways to handle n= egotiation (the "I know what I'm doing; Here's what I want to = send; Let me signal everything" mode and the "please take care of= it for me; =C2=A0send SDP back and forth" mode).=C2=A0
    = =C2=A0
    Following the success of cr= eateDataChannel, this allows simple applications to Just Work and more adva= nced applications to easily control what they need to. =C2=A0In particular,= it's possible to use this API to implement either Plan A or Plan B.

    // The following two method are a= dded to RTCPeerConnection
    partial interface RTCPeerConnection {
    =C2= =A0// Create a stream that is used to send a source stream.
    =C2=A0// The= MediaSendStream.description can be used for signalling.
    =C2=A0// No media is sent until addStream(MediaSendStream) is called.
    =C2=A0LocalMediaStream createL= ocalStream(MediaStream sourceStream);

    =C2=A0// Create a stream that is used to receive media from the remote = side,
    =C2=A0// given the parameters signalled from MedaiSendStream.descr= iption.
    =C2=A0MediaStream createRemoteStream(MediaStreamDescription desc= ription);
    }


    interface LocalMediaStream implements MediaStream {
    =C2=A0 = // This can be changed at any time, but especially before calling
    =C2=A0= // PeerConnection.addStream
    =C2=A0 attribute MediaStreamDescripti= on description;
    }

    =
    // Represents the parameters used to either send or receive a stream=C2= =A0
    = // over a=C2=A0PeerConnection.
    dic= tionary MediaStreamDescription {
    =C2=A0 MediaStreamTrackDescription[] tr= acks;
    }


    // Represents the parameters used to either send or receive a track= over // a=C2=A0PeerConnection. =C2=A0A track has many "flows", w= hich can be grouped=C2=A0
    // together.
    dictionary MediaStrea= mTrackDescription {
    =C2=A0 // Same as the MediaStreamTrack.id
    =C2=A0 = DOMString id;

    =C2=A0 // Same as the MediaStreamTrack.kind
    =C2=A0 = DOMString kind; =C2=A0

    =C2=A0 // A track can have many "flows", such as for Simulcas= t, FEC, etc.
    =C2=A0 // And they can be grouped in arbitrary ways.
    =C2= =A0 MediaFlowDescription[] flows;
    =C2=A0 MediaFlowGroup[] flowGroups;}

    // Represents the parameters used to = either send or receive a "flow"=C2=A0
    // over a=C2=A0PeerConnection. =C2=A0A "flow&qu= ot; is a media that arrives with a=C2=A0
    = // single, unique SSRC. =C2=A0One to = many flows together make up the media=C2=A0
    // for a track. =C2=A0For=C2=A0exampl= e, there may be Simulcast, FEC, and RTX=C2=A0
    // flows.
    dictionay MediaFlowDescription {
    =C2=A0 // The "flow id" must = be unique to the track, but need not be unique=C2=A0
    =C2=A0 // outside=C2=A0of the track (two tracks= could both have a flow with the=C2=A0
    = =C2=A0 // same flow ID).
    =C2=A0 DO= MString id;

    =C2=A0 // Each flow can go over its own transport. =C2= =A0If the JS sets this to a
    =C2=A0 // transportId that doesn't have a transport setup already, the= =C2=A0
    =C2=A0 // browser = will use SDP negotiation to setup a transport to back that=C2=A0
    = =C2=A0 // transportId. =C2=A0If=C2=A0= This is set to an MID in the SDP, then that MID's=C2=A0
    =C2=A0 // transport is used.
    =C2= =A0 DOMString transportId;

    =C2=A0 // The SSRC used to send the flow.=
    =C2=A0 unsigned int ssrc;

    =C2=A0 // When used as receive parameters, this indicates the possib= le list=C2=A0
    = =C2=A0 // of codecs that might come i= n for this flow. =C2=A0For exmample, a given=C2=A0
    =C2=A0 // receive=C2=A0flow could be = setup to receive any of OPUS, ISAC, or PCMU.
    =C2=A0 // When used as send= parameters, this indicates that the first codec=C2=A0
    =C2=A0 // should=C2=A0be used, but th= e browser can use send other codecs if it=C2=A0
    =C2=A0 // needs to because=C2=A0of either bandwidth = or CPU constraints.
    =C2=A0 MediaCodecDescription[] codecs;
    }


    dictionary MediaFlow= Group {
    =C2=A0 DOMString type; =C2=A0// "SIM" for Simulcast, &= quot;FEC" for FEC, etc
    =C2=A0 DOMString[] flowids;
    }

    dictionary MediaCodecDescrip= tion {
    =C2=A0 unsigned byte payloadType;
    =C2=A0 DOMString name;
    = =C2=A0 unsigned int? clockRate;
    =C2=A0 unsigned int? bitRate;
    =C2=A0 // A grab bag of other fmtp th= at will need to be further defined.
    =C2=A0 MediaCodecParam[] params; =C2= =A0
    }

    dictionary MediaCodecParam {
    =C2=A0 DOMString key;
    = =C2=A0 DOMString value;
    }


    Notes:

    - When LocalMediaStreams are added using addStre= am, onnegotiatedneeded is not called, and those streams are never reflected= in future SDP exchanges. =C2=A0Indeed, it would be impossible to put them = in the SDP without first resolving if that would be Plan A SDP or Plan B SD= P.
    =
    - Just like piles of attributes would need to be defined = for Plan A and for Plan B, similar attributes would need to be defined here= (Luckily, =C2=A0much work has already been done figuring out what those pa= rameters are :).


    Pros:

    - Either Plan A or Plan B or could be implemented in J= avascript using this API
    - It exposes all the same functionality to the = Javascript as SDP, but in a much nicer format that is much easier to work w= ith.
    - Any other signalling mechanism, such as Jingle or CLUE could be implement= ed using this API.
    - There is almost no risk of signalling glare.
    - D= ebugging errors with misconfigured descriptions should be much easier with = this than with large SDP blobs.


    Cons:

    - Now there are = two slightly different ways to add streams: by creating a LocalMediaStream = first, and not. =C2=A0This is, however, analogous to setting "negotiat= ed: true" in createDataChannel. =C2=A0On way is "Just Work",= and the other is more advanced control.
    =
    - All the options in MediaCodecDescription are a bit comp= licated. =C2=A0Really, this is only necessary because Plan A requires being= able to specify codec parameters per SSRC, and set each flow on different = transports. =C2=A0If we did not have this requirement, we could simplify.

    Example Usage:

    // Imagine I have MyApp, handles creating a P= eerConnection,
    // signalling, and rendering streams. =C2=A0This is how t= he new API could be=C2=A0
    // used.
    var peerConnection =3D My= App.createPeerConnection();

    // On sender side:
    var stream =3D MyA= pp.getMediaStream();
    var localStream =3D peerConnection.createSendStream= (stream);
    sendStream.description =3D MyApp.modifyStream(localStream.description)
    M= yApp.signalAddStream(localStream.description, function(response)) {
    =C2= =A0 if (!response.rejected) {
    =C2=A0 =C2=A0 // Media will not be sent.=C2=A0 =C2=A0 peerConnection.addStream(localStream);
    =C2=A0 }
    }

    // On receiver side:
    MyApp.onAddStreamSignalled =3D= function(streamDescription) {
    =C2=A0 var stream =3D peerConnection.crea= teReceiveStream(streamDescription);
    =C2=A0 MyApp.renderStream(stream);}


    // In this exchange, the MediaStreamDescription signalled fro= m the=C2=A0
    // sender to=C2=A0the receiver may ha= ve looked something like this:

    {
    =C2=A0 tracks: [
    =C2=A0 {
    = =C2=A0 =C2=A0 id: "audio1",
    =C2=A0 =C2=A0 kind: "audio&qu= ot;,
    =C2=A0 =C2=A0 flows: [
    =C2=A0 =C2=A0 {
    =C2=A0 =C2=A0 =C2=A0=C2=A0    id: "main",
    =C2=A0 =C2=A0 =C2=A0 transportId: "transport1", =C2=A0 = =C2=A0 =C2=A0 ssrc: 1111,
    <= /font>=C2=A0 = =C2=A0 =C2=A0 codecs: [
    =C2=A0 = =C2=A0 =C2=A0 {
    =C2=A0 =C2=A0 =C2= =A0 =C2=A0 payloadType: 111, =C2=A0 = =C2=A0 =C2=A0 =C2=A0 name: "opus",
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... more codec details
    = =C2=A0 =C2=A0 = =C2=A0 },
    =C2=A0 =C2=A0 = =C2=A0 {=C2=A0
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 112,
    =C2=A0 =C2=A0 =C2=A0 =C2= =A0 name: "pcmu",
    =C2=A0 =C2=A0 = =C2=A0 =C2=A0=C2=A0// ... more codec details
    =C2=A0 =C2=A0 = =C2=A0 }]
    =C2=A0 =C2=A0}]=C2=A0},
    =C2=A0{
    =C2=A0 =C2=A0 id: "video1",
    =C2=A0 = =C2=A0 kind: "video",
    =C2= =A0 =C2=A0 flows: [
    = =C2=A0 =C2=A0 {=
    =C2=A0 =C2=A0 = =C2=A0 id: "sim0",
    =C2=A0 =C2=A0 =C2=A0 transportId: "transport= 2",
    =C2=A0 = =C2=A0 =C2=A0 ssrc: 2222,
    <= /font>=C2=A0 = =C2=A0 =C2=A0 codecs: [
    =C2=A0 = =C2=A0 =C2=A0 {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 122,
    =C2=A0 = =C2=A0 =C2=A0 =C2=A0 name: "vp8"
    =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0// ... mor= e codec details
    = =C2=A0 =C2=A0 = =C2=A0 }]
    =C2=A0 =C2=A0},
    =C2=A0 =C2=A0{
    = =C2=A0 =C2=A0 =C2=A0id: "sim1",
    =C2=A0 =C2=A0 =C2=A0transportI= d: "transport2",
    =C2=A0 =C2=A0 =C2=A0ssrc: 2223,
    =C2=A0 =C2= =A0 =C2=A0codecs: [
    =C2=A0 =C2=A0 =C2=A0{
    =C2=A0 =C2=A0 =C2=A0 =C2=A0= payloadType: 122,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "vp8",
    =C2=A0 =C2=A0 =C2=A0 =C2=A0    // ... more codec details
    =C2=A0 =C2=A0 =C2=A0}]
    =C2=A0 =C2=A0},
    =C2=A0 =C2= =A0{
    =C2=A0 =C2=A0 =C2=A0id: "sim2",
    =C2=A0 =C2=A0 =C2=A0tr= ansportId: "transport2",
    =C2=A0 =C2=A0 =C2=A0ssrc: 2224,
    =C2=A0 =C2=A0 =C2=A0codecs: [
    =C2=A0 = =C2=A0 =C2=A0{
    =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 122,
    =C2=A0 = =C2=A0 =C2=A0 =C2=A0name: "vp8",
    =C2=A0 =C2=A0 =C2=A0 =C2=A0// ... mor= e codec details
    =C2=A0 =C2=A0 =C2=A0}]
    =C2=A0 =C2=A0},

    =C2=A0 =C2=A0{
    =C2=A0 = =C2=A0 =C2=A0id: "sim0fec",
    =C2=A0 =C2=A0 =C2=A0transportId: &= quot;transport2",
    =C2=A0 =C2=A0 =C2=A0ssrc: 2225,
    =C2=A0 =C2=A0 = =C2=A0codecs: [
    =C2=A0 =C2=A0 =C2=A0{
    =C2=A0 =C2=A0 =C2=A0 =C2=A0payl= oadType: 122,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "vp8",
    =C2= =A0 =C2=A0 =C2=A0 =C2=A0// ...
    =C2=A0 =C2=A0 =C2=A0}]
    =C2=A0 =C2=A0}],
    =C2=A0 =C2=A0flowGroups: [=C2=A0 =C2=A0{
    =C2=A0 =C2=A0 =C2=A0semantics: "SIM",
    =C2= =A0 =C2=A0 =C2=A0ssrcs: [2222, 2223, 2224]
    =C2=A0 =C2=A0},
    =C2=A0 =C2= =A0{
    =C2=A0 =C2=A0 =C2=A0semantics: "FEC",
    =C2=A0 =C2=A0 = =C2=A0ssrcs: [2222, 2225]
    =C2=A0 =C2=A0}]
    =C2=A0}]
    }


    Constructive feedback is welcome :).
    --047d7b15aba9999a0104df592456-- From pthatcher@google.com Mon Jun 17 05:59:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F8C21F9BA6 for ; Mon, 17 Jun 2013 05:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8HVEkgfLxrh for ; Mon, 17 Jun 2013 05:59:27 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB9921F9B8D for ; Mon, 17 Jun 2013 05:59:27 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc8so2756290pbc.18 for ; Mon, 17 Jun 2013 05:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CTJuMzFO8nA13bphYdGX6GQQTEn07PpXiXoS08YzvC0=; b=LOnLFamllZF58Slh3Ye7pMMbp18fMwD4MkZ3kDmM3b5FSTvpKCJYj+wDi8H+0QrgMi +nnYF1yTjiqebc/ScXqzoZwUncVN8hy6UvBMNbnA8P0Ve8B3BpwjLW7RbJgNlKD6QsfO JjwPUHjTKSfOUmvdwdfvrNv/OqbUQtsgm5266xX68vHOqSGZY35WnHF3KIQ28+7Xf+Cr 2miWVUty/MyEuCx1JvYHh6TWIrMuwZRp3p+j/XZO8i6IU0Uy1WAZMaAtRbBtKpF2hybS znc6HRnEaAMPlL25FtcH3hs4/qW/aIf/Q9BIDDTqwP3k0rI2AgekJJALlzyYaaWGKLyg RQgQ== 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=CTJuMzFO8nA13bphYdGX6GQQTEn07PpXiXoS08YzvC0=; b=Lia93vbjb3tQ+1k7hrNOlxV0SqyKb8gmanNBN3rZpv95fncb3jh3clLxXi+6790jH2 nkrW2BdhOqhqKjEybGNK8K3Maa7wKnCLhMxSBX3CwW31MkbhoQU+VLB9HLGDiH7YJANt fN8iWVbGIqacrdF3GGkLXYFc2A1RjZ1jZoexkOegF9YnJyvYG5WQkiLTaUfQVhDCg8VP YEfsrwSeFMCFp1FpxNlooAXJrqldU7o+atbDt8gAtdtCegPgXP8QxwAn/HU6DCIPDnCq oQC2gchQeyFGfEca31gV0tRxW75O2wTvXoYcWVZKg3J1rZ9lqAmuI/Kn69Vg171YBZ7J lNLw== X-Received: by 10.66.83.7 with SMTP id m7mr13061415pay.150.1371473966688; Mon, 17 Jun 2013 05:59:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Mon, 17 Jun 2013 05:58:46 -0700 (PDT) In-Reply-To: <6AC8E7C0-F199-4090-94D6-FFF2DF1559F0@iii.ca> References: <51A65017.4090502@jitsi.org> <51A8EB7F.6000506@jitsi.org> <72B58042-78E3-4759-B3CD-204B82A38447@iii.ca> <51ACF998.5030202@jitsi.org> <5ED2CC48-1514-4C00-AEE8-A334EB67A6F4@iii.ca> <51AF5784.3060307@jitsi.org> <13444A29-86C6-4D69-964D-AE9A5BA7BB4A@iii.ca> <6AC8E7C0-F199-4090-94D6-FFF2DF1559F0@iii.ca> From: Peter Thatcher Date: Mon, 17 Jun 2013 05:58:46 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=f46d042ef48d9a83dc04df592ad6 X-Gm-Message-State: ALoCoQmtZggczStzmFdd+F7bSPspfRL0/TiiIAF4zZ21v5X7EqDqG7ZcBC0P0xWUGxzL5u1MslCbodTG8yE+xGilIa9tX/LPPnKcGcRFZVJw70SNG465MtvY2AQmajr4lWm4dfJeGsj83ddSUmDqJH9bQuMfdQHC/HSE2YXzg18u0TrF7NZ+DNRKYDU/BUkoBtbJ/yYZGxb7 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan - but what's the proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 12:59:27 -0000 --f46d042ef48d9a83dc04df592ad6 Content-Type: text/plain; charset=UTF-8 >From Cullen: "We need to agree on roughly what is passed across the JS API such that the browser know how to set up the media stack to send and receive the appropriate RTP that is desired by the JS application" I think this hits the nail on the head. Generally, we need to decide what the JS API is to allow the JS app to control what is sent and received. Specifically for NoPlan, we need a JS API that does not rely on encoding multiple sources in SDP and doesn't require extra SDP exchanges to add/remove sources. I'm glad you asked for such an API, because I was interested in working on one. So, I just sent an email with a proposed JS API, and Emil will be updating the draft RFC to incorporate it. To be clear, Google is in full support of Plan B, and wants to see the Plan A vs. Plan B decision resolved. But if Plan A vs. Plan B cannot be decided, then we support NoPlan with this JS API as a backup plan, since Plan B could be implemented on top of NoPlan within JS (and so could Plan A). On Fri, Jun 7, 2013 at 10:43 PM, Cullen Jennings wrote: > > On Jun 6, 2013, at 2:14 PM, Silvia Pfeiffer > wrote: > > > On Thu, Jun 6, 2013 at 3:41 PM, Cullen Jennings wrote: > >> > >> I've trying to help you explain and I keep asking for an example but I > don't think we have had a complete example yet. I know you think there is a > complete example so let me try and be more specific so perhaps we can get > to the bottom of the disconnect. > >> > >> Let me try to be specific. > >> > >> Say an application running on Alice's browser want to generate an offer > that says the browser is ready to send and receive 2 streams of video and 1 > stream of audio look like? Imagine that one of the video streams is a > document camera running at high res but low frame rate while the other is > video of the speaker running at a higher frame rate. What exactly does the > SDP passed from the browser to the JS applications look like. I agree the > applications can do whatever it wants to communicate the relevant data to > the far end so I don't care about the signaling protocol or JSON that JS > app can send across the wire. But next question, can the far end start > sending media immediately to the browser? Finally the far end does > something that causes the applications to generate an SDP answer from the > JS applications to Alice's browser. I want and example of that that looks > like in the cases where the far end a) accepted all the video streams and > b) rejected some but not all of the > video streams. > >> > >> If we can get an simple example like this sorted out, then perhaps it > will be easy to extrapolate to the ones in the say the use case document > and start looking at things like number of round trips and audio clipping. > > > > > > Wouldn't that simply be multiplexed over one PeerConnection in the > > browser using addStream()? > > Yes, that makes sense. I was assuming all the streams would be on the same > PeerConnection > > > I have an application like that working. I > > can dig out the SDP packets that the browser sends in this case, if > > you are interested. > > Uh, not sure that would help much. The issues is that current standards > don't say what the browsers should do and we have two proposal on how the > browsers could implement this. One proposal from Mozilla and one proposal > from Google. I don't think either browser implements exactly the > corresponding proposal yet but they are trying to figure out what to do. We > need to agree on roughly what is passed across the JS API such that the > browser know how to set up the media stack to send and receive the > appropriate RTP that is desired by the JS application. > > > > > > Regards, > > Silvia. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d042ef48d9a83dc04df592ad6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    From Cullen: "We need to agree on roughly what is pa= ssed across the JS API such that the browser know how to set up the media s= tack to send and receive the appropriate RTP that is desired by the JS appl= ication"


    I think this hits the n= ail on the head. =C2=A0Generally, we need to decide what the JS API is to a= llow the JS app to control what is sent and received. =C2=A0Specifically fo= r NoPlan, we need a JS API that does not rely on encoding multiple sources = in SDP and doesn't require extra SDP exchanges to add/remove sources.

    I'm glad y= ou asked for such an API, because I was interested in working on one. =C2= =A0So, I just sent an email with a proposed JS API, and Emil will be updati= ng the draft RFC to incorporate it.

    To be clear, Google is in full support of Plan B, and wan= ts to see the Plan A vs. Plan B decision resolved. =C2=A0But if Plan A vs. Plan B cannot be decide= d, then we support NoPlan with this JS API as a backup plan, since Plan B c= ould be implemented on top of NoPlan within JS (and so could Plan A). =C2= =A0


    On Fri,= Jun 7, 2013 at 10:43 PM, Cullen Jennings <fluffy@iii.ca> wrote:=

    On Jun 6, 2013, at 2:14 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

    > On Thu, Jun 6, 2013 at 3:41 PM, Cullen Jennings <fluffy@iii.ca> wrote:
    >>
    >> I've trying to help you explain and I keep asking for an examp= le but I don't think we have had a complete example yet. I know you thi= nk there is a complete example so let me try and be more specific so perhap= s we can get to the bottom of the disconnect.
    >>
    >> Let me try to be specific.
    >>
    >> Say an application running on Alice's browser want to generate= an offer that says the browser is ready to send and receive 2 streams of v= ideo and 1 stream of audio look like? Imagine that one of the video streams= is a document camera running at high res but low frame rate while the othe= r is video of the speaker running at a higher frame rate. =C2=A0What exactl= y does the SDP passed from the browser to the JS applications look like. = =C2=A0I agree the applications can do whatever it wants to communicate the = relevant data to the far end so I don't care about =C2=A0the signaling = protocol or JSON =C2=A0that JS app can send across the wire. But next quest= ion, can the far end start sending media immediately to the browser? Finall= y the far end does something that causes the applications to generate an SD= P answer from the JS applications to Alice's browser. I want and exampl= e of that that looks like in the cases where the far end a) accepted all th= e video streams and b) rejected some but not all of the
    =C2=A0 video streams.
    >>
    >> If we can get an simple example like this sorted out, then perhaps= it will be easy to extrapolate to the ones in the say the use case documen= t and start looking at things like number of round trips and audio clipping= .
    >
    >
    > Wouldn't that simply be multiplexed over one PeerConnection in the=
    > browser using addStream()?

    Yes, that makes sense. I was assuming all the streams would be on the= same PeerConnection

    > I have an application like that working. I
    > can dig out the SDP packets that the browser sends in this case, if > you are interested.

    Uh, not sure that would help much. The issues is that current standar= ds don't say what the browsers should do and we have two proposal on ho= w the browsers could implement this. One proposal from Mozilla and one prop= osal from Google. I don't think either browser implements exactly the c= orresponding proposal yet but they are trying to figure out what to do. We = need to agree on roughly what is passed across the JS API such that the bro= wser know how to set up the media stack to send and receive the appropriate= RTP that is desired by the JS application.


    >
    > Regards,
    > Silvia.

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

    --f46d042ef48d9a83dc04df592ad6-- From emil@sip-communicator.org Mon Jun 17 06:40:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEEC21F9BAC for ; Mon, 17 Jun 2013 06:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCuLH7GdIEUW for ; Mon, 17 Jun 2013 06:40:17 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5841821F9BA5 for ; Mon, 17 Jun 2013 06:40:17 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hj3so2303326wib.10 for ; Mon, 17 Jun 2013 06:40:16 -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 :subject:content-type:content-transfer-encoding:x-gm-message-state; bh=0DmD0DfhTiysaebyoxcsGDHjik7SExVPGaGgv2hfOPo=; b=BVmc+/2aT/nyFbts1iqeE3lxvE0QI7Yyk92xacceGj0WzvoXT0jDobJJZjrrJQ8X+f CRa+R/DJodKFqCrO4LaS3gOPr/IAkQaGgXCEwAG+rUNhlT0BZDcWd8xq8Vi3mkqAbfHq lGbEtjZ7v1JBsnZUqCUqKiDuBL2UhR3MsAxsAivSUE2Z06FiNLnjXaPO6ui23buSIdLm mrUY8/R33mfSW7M1hBoWXOUcVanqkOVujLsWuE83X6B3yiXhsXTKd2eo3aNdABL1bPMr bBQG8StxO+T3Z3V008vGHA5WQlodHAe01uVSjq6Iw9Odt5hnxGdmBTufWN8dOeFfZfMN p81Q== X-Received: by 10.180.189.68 with SMTP id gg4mr4876646wic.27.1371476416483; Mon, 17 Jun 2013 06:40:16 -0700 (PDT) Received: from camionet.local ([2a01:e35:2e2c:f600:6d77:1ca:9e19:c6f4]) by mx.google.com with ESMTPSA id cw8sm22153150wib.7.2013.06.17.06.40.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Jun 2013 06:40:15 -0700 (PDT) Message-ID: <51BF11BD.60708@jitsi.org> Date: Mon, 17 Jun 2013 15:40:13 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnx66Q7AWKHS/NF6YTL7rw7lUeMY57qadMTt9IyAT/lJL3fi3//Hdr8N+267nzwrMp/4gmB Subject: [rtcweb] No Plan 01 - Now with an 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: Mon, 17 Jun 2013 13:40:18 -0000 Hey all, As Peter already mentioned, we have just updated No Plan. The most substantial change is that the draft now contains a sample API. Hopefully this would make things clearer for everyone: Html: http://tools.ietf.org/html/draft-ivov-rtcweb-noplan-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-ivov-rtcweb-noplan-01 As usual, comments are welcome! Cheers, Emil, Peter, Enrico -- https://jitsi.org From prvs=4880f0f092=stefan.lk.hakansson@ericsson.com Mon Jun 17 06:58:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB98621F9BF6 for ; Mon, 17 Jun 2013 06:58:47 -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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eb2+b7XYkO4 for ; Mon, 17 Jun 2013 06:58:41 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 17FC421F9BB8 for ; Mon, 17 Jun 2013 06:58:38 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-3f-51bf160d41a0 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 3F.11.09795.D061FB15; Mon, 17 Jun 2013 15:58:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Mon, 17 Jun 2013 15:58:36 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Peter Thatcher Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) Thread-Index: AQHOa1pIfKQNX7+x70mEbzKV/FqHgg== Date: Mon, 17 Jun 2013 13:58:36 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2FC071@ESESSMB209.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+JvrS6v2P5Ag7ZVOhbXlr9mtVj7r53d gcljwaZSjyVLfjIFMEVx2yQllpQFZ6bn6dslcGf0bVvIUrAksuL/y7NMDYw7XboYOTkkBEwk 7m97ywZhi0lcuLceyObiEBI4zCjR1fGaEcJZxCgxc1EHI0gVm0CgxNZ9C8A6RAQ0JSZPbmYF sZmB7AnLdgHFOTiEBfIlJjwLBzFFBAokDu1khKjWk+i9MhvMZhFQlWh/MY8dxOYV8JWYuLib CcQWEgiQWDtpDlgNI9A930+tYYKYLi5x68l8Jog7BSSW7DnPDGGLSrx8/I8VwlaU2Hm2nRmi Xk/ixtQpbBC2tsSyha+ZIXYJSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsY2XMTM3PSy803 MQIj4eCW3wY7GDfdFzvEKM3BoiTO++nUrkAhgfTEktTs1NSC1KL4otKc1OJDjEwcnCCCS6qB Ufa8zalZ6sGN3fPW3zi7WeOo0NvKVqZL/otv9LrOa4hccfZ1iYo9i0Ke4dJ1/3aoxmtI/9og nlKuf5Or9Y4rL/uuz3JzNA48O+ky74R71cIagYtTwxoSHOZWFZ//NVdj5ZHKBSeaRa0flnqx J3heuTY3w+Jvuu9syW9s+2ImxUtnvgvviIn0V2Ipzkg01GIuKk4EAE/fdAlXAgAA Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 13:58:47 -0000 A couple of questions (to help me understand) in-line //Stefan=0A= =0A= On 2013-06-17 14:57, Peter Thatcher wrote:=0A= > Google is in full support of "Plan B" for encoding multiple media=0A= > sources in SDP, and would like to see the Plan A vs. Plan B decision=0A= > resolved soon. Recently, though, a third option, called "NoPlan" has=0A= > been proposed, but it lacked the details of what a JS API would look=0A= > like for NoPlan. Cullen asked to see such an API proposal, and so I=0A= > have worked with Emil to make one. He will be adding it to the NoPlan=0A= > draft, but I will also include it in this email.=0A= >=0A= > Again, Google is in full support of "Plan B". But if Plan A vs. Plan B= =0A= > cannot be decided, then we support NoPlan with the following additions=0A= > to the WebRTC JS API as an option that allows implementing either Plan A= =0A= > or Plan B in Javascript. And even if Plan A vs. Plan B is resolved,=0A= > these API additions would still be a big improvement for those WebRTC=0A= > applications that don't use SDP for signalling.=0A= >=0A= > It is a bit long because I have added many comments and examples, but=0A= > the actually additions only include two new methods on PeerConnection=0A= > and a few new dictionaries. So don't be overwhelmed :).=0A= >=0A= >=0A= >=0A= > Intro: This follows the model of createDataChannel, which has a JS=0A= > method on PeerConnection that makes it possible to add data channels=0A= > without going through SDP. Furthermore, just like createDataChannel=0A= > allows 2 ways to handle neogitation (the "I know what I'm doing; Here's= =0A= > what I want to send; Let me signal everything" mode and the "please take= =0A= > care of it for me; send an OPEN message" mode), this also has 2 ways to= =0A= > handle negotiation (the "I know what I'm doing; Here's what I want to=0A= > send; Let me signal everything" mode and the "please take care of it for= =0A= > me; send SDP back and forth" mode).=0A= >=0A= > Following the success of createDataChannel, this allows simple=0A= > applications to Just Work and more advanced applications to easily=0A= > control what they need to. In particular, it's possible to use this API= =0A= > to implement either Plan A or Plan B.=0A= >=0A= > // The following two method are added to RTCPeerConnection=0A= > partial interface RTCPeerConnection {=0A= > // Create a stream that is used to send a source stream.=0A= > // The MediaSendStream.description can be used for signalling.=0A= > // No media is sent until addStream(MediaSendStream) is called.=0A= > LocalMediaStream createLocalStream(MediaStream sourceStream);=0A= >=0A= > // Create a stream that is used to receive media from the remote side,= =0A= > // given the parameters signalled from MedaiSendStream.description.=0A= > MediaStream createRemoteStream(MediaStreamDescription description);=0A= > }=0A= =0A= what would happen if the application adds or removes a track from =0A= sourceStream (I'm thinking on how what would impact the created =0A= LocalMediaStream and the MediaStream at the remote end)?=0A= =0A= >=0A= >=0A= > interface LocalMediaStream implements MediaStream {=0A= > // This can be changed at any time, but especially before calling=0A= > // PeerConnection.addStream=0A= > attribute MediaStreamDescription description;=0A= > }=0A= >=0A= >=0A= > // Represents the parameters used to either send or receive a stream=0A= > // over a PeerConnection.=0A= > dictionary MediaStreamDescription {=0A= > MediaStreamTrackDescription[] tracks;=0A= > }=0A= >=0A= >=0A= > // Represents the parameters used to either send or receive a track over= =0A= > // a PeerConnection. A track has many "flows", which can be grouped=0A= > // together.=0A= > dictionary MediaStreamTrackDescription {=0A= > // Same as the MediaStreamTrack.id=0A= > DOMString id;=0A= >=0A= > // Same as the MediaStreamTrack.kind=0A= > DOMString kind;=0A= >=0A= > // A track can have many "flows", such as for Simulcast, FEC, etc.=0A= > // And they can be grouped in arbitrary ways.=0A= > MediaFlowDescription[] flows;=0A= > MediaFlowGroup[] flowGroups;=0A= > }=0A= >=0A= > // Represents the parameters used to either send or receive a "flow"=0A= > // over a PeerConnection. A "flow" is a media that arrives with a=0A= > // single, unique SSRC. One to many flows together make up the media=0A= > // for a track. For example, there may be Simulcast, FEC, and RTX=0A= > // flows.=0A= > dictionay MediaFlowDescription {=0A= > // The "flow id" must be unique to the track, but need not be unique= =0A= > // outside of the track (two tracks could both have a flow with the=0A= > // same flow ID).=0A= > DOMString id;=0A= >=0A= > // Each flow can go over its own transport. If the JS sets this to a= =0A= > // transportId that doesn't have a transport setup already, the=0A= > // browser will use SDP negotiation to setup a transport to back that= =0A= > // transportId. If This is set to an MID in the SDP, then that MID's= =0A= > // transport is used.=0A= > DOMString transportId;=0A= =0A= Where from do you get transportId (e.g. if you want to re-use one)?=0A= =0A= >=0A= > // The SSRC used to send the flow.=0A= > unsigned int ssrc;=0A= >=0A= > // When used as receive parameters, this indicates the possible list= =0A= > // of codecs that might come in for this flow. For exmample, a given= =0A= > // receive flow could be setup to receive any of OPUS, ISAC, or PCMU.= =0A= > // When used as send parameters, this indicates that the first codec= =0A= > // should be used, but the browser can use send other codecs if it=0A= > // needs to because of either bandwidth or CPU constraints.=0A= > MediaCodecDescription[] codecs;=0A= > }=0A= >=0A= >=0A= > dictionary MediaFlowGroup {=0A= > DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc=0A= > DOMString[] flowids;=0A= > }=0A= >=0A= > dictionary MediaCodecDescription {=0A= > unsigned byte payloadType;=0A= > DOMString name;=0A= > unsigned int? clockRate;=0A= > unsigned int? bitRate;=0A= > // A grab bag of other fmtp that will need to be further defined.=0A= > MediaCodecParam[] params;=0A= > }=0A= >=0A= > dictionary MediaCodecParam {=0A= > DOMString key;=0A= > DOMString value;=0A= > }=0A= >=0A= >=0A= > Notes:=0A= >=0A= > - When LocalMediaStreams are added using addStream, onnegotiatedneeded=0A= > is not called, and those streams are never reflected in future SDP=0A= > exchanges. Indeed, it would be impossible to put them in the SDP=0A= > without first resolving if that would be Plan A SDP or Plan B SDP.=0A= >=0A= > - Just like piles of attributes would need to be defined for Plan A and= =0A= > for Plan B, similar attributes would need to be defined here (Luckily,=0A= > much work has already been done figuring out what those parameters are = :).=0A= >=0A= >=0A= > Pros:=0A= >=0A= > - Either Plan A or Plan B or could be implemented in Javascript using=0A= > this API=0A= > - It exposes all the same functionality to the Javascript as SDP, but in= =0A= > a much nicer format that is much easier to work with.=0A= > - Any other signalling mechanism, such as Jingle or CLUE could be=0A= > implemented using this API.=0A= > - There is almost no risk of signalling glare.=0A= > - Debugging errors with misconfigured descriptions should be much easier= =0A= > with this than with large SDP blobs.=0A= >=0A= >=0A= > Cons:=0A= >=0A= > - Now there are two slightly different ways to add streams: by creating= =0A= > a LocalMediaStream first, and not. This is, however, analogous to=0A= > setting "negotiated: true" in createDataChannel. On way is "Just Work",= =0A= > and the other is more advanced control.=0A= >=0A= > - All the options in MediaCodecDescription are a bit complicated.=0A= > Really, this is only necessary because Plan A requires being able to=0A= > specify codec parameters per SSRC, and set each flow on different=0A= > transports. If we did not have this requirement, we could simplify.=0A= >=0A= >=0A= > Example Usage:=0A= >=0A= > // Imagine I have MyApp, handles creating a PeerConnection,=0A= > // signalling, and rendering streams. This is how the new API could be= =0A= > // used.=0A= > var peerConnection =3D MyApp.createPeerConnection();=0A= >=0A= > // On sender side:=0A= > var stream =3D MyApp.getMediaStream();=0A= > var localStream =3D peerConnection.createSendStream(stream);=0A= > sendStream.description =3D MyApp.modifyStream(localStream.description)=0A= =0A= Should it say "localStream.description"?=0A= =0A= > MyApp.signalAddStream(localStream.description, function(response)) {=0A= > if (!response.rejected) {=0A= > // Media will not be sent.=0A= > peerConnection.addStream(localStream);=0A= > }=0A= > }=0A= >=0A= > // On receiver side:=0A= > MyApp.onAddStreamSignalled =3D function(streamDescription) {=0A= > var stream =3D peerConnection.createReceiveStream(streamDescription);= =0A= > MyApp.renderStream(stream);=0A= > }=0A= >=0A= >=0A= > // In this exchange, the MediaStreamDescription signalled from the=0A= > // sender to the receiver may have looked something like this:=0A= >=0A= > {=0A= > tracks: [=0A= > {=0A= > id: "audio1",=0A= > kind: "audio",=0A= > flows: [=0A= > {=0A= > id: "main",=0A= > transportId: "transport1",=0A= > ssrc: 1111,=0A= > codecs: [=0A= > {=0A= > payloadType: 111,=0A= > name: "opus",=0A= > // ... more codec details=0A= > },=0A= > {=0A= > payloadType: 112,=0A= > name: "pcmu",=0A= > // ... more codec details=0A= > }]=0A= > }]=0A= > },=0A= > {=0A= > id: "video1",=0A= > kind: "video",=0A= > flows: [=0A= > {=0A= > id: "sim0",=0A= > transportId: "transport2",=0A= > ssrc: 2222,=0A= > codecs: [=0A= > {=0A= > payloadType: 122,=0A= > name: "vp8"=0A= > // ... more codec details=0A= > }]=0A= > },=0A= > {=0A= > id: "sim1",=0A= > transportId: "transport2",=0A= > ssrc: 2223,=0A= > codecs: [=0A= > {=0A= > payloadType: 122,=0A= > name: "vp8",=0A= > // ... more codec details=0A= > }]=0A= > },=0A= > {=0A= > id: "sim2",=0A= > transportId: "transport2",=0A= > ssrc: 2224,=0A= > codecs: [=0A= > {=0A= > payloadType: 122,=0A= > name: "vp8",=0A= > // ... more codec details=0A= > }]=0A= > },=0A= >=0A= > {=0A= > id: "sim0fec",=0A= > transportId: "transport2",=0A= > ssrc: 2225,=0A= > codecs: [=0A= > {=0A= > payloadType: 122,=0A= > name: "vp8",=0A= > // ...=0A= > }]=0A= > }],=0A= > flowGroups: [=0A= > {=0A= > semantics: "SIM",=0A= > ssrcs: [2222, 2223, 2224]=0A= > },=0A= > {=0A= > semantics: "FEC",=0A= > ssrcs: [2222, 2225]=0A= > }]=0A= > }]=0A= > }=0A= >=0A= >=0A= > Constructive feedback is welcome :).=0A= =0A= From pthatcher@google.com Mon Jun 17 08:14:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F97321F9CA6 for ; Mon, 17 Jun 2013 08:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXt1cnqiR3rs for ; Mon, 17 Jun 2013 08:14:12 -0700 (PDT) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB3521F9C32 for ; Mon, 17 Jun 2013 08:14:09 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x11so2898925pdj.15 for ; Mon, 17 Jun 2013 08:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=i94b+BdKo6ZZGIu3lomh3sOZnnEJuFLeXydc5nUdL5s=; b=bRbsw31Pw0lI/J8ZK7Q3bPa5BHV/BMQYHktpFjpMhiVS4F/EC3Ee0zO8ncprsHTnyX VYs5VhZH8KouUoK6dhNvgMB/FDuDm05w4GzCMwYymxfIMfjQB4orbjnN8qeeeI3uTFvn +onoNijuSfu0yOWRKm1EVdAQiKty0IIQ1moKEnGijjisgDloYOadIDBZWFrvpULjq+bF 0jiFlsEcm8OTg4u7vDQxGWwj3VWKJOy0GhstVOkm7TLYitYzvC15Mpzj/COmGoTtsW9p 8/pDBN871GhXccbHY5zblAJQ0C4CpYIvRfCqY/OTxJF5Ympm0VLzB1LWc3LmbrZBUflv bEOw== 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=i94b+BdKo6ZZGIu3lomh3sOZnnEJuFLeXydc5nUdL5s=; b=ClGExinjOUGstuKkVbUnhYkEFyaZEjeL4rI9Ll22JAM1Yvab8oScQfWpewyN1sIzzR glkXbq9WrTmWScrqNrjpXmeklU/Dk6ajC4PS5I4R9yoMFXF/BfgX3y2sUZVVMfHicBGk uat6ebwuUWa/WJCWJlsDkxLa5aKYKXLOe9CKRtkOC/sDyVihKhIM9LhXmE6rAKxyOvV9 KMZ16+r57n6VdDjMbzjlYshOKsT2jXsMb/xRmKR6cgrpth+ZjRctN9jFENPDvhB4qDoh hUD5Y2y1PMNNLKbNIB61WZ2PIsEghFohjSq6d0+2E6tt//SSPYiigB+/5NyrqXT6ErqH bzxA== X-Received: by 10.68.19.72 with SMTP id c8mr6612530pbe.219.1371482049732; Mon, 17 Jun 2013 08:14:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Mon, 17 Jun 2013 08:13:29 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2FC071@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C2FC071@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Mon, 17 Jun 2013 08:13:29 -0700 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary=bcaec53af13a63f7d404df5b0cd5 X-Gm-Message-State: ALoCoQlvqfAmfvS3DsRPX5QLfIijpO576sL5+jsAgEQmpD/UHJ5sQ6NfWmvNcdnZujqSj0OAy2CUrSFvHlk6d+Ahf8r7km+q6CvWHmMopcaiLCga2m7PLzAMkI9V8t4quaOJsPSa3jsAk/as2lmXJgo5izLKqQJRYsmXSghsrHmv3cfTsKKcMlqeUIz9z+ZohGO63kP7OpuM Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 15:14:19 -0000 --bcaec53af13a63f7d404df5b0cd5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Answers: On Mon, Jun 17, 2013 at 6:58 AM, Stefan H=C3=A5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > A couple of questions (to help me understand) in-line //Stefan > > On 2013-06-17 14:57, Peter Thatcher wrote: > > Google is in full support of "Plan B" for encoding multiple media > > sources in SDP, and would like to see the Plan A vs. Plan B decision > > resolved soon. Recently, though, a third option, called "NoPlan" has > > been proposed, but it lacked the details of what a JS API would look > > like for NoPlan. Cullen asked to see such an API proposal, and so I > > have worked with Emil to make one. He will be adding it to the NoPlan > > draft, but I will also include it in this email. > > > > Again, Google is in full support of "Plan B". But if Plan A vs. Plan B > > cannot be decided, then we support NoPlan with the following additions > > to the WebRTC JS API as an option that allows implementing either Plan = A > > or Plan B in Javascript. And even if Plan A vs. Plan B is resolved, > > these API additions would still be a big improvement for those WebRTC > > applications that don't use SDP for signalling. > > > > It is a bit long because I have added many comments and examples, but > > the actually additions only include two new methods on PeerConnection > > and a few new dictionaries. So don't be overwhelmed :). > > > > > > > > Intro: This follows the model of createDataChannel, which has a JS > > method on PeerConnection that makes it possible to add data channels > > without going through SDP. Furthermore, just like createDataChannel > > allows 2 ways to handle neogitation (the "I know what I'm doing; Here'= s > > what I want to send; Let me signal everything" mode and the "please tak= e > > care of it for me; send an OPEN message" mode), this also has 2 ways t= o > > handle negotiation (the "I know what I'm doing; Here's what I want to > > send; Let me signal everything" mode and the "please take care of it fo= r > > me; send SDP back and forth" mode). > > > > Following the success of createDataChannel, this allows simple > > applications to Just Work and more advanced applications to easily > > control what they need to. In particular, it's possible to use this AP= I > > to implement either Plan A or Plan B. > > > > // The following two method are added to RTCPeerConnection > > partial interface RTCPeerConnection { > > // Create a stream that is used to send a source stream. > > // The MediaSendStream.description can be used for signalling. > > // No media is sent until addStream(MediaSendStream) is called. > > LocalMediaStream createLocalStream(MediaStream sourceStream); > > > > // Create a stream that is used to receive media from the remote side= , > > // given the parameters signalled from MedaiSendStream.description. > > MediaStream createRemoteStream(MediaStreamDescription description); > > } > > what would happen if the application adds or removes a track from > sourceStream (I'm thinking on how what would impact the created > LocalMediaStream and the MediaStream at the remote end)? > > Good question. I'd have to think about it some more, but off the bat, I'd say that on the sender side, adding or removing tracks from the source MediaStream would have no effect on what is sent. In other words, it's as if the source MediaStream were cloned when createLocalStream was called. If you want to modify the LocalStream, you have to go through the .description. On the receiver side, it would look like any other received MediaStream: if you remove the track, it just doesn't play out anymore. > > > > > > interface LocalMediaStream implements MediaStream { > > // This can be changed at any time, but especially before calling > > // PeerConnection.addStream > > attribute MediaStreamDescription description; > > } > > > > > > // Represents the parameters used to either send or receive a stream > > // over a PeerConnection. > > dictionary MediaStreamDescription { > > MediaStreamTrackDescription[] tracks; > > } > > > > > > // Represents the parameters used to either send or receive a track ove= r > > // a PeerConnection. A track has many "flows", which can be grouped > > // together. > > dictionary MediaStreamTrackDescription { > > // Same as the MediaStreamTrack.id > > DOMString id; > > > > // Same as the MediaStreamTrack.kind > > DOMString kind; > > > > // A track can have many "flows", such as for Simulcast, FEC, etc. > > // And they can be grouped in arbitrary ways. > > MediaFlowDescription[] flows; > > MediaFlowGroup[] flowGroups; > > } > > > > // Represents the parameters used to either send or receive a "flow" > > // over a PeerConnection. A "flow" is a media that arrives with a > > // single, unique SSRC. One to many flows together make up the media > > // for a track. For example, there may be Simulcast, FEC, and RTX > > // flows. > > dictionay MediaFlowDescription { > > // The "flow id" must be unique to the track, but need not be unique > > // outside of the track (two tracks could both have a flow with the > > // same flow ID). > > DOMString id; > > > > // Each flow can go over its own transport. If the JS sets this to = a > > // transportId that doesn't have a transport setup already, the > > // browser will use SDP negotiation to setup a transport to back tha= t > > // transportId. If This is set to an MID in the SDP, then that MID'= s > > // transport is used. > > DOMString transportId; > > Where from do you get transportId (e.g. if you want to re-use one)? > First, the browser would fill it in via createLocalStream. So in almost all cases, the JS would not need to set it. In very advanced applications that want to do tricky things with transports, then the value should be the MID for that transport found in the SDP, as it says in the comment. > > > > > // The SSRC used to send the flow. > > unsigned int ssrc; > > > > // When used as receive parameters, this indicates the possible list > > // of codecs that might come in for this flow. For exmample, a give= n > > // receive flow could be setup to receive any of OPUS, ISAC, or PCMU= . > > // When used as send parameters, this indicates that the first codec > > // should be used, but the browser can use send other codecs if it > > // needs to because of either bandwidth or CPU constraints. > > MediaCodecDescription[] codecs; > > } > > > > > > dictionary MediaFlowGroup { > > DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc > > DOMString[] flowids; > > } > > > > dictionary MediaCodecDescription { > > unsigned byte payloadType; > > DOMString name; > > unsigned int? clockRate; > > unsigned int? bitRate; > > // A grab bag of other fmtp that will need to be further defined. > > MediaCodecParam[] params; > > } > > > > dictionary MediaCodecParam { > > DOMString key; > > DOMString value; > > } > > > > > > Notes: > > > > - When LocalMediaStreams are added using addStream, onnegotiatedneeded > > is not called, and those streams are never reflected in future SDP > > exchanges. Indeed, it would be impossible to put them in the SDP > > without first resolving if that would be Plan A SDP or Plan B SDP. > > > > - Just like piles of attributes would need to be defined for Plan A and > > for Plan B, similar attributes would need to be defined here (Luckily, > > much work has already been done figuring out what those parameters ar= e > :). > > > > > > Pros: > > > > - Either Plan A or Plan B or could be implemented in Javascript using > > this API > > - It exposes all the same functionality to the Javascript as SDP, but i= n > > a much nicer format that is much easier to work with. > > - Any other signalling mechanism, such as Jingle or CLUE could be > > implemented using this API. > > - There is almost no risk of signalling glare. > > - Debugging errors with misconfigured descriptions should be much easie= r > > with this than with large SDP blobs. > > > > > > Cons: > > > > - Now there are two slightly different ways to add streams: by creating > > a LocalMediaStream first, and not. This is, however, analogous to > > setting "negotiated: true" in createDataChannel. On way is "Just Work"= , > > and the other is more advanced control. > > > > - All the options in MediaCodecDescription are a bit complicated. > > Really, this is only necessary because Plan A requires being able to > > specify codec parameters per SSRC, and set each flow on different > > transports. If we did not have this requirement, we could simplify. > > > > > > Example Usage: > > > > // Imagine I have MyApp, handles creating a PeerConnection, > > // signalling, and rendering streams. This is how the new API could be > > // used. > > var peerConnection =3D MyApp.createPeerConnection(); > > > > // On sender side: > > var stream =3D MyApp.getMediaStream(); > > var localStream =3D peerConnection.createSendStream(stream); > > sendStream.description =3D MyApp.modifyStream(localStream.description) > > Should it say "localStream.description"? > Yes. There was a last-minute rename and I missed a spot. Anywhere you see "sendStream", it should be "localStream". > > > MyApp.signalAddStream(localStream.description, function(response)) { > > if (!response.rejected) { > > // Media will not be sent. > > peerConnection.addStream(localStream); > > } > > } > > > > // On receiver side: > > MyApp.onAddStreamSignalled =3D function(streamDescription) { > > var stream =3D peerConnection.createReceiveStream(streamDescription)= ; > > MyApp.renderStream(stream); > > } > > > > > > // In this exchange, the MediaStreamDescription signalled from the > > // sender to the receiver may have looked something like this: > > > > { > > tracks: [ > > { > > id: "audio1", > > kind: "audio", > > flows: [ > > { > > id: "main", > > transportId: "transport1", > > ssrc: 1111, > > codecs: [ > > { > > payloadType: 111, > > name: "opus", > > // ... more codec details > > }, > > { > > payloadType: 112, > > name: "pcmu", > > // ... more codec details > > }] > > }] > > }, > > { > > id: "video1", > > kind: "video", > > flows: [ > > { > > id: "sim0", > > transportId: "transport2", > > ssrc: 2222, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8" > > // ... more codec details > > }] > > }, > > { > > id: "sim1", > > transportId: "transport2", > > ssrc: 2223, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... more codec details > > }] > > }, > > { > > id: "sim2", > > transportId: "transport2", > > ssrc: 2224, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... more codec details > > }] > > }, > > > > { > > id: "sim0fec", > > transportId: "transport2", > > ssrc: 2225, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... > > }] > > }], > > flowGroups: [ > > { > > semantics: "SIM", > > ssrcs: [2222, 2223, 2224] > > }, > > { > > semantics: "FEC", > > ssrcs: [2222, 2225] > > }] > > }] > > } > > > > > > Constructive feedback is welcome :). > > --bcaec53af13a63f7d404df5b0cd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Answers:


    On Mon, Jun 17, 2013 at 6:58 AM, Stefan H=C3=A5kansson LK = <stefan.lk.hakansson@ericsson.com> wrote:
    A couple of questions (to help me understand= ) in-line //Stefan

    On 2013-06-17 14:57, Peter Thatcher wrote:
    > Google is in full support of "Plan B" for encoding multiple = media
    > sources in SDP, and would like to see the Plan A vs. Plan B decision > resolved soon. =C2=A0Recently, though, a third option, called "No= Plan" has
    > been proposed, but it lacked the details of what a JS API would look > like for NoPlan. =C2=A0Cullen asked to see such an API proposal, and s= o I
    > have worked with Emil to make one. =C2=A0He will be adding it to the N= oPlan
    > draft, but I will also include it in this email.
    >
    > Again, Google is in full support of "Plan B". =C2=A0But if P= lan A vs. Plan B
    > cannot be decided, then we support NoPlan with the following additions=
    > to the WebRTC JS API as an option that allows implementing either Plan= A
    > or Plan B =C2=A0in Javascript. =C2=A0And even if Plan A vs. Plan B is = resolved,
    > these API additions would still be a big improvement for those WebRTC<= br> > applications that don't use SDP for signalling.
    >
    > It is a bit long because I have added many comments and examples, but<= br> > the actually additions only include two new methods on PeerConnection<= br> > and a few new dictionaries. =C2=A0So don't be overwhelmed :).
    >
    >
    >
    > Intro: This follows the model of createDataChannel, which has a JS
    > method on PeerConnection that makes it possible to add data channels > without going through SDP. =C2=A0Furthermore, just like createDataChan= nel
    > allows 2 ways to handle neogitation (the "I know what I'm doi= ng; =C2=A0Here's
    > what I want to send; Let me signal everything" mode and the "= ;please take
    > care of it for me; =C2=A0send an OPEN message" mode), this also h= as 2 ways to
    > handle negotiation (the "I know what I'm doing; Here's wh= at I want to
    > send; Let me signal everything" mode and the "please take ca= re of it for
    > me; =C2=A0send SDP back and forth" mode).
    >
    > Following the success of createDataChannel, this allows simple
    > applications to Just Work and more advanced applications to easily
    > control what they need to. =C2=A0In particular, it's possible to u= se this API
    > to implement either Plan A or Plan B.
    >
    > // The following two method are added to RTCPeerConnection
    > partial interface RTCPeerConnection {
    > =C2=A0 // Create a stream that is used to send a source stream.
    > =C2=A0 // The MediaSendStream.description can be used for signalling.<= br> > =C2=A0 // No media is sent until addStream(MediaSendStream) is called.=
    > =C2=A0 LocalMediaStream createLocalStream(MediaStream sourceStream); >
    > =C2=A0 // Create a stream that is used to receive media from the remot= e side,
    > =C2=A0 // given the parameters signalled from MedaiSendStream.descript= ion.
    > =C2=A0 MediaStream createRemoteStream(MediaStreamDescription descripti= on);
    > }

    what would happen if the application adds or removes a track fr= om
    sourceStream (I'm thinking on how what would impact the created
    LocalMediaStream and the MediaStream at the remote end)?


    Goo= d question. =C2=A0I'd have to think about it some more, but off the bat= , I'd say that on the sender side, adding or removing tracks from the s= ource MediaStream would have no effect on what is sent. =C2=A0In other word= s, it's as if the source MediaStream were cloned when createLocalStream= was called. =C2=A0If you want to modify the LocalStream, you have to go th= rough the .description. =C2=A0 On the receiver side, it would look like any= other received MediaStream: if you remove the track, it just doesn't p= lay out anymore.

    =C2=A0
    >
    >
    > interface LocalMediaStream implements MediaStream {
    > =C2=A0 =C2=A0// This can be changed at any time, but especially before= calling
    > =C2=A0 =C2=A0// PeerConnection.addStream
    > =C2=A0 =C2=A0attribute MediaStreamDescription description;
    > }
    >
    >
    > // Represents the parameters used to either send or receive a stream > // over a PeerConnection.
    > dictionary MediaStreamDescription {
    > =C2=A0 =C2=A0MediaStreamTrackDescription[] tracks;
    > }
    >
    >
    > // Represents the parameters used to either send or receive a track ov= er
    > // a PeerConnection. =C2=A0A track has many "flows", which c= an be grouped
    > // together.
    > dictionary MediaStreamTrackDescription {
    > =C2=A0 =C2=A0// Same as the MediaStreamTrack.id
    > =C2=A0 =C2=A0DOMString id;
    >
    > =C2=A0 =C2=A0// Same as the MediaStreamTrack.kind
    > =C2=A0 =C2=A0DOMString kind;
    >
    > =C2=A0 =C2=A0// A track can have many "flows", such as for S= imulcast, FEC, etc.
    > =C2=A0 =C2=A0// And they can be grouped in arbitrary ways.
    > =C2=A0 =C2=A0MediaFlowDescription[] flows;
    > =C2=A0 =C2=A0MediaFlowGroup[] flowGroups;
    > }
    >
    > // Represents the parameters used to either send or receive a "fl= ow"
    > // over a PeerConnection. =C2=A0A "flow" is a media that arr= ives with a
    > // single, unique SSRC. =C2=A0One to many flows together make up the m= edia
    > // for a track. =C2=A0For example, there may be Simulcast, FEC, and RT= X
    > // flows.
    > dictionay MediaFlowDescription {
    > =C2=A0 =C2=A0// The "flow id" must be unique to the track, b= ut need not be unique
    > =C2=A0 =C2=A0// outside of the track (two tracks could both have a flo= w with the
    > =C2=A0 =C2=A0// same flow ID).
    > =C2=A0 =C2=A0DOMString id;
    >
    > =C2=A0 =C2=A0// Each flow can go over its own transport. =C2=A0If the = JS sets this to a
    > =C2=A0 =C2=A0// transportId that doesn't have a transport setup al= ready, the
    > =C2=A0 =C2=A0// browser will use SDP negotiation to setup a transport = to back that
    > =C2=A0 =C2=A0// transportId. =C2=A0If This is set to an MID in the SDP= , then that MID's
    > =C2=A0 =C2=A0// transport is used.
    > =C2=A0 =C2=A0DOMString transportId;

    Where from do you get transportId (e.g. if you want to re-use o= ne)?

    First, the browser would fill it i= n via createLocalStream. =C2=A0So in almost all cases, the JS would not nee= d to set it. =C2=A0In very advanced applications that want to do tricky thi= ngs with transports, then the value should be the MID for that transport fo= und in the SDP, as it says in the comment.=C2=A0
    =C2=A0

    >
    > =C2=A0 =C2=A0// The SSRC used to send the flow.
    > =C2=A0 =C2=A0unsigned int ssrc;
    >
    > =C2=A0 =C2=A0// When used as receive parameters, this indicates the po= ssible list
    > =C2=A0 =C2=A0// of codecs that might come in for this flow. =C2=A0For = exmample, a given
    > =C2=A0 =C2=A0// receive flow could be setup to receive any of OPUS, IS= AC, or PCMU.
    > =C2=A0 =C2=A0// When used as send parameters, this indicates that the = first codec
    > =C2=A0 =C2=A0// should be used, but the browser can use send other cod= ecs if it
    > =C2=A0 =C2=A0// needs to because of either bandwidth or CPU constraint= s.
    > =C2=A0 =C2=A0MediaCodecDescription[] codecs;
    > }
    >
    >
    > dictionary MediaFlowGroup {
    > =C2=A0 =C2=A0DOMString type; =C2=A0// "SIM" for Simulcast, &= quot;FEC" for FEC, etc
    > =C2=A0 =C2=A0DOMString[] flowids;
    > }
    >
    > dictionary MediaCodecDescription {
    > =C2=A0 =C2=A0unsigned byte payloadType;
    > =C2=A0 =C2=A0DOMString name;
    > =C2=A0 =C2=A0unsigned int? clockRate;
    > =C2=A0 =C2=A0unsigned int? bitRate;
    > =C2=A0 =C2=A0// A grab bag of other fmtp that will need to be further = defined.
    > =C2=A0 =C2=A0MediaCodecParam[] params;
    > }
    >
    > dictionary MediaCodecParam {
    > =C2=A0 =C2=A0DOMString key;
    > =C2=A0 =C2=A0DOMString value;
    > }
    >
    >
    > Notes:
    >
    > - When LocalMediaStreams are added using addStream, onnegotiatedneeded=
    > is not called, and those streams are never reflected in future SDP
    > exchanges. =C2=A0Indeed, it would be impossible to put them in the SDP=
    > without first resolving if that would be Plan A SDP or Plan B SDP.
    >
    > - Just like piles of attributes would need to be defined for Plan A an= d
    > for Plan B, similar attributes would need to be defined here (Luckily,=
    > =C2=A0 much work has already been done figuring out what those paramet= ers are :).
    >
    >
    > Pros:
    >
    > - Either Plan A or Plan B or could be implemented in Javascript using<= br> > this API
    > - It exposes all the same functionality to the Javascript as SDP, but = in
    > a much nicer format that is much easier to work with.
    > - Any other signalling mechanism, such as Jingle or CLUE could be
    > implemented using this API.
    > - There is almost no risk of signalling glare.
    > - Debugging errors with misconfigured descriptions should be much easi= er
    > with this than with large SDP blobs.
    >
    >
    > Cons:
    >
    > - Now there are two slightly different ways to add streams: by creatin= g
    > a LocalMediaStream first, and not. =C2=A0This is, however, analogous t= o
    > setting "negotiated: true" in createDataChannel. =C2=A0On wa= y is "Just Work",
    > and the other is more advanced control.
    >
    > - All the options in MediaCodecDescription are a bit complicated.
    > =C2=A0 Really, this is only necessary because Plan A requires being ab= le to
    > specify codec parameters per SSRC, and set each flow on different
    > transports. =C2=A0If we did not have this requirement, we could simpli= fy.
    >
    >
    > Example Usage:
    >
    > // Imagine I have MyApp, handles creating a PeerConnection,
    > // signalling, and rendering streams. =C2=A0This is how the new API co= uld be
    > // used.
    > var peerConnection =3D MyApp.createPeerConnection();
    >
    > // On sender side:
    > var stream =3D MyApp.getMediaStream();
    > var localStream =3D peerConnection.createSendStream(stream);
    > sendStream.description =3D MyApp.modifyStream(localStream.description)=

    Should it say "localStream.description"?

    Yes. There was a last-minute rename and I missed a = spot. =C2=A0Anywhere you see "sendStream", it should be "loc= alStream".
    =C2=A0

    > MyApp.signalAddStream(localStream.description, function(response)) { > =C2=A0 =C2=A0if (!response.rejected) {
    > =C2=A0 =C2=A0 =C2=A0// Media will not be sent.
    > =C2=A0 =C2=A0 =C2=A0peerConnection.addStream(localStream);
    > =C2=A0 =C2=A0}
    > }
    >
    > // On receiver side:
    > MyApp.onAddStreamSignalled =3D function(streamDescription) {
    > =C2=A0 =C2=A0var stream =3D peerConnection.createReceiveStream(streamD= escription);
    > =C2=A0 =C2=A0MyApp.renderStream(stream);
    > }
    >
    >
    > // In this exchange, the MediaStreamDescription signalled from the
    > // sender to the receiver may have looked something like this:
    >
    > {
    > =C2=A0 =C2=A0tracks: [
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0id: "audio1",
    > =C2=A0 =C2=A0 =C2=A0kind: "audio",
    > =C2=A0 =C2=A0 =C2=A0flows: [
    > =C2=A0 =C2=A0 =C2=A0{
    > id: "main",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0transportId: "transport1",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0ssrc: 1111,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0codecs: [
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 111,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "opus",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0},
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 112,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "pcmu",
    > // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0}]
    > =C2=A0 =C2=A0 }]
    > =C2=A0 },
    > =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0id: "video1",
    > =C2=A0 =C2=A0 =C2=A0kind: "video",
    > =C2=A0 =C2=A0 =C2=A0flows: [
    > =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0id: "sim0",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0ssrc: 2222,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0codecs: [
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "vp8"
    > // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0}]
    > =C2=A0 =C2=A0 },
    > =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 id: "sim1",
    > =C2=A0 =C2=A0 =C2=A0 transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0 ssrc: 2223,
    > =C2=A0 =C2=A0 =C2=A0 codecs: [
    > =C2=A0 =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 name: "vp8",
    > // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 }]
    > =C2=A0 =C2=A0 },
    > =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 id: "sim2",
    > =C2=A0 =C2=A0 =C2=A0 transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0 ssrc: 2224,
    > =C2=A0 =C2=A0 =C2=A0 codecs: [
    > =C2=A0 =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 name: "vp8",
    > // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 }]
    > =C2=A0 =C2=A0 },
    >
    > =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 id: "sim0fec",
    > =C2=A0 =C2=A0 =C2=A0 transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0 ssrc: 2225,
    > =C2=A0 =C2=A0 =C2=A0 codecs: [
    > =C2=A0 =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 name: "vp8",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ...
    > =C2=A0 =C2=A0 =C2=A0 }]
    > =C2=A0 =C2=A0 }],
    > =C2=A0 =C2=A0 flowGroups: [
    > =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 semantics: "SIM",
    > =C2=A0 =C2=A0 =C2=A0 ssrcs: [2222, 2223, 2224]
    > =C2=A0 =C2=A0 },
    > =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 semantics: "FEC",
    > =C2=A0 =C2=A0 =C2=A0 ssrcs: [2222, 2225]
    > =C2=A0 =C2=A0 }]
    > =C2=A0 }]
    > }
    >
    >
    > Constructive feedback is welcome :).


    --bcaec53af13a63f7d404df5b0cd5-- From jim.barnett@genesyslab.com Mon Jun 17 08:22:16 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B88121F9BA0 for ; Mon, 17 Jun 2013 08:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hB9T1GmIS7C for ; Mon, 17 Jun 2013 08:22:10 -0700 (PDT) Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id BB77321F9CA4 for ; Mon, 17 Jun 2013 08:22:07 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.3 [168.75.250.3]) (Using TLS) by service107-us.mimecast.com; Mon, 17 Jun 2013 11:21:53 -0400 Received: from GENSJZMBX01.msg.int.genesyslab.com ([fe80::c80a:d985:3cca:a5e7]) by GENSJZFE01.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 08:21:50 -0700 From: Jim Barnett To: Peter Thatcher , =?utf-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) Thread-Index: AQHOa1pIZXTOQ/GlLUKrYtD/Xog7c5k6eRWA//+MUjA= Date: Mon, 17 Jun 2013 15:21:49 +0000 Message-ID: <57A15FAF9E58F841B2B1651FFE16D28104C918@GENSJZMBX01.msg.int.genesyslab.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C2FC071@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: [108.7.220.231] MIME-Version: 1.0 X-MC-Unique: 113061711215400801 Content-Type: multipart/alternative; boundary="_000_57A15FAF9E58F841B2B1651FFE16D28104C918GENSJZMBX01msgint_" Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 15:22:16 -0000 --_000_57A15FAF9E58F841B2B1651FFE16D28104C918GENSJZMBX01msgint_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 V2hhdCBjYW4geW91IG1vZGlmeSBpbiBhIExvY2FsTWVkaWFTdHJlYW0gYnkgZWRpdGluZyBpdHMg ZGVzY3JpcHRpb24/ICBDYW4geW91IGFkZCBhIHZpZGVvIHRyYWNrIHRvIGl0PyAgVGhhdCB3b3Vs ZCBpbXBseSBjYWxsaW5nIGdVTSwgYW5kIHlvdeKAmWQgIGhhdmUgdG8gdGhyZWFkIGl04oCZcyBz dWNjZXNzIGFuZCBmYWlsdXJlIGNhbGxiYWNrcyB1cCB0byB0aGUgZWRpdGluZyBvcGVyYXRpb24u ICBPciBpcyB0aGUgdHJhY2sgbGlzdCBmaXhlZCwgc28gdGhhdCB5b3UgY2FuIG9ubHkgdHdlYWsg dHJhbnNwb3J0IGluZm8gYnkgZWRpdGluZyB0aGUgTG9jYWxNZWRpYVN0cmVhbeKAmXMgZGVzY3Jp cHRpb24/DQoNCg0KLSAgICAgICAgICBKaW0NCg0KRnJvbTogcnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBldGVyIFRo YXRjaGVyDQpTZW50OiBNb25kYXksIEp1bmUgMTcsIDIwMTMgMTE6MTMgQU0NClRvOiBTdGVmYW4g SMOla2Fuc3NvbiBMSw0KQ2M6IDxydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dl Yl0gUHJvcG9zYWwgZm9yIGEgSlMgQVBJIGZvciBOb1BsYW4gKGFkZGluZyBtdWx0aXBsZSBzb3Vy Y2VzIHdpdGhvdXQgZW5jb2RpbmcgdGhlbSBpbiBTRFApDQoNCkFuc3dlcnM6DQoNCk9uIE1vbiwg SnVuIDE3LCAyMDEzIGF0IDY6NTggQU0sIFN0ZWZhbiBIw6VrYW5zc29uIExLIDxzdGVmYW4ubGsu aGFrYW5zc29uQGVyaWNzc29uLmNvbTxtYWlsdG86c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nv bi5jb20+PiB3cm90ZToNCkEgY291cGxlIG9mIHF1ZXN0aW9ucyAodG8gaGVscCBtZSB1bmRlcnN0 YW5kKSBpbi1saW5lIC8vU3RlZmFuDQoNCk9uIDIwMTMtMDYtMTcgMTQ6NTcsIFBldGVyIFRoYXRj aGVyIHdyb3RlOg0KPiBHb29nbGUgaXMgaW4gZnVsbCBzdXBwb3J0IG9mICJQbGFuIEIiIGZvciBl bmNvZGluZyBtdWx0aXBsZSBtZWRpYQ0KPiBzb3VyY2VzIGluIFNEUCwgYW5kIHdvdWxkIGxpa2Ug dG8gc2VlIHRoZSBQbGFuIEEgdnMuIFBsYW4gQiBkZWNpc2lvbg0KPiByZXNvbHZlZCBzb29uLiAg UmVjZW50bHksIHRob3VnaCwgYSB0aGlyZCBvcHRpb24sIGNhbGxlZCAiTm9QbGFuIiBoYXMNCj4g YmVlbiBwcm9wb3NlZCwgYnV0IGl0IGxhY2tlZCB0aGUgZGV0YWlscyBvZiB3aGF0IGEgSlMgQVBJ IHdvdWxkIGxvb2sNCj4gbGlrZSBmb3IgTm9QbGFuLiAgQ3VsbGVuIGFza2VkIHRvIHNlZSBzdWNo IGFuIEFQSSBwcm9wb3NhbCwgYW5kIHNvIEkNCj4gaGF2ZSB3b3JrZWQgd2l0aCBFbWlsIHRvIG1h a2Ugb25lLiAgSGUgd2lsbCBiZSBhZGRpbmcgaXQgdG8gdGhlIE5vUGxhbg0KPiBkcmFmdCwgYnV0 IEkgd2lsbCBhbHNvIGluY2x1ZGUgaXQgaW4gdGhpcyBlbWFpbC4NCj4NCj4gQWdhaW4sIEdvb2ds ZSBpcyBpbiBmdWxsIHN1cHBvcnQgb2YgIlBsYW4gQiIuICBCdXQgaWYgUGxhbiBBIHZzLiBQbGFu IEINCj4gY2Fubm90IGJlIGRlY2lkZWQsIHRoZW4gd2Ugc3VwcG9ydCBOb1BsYW4gd2l0aCB0aGUg Zm9sbG93aW5nIGFkZGl0aW9ucw0KPiB0byB0aGUgV2ViUlRDIEpTIEFQSSBhcyBhbiBvcHRpb24g dGhhdCBhbGxvd3MgaW1wbGVtZW50aW5nIGVpdGhlciBQbGFuIEENCj4gb3IgUGxhbiBCICBpbiBK YXZhc2NyaXB0LiAgQW5kIGV2ZW4gaWYgUGxhbiBBIHZzLiBQbGFuIEIgaXMgcmVzb2x2ZWQsDQo+ IHRoZXNlIEFQSSBhZGRpdGlvbnMgd291bGQgc3RpbGwgYmUgYSBiaWcgaW1wcm92ZW1lbnQgZm9y IHRob3NlIFdlYlJUQw0KPiBhcHBsaWNhdGlvbnMgdGhhdCBkb24ndCB1c2UgU0RQIGZvciBzaWdu YWxsaW5nLg0KPg0KPiBJdCBpcyBhIGJpdCBsb25nIGJlY2F1c2UgSSBoYXZlIGFkZGVkIG1hbnkg Y29tbWVudHMgYW5kIGV4YW1wbGVzLCBidXQNCj4gdGhlIGFjdHVhbGx5IGFkZGl0aW9ucyBvbmx5 IGluY2x1ZGUgdHdvIG5ldyBtZXRob2RzIG9uIFBlZXJDb25uZWN0aW9uDQo+IGFuZCBhIGZldyBu ZXcgZGljdGlvbmFyaWVzLiAgU28gZG9uJ3QgYmUgb3ZlcndoZWxtZWQgOikuDQo+DQo+DQo+DQo+ IEludHJvOiBUaGlzIGZvbGxvd3MgdGhlIG1vZGVsIG9mIGNyZWF0ZURhdGFDaGFubmVsLCB3aGlj aCBoYXMgYSBKUw0KPiBtZXRob2Qgb24gUGVlckNvbm5lY3Rpb24gdGhhdCBtYWtlcyBpdCBwb3Nz aWJsZSB0byBhZGQgZGF0YSBjaGFubmVscw0KPiB3aXRob3V0IGdvaW5nIHRocm91Z2ggU0RQLiAg RnVydGhlcm1vcmUsIGp1c3QgbGlrZSBjcmVhdGVEYXRhQ2hhbm5lbA0KPiBhbGxvd3MgMiB3YXlz IHRvIGhhbmRsZSBuZW9naXRhdGlvbiAodGhlICJJIGtub3cgd2hhdCBJJ20gZG9pbmc7ICBIZXJl J3MNCj4gd2hhdCBJIHdhbnQgdG8gc2VuZDsgTGV0IG1lIHNpZ25hbCBldmVyeXRoaW5nIiBtb2Rl IGFuZCB0aGUgInBsZWFzZSB0YWtlDQo+IGNhcmUgb2YgaXQgZm9yIG1lOyAgc2VuZCBhbiBPUEVO IG1lc3NhZ2UiIG1vZGUpLCB0aGlzIGFsc28gaGFzIDIgd2F5cyB0bw0KPiBoYW5kbGUgbmVnb3Rp YXRpb24gKHRoZSAiSSBrbm93IHdoYXQgSSdtIGRvaW5nOyBIZXJlJ3Mgd2hhdCBJIHdhbnQgdG8N Cj4gc2VuZDsgTGV0IG1lIHNpZ25hbCBldmVyeXRoaW5nIiBtb2RlIGFuZCB0aGUgInBsZWFzZSB0 YWtlIGNhcmUgb2YgaXQgZm9yDQo+IG1lOyAgc2VuZCBTRFAgYmFjayBhbmQgZm9ydGgiIG1vZGUp Lg0KPg0KPiBGb2xsb3dpbmcgdGhlIHN1Y2Nlc3Mgb2YgY3JlYXRlRGF0YUNoYW5uZWwsIHRoaXMg YWxsb3dzIHNpbXBsZQ0KPiBhcHBsaWNhdGlvbnMgdG8gSnVzdCBXb3JrIGFuZCBtb3JlIGFkdmFu Y2VkIGFwcGxpY2F0aW9ucyB0byBlYXNpbHkNCj4gY29udHJvbCB3aGF0IHRoZXkgbmVlZCB0by4g IEluIHBhcnRpY3VsYXIsIGl0J3MgcG9zc2libGUgdG8gdXNlIHRoaXMgQVBJDQo+IHRvIGltcGxl bWVudCBlaXRoZXIgUGxhbiBBIG9yIFBsYW4gQi4NCj4NCj4gLy8gVGhlIGZvbGxvd2luZyB0d28g bWV0aG9kIGFyZSBhZGRlZCB0byBSVENQZWVyQ29ubmVjdGlvbg0KPiBwYXJ0aWFsIGludGVyZmFj ZSBSVENQZWVyQ29ubmVjdGlvbiB7DQo+ICAgLy8gQ3JlYXRlIGEgc3RyZWFtIHRoYXQgaXMgdXNl ZCB0byBzZW5kIGEgc291cmNlIHN0cmVhbS4NCj4gICAvLyBUaGUgTWVkaWFTZW5kU3RyZWFtLmRl c2NyaXB0aW9uIGNhbiBiZSB1c2VkIGZvciBzaWduYWxsaW5nLg0KPiAgIC8vIE5vIG1lZGlhIGlz IHNlbnQgdW50aWwgYWRkU3RyZWFtKE1lZGlhU2VuZFN0cmVhbSkgaXMgY2FsbGVkLg0KPiAgIExv Y2FsTWVkaWFTdHJlYW0gY3JlYXRlTG9jYWxTdHJlYW0oTWVkaWFTdHJlYW0gc291cmNlU3RyZWFt KTsNCj4NCj4gICAvLyBDcmVhdGUgYSBzdHJlYW0gdGhhdCBpcyB1c2VkIHRvIHJlY2VpdmUgbWVk aWEgZnJvbSB0aGUgcmVtb3RlIHNpZGUsDQo+ICAgLy8gZ2l2ZW4gdGhlIHBhcmFtZXRlcnMgc2ln bmFsbGVkIGZyb20gTWVkYWlTZW5kU3RyZWFtLmRlc2NyaXB0aW9uLg0KPiAgIE1lZGlhU3RyZWFt IGNyZWF0ZVJlbW90ZVN0cmVhbShNZWRpYVN0cmVhbURlc2NyaXB0aW9uIGRlc2NyaXB0aW9uKTsN Cj4gfQ0Kd2hhdCB3b3VsZCBoYXBwZW4gaWYgdGhlIGFwcGxpY2F0aW9uIGFkZHMgb3IgcmVtb3Zl cyBhIHRyYWNrIGZyb20NCnNvdXJjZVN0cmVhbSAoSSdtIHRoaW5raW5nIG9uIGhvdyB3aGF0IHdv dWxkIGltcGFjdCB0aGUgY3JlYXRlZA0KTG9jYWxNZWRpYVN0cmVhbSBhbmQgdGhlIE1lZGlhU3Ry ZWFtIGF0IHRoZSByZW1vdGUgZW5kKT8NCg0KDQpHb29kIHF1ZXN0aW9uLiAgSSdkIGhhdmUgdG8g dGhpbmsgYWJvdXQgaXQgc29tZSBtb3JlLCBidXQgb2ZmIHRoZSBiYXQsIEknZCBzYXkgdGhhdCBv biB0aGUgc2VuZGVyIHNpZGUsIGFkZGluZyBvciByZW1vdmluZyB0cmFja3MgZnJvbSB0aGUgc291 cmNlIE1lZGlhU3RyZWFtIHdvdWxkIGhhdmUgbm8gZWZmZWN0IG9uIHdoYXQgaXMgc2VudC4gIElu IG90aGVyIHdvcmRzLCBpdCdzIGFzIGlmIHRoZSBzb3VyY2UgTWVkaWFTdHJlYW0gd2VyZSBjbG9u ZWQgd2hlbiBjcmVhdGVMb2NhbFN0cmVhbSB3YXMgY2FsbGVkLiAgSWYgeW91IHdhbnQgdG8gbW9k aWZ5IHRoZSBMb2NhbFN0cmVhbSwgeW91IGhhdmUgdG8gZ28gdGhyb3VnaCB0aGUgLmRlc2NyaXB0 aW9uLiAgIE9uIHRoZSByZWNlaXZlciBzaWRlLCBpdCB3b3VsZCBsb29rIGxpa2UgYW55IG90aGVy IHJlY2VpdmVkIE1lZGlhU3RyZWFtOiBpZiB5b3UgcmVtb3ZlIHRoZSB0cmFjaywgaXQganVzdCBk b2Vzbid0IHBsYXkgb3V0IGFueW1vcmUuDQoNCg0KPg0KPg0KPiBpbnRlcmZhY2UgTG9jYWxNZWRp YVN0cmVhbSBpbXBsZW1lbnRzIE1lZGlhU3RyZWFtIHsNCj4gICAgLy8gVGhpcyBjYW4gYmUgY2hh bmdlZCBhdCBhbnkgdGltZSwgYnV0IGVzcGVjaWFsbHkgYmVmb3JlIGNhbGxpbmcNCj4gICAgLy8g UGVlckNvbm5lY3Rpb24uYWRkU3RyZWFtDQo+ICAgIGF0dHJpYnV0ZSBNZWRpYVN0cmVhbURlc2Ny aXB0aW9uIGRlc2NyaXB0aW9uOw0KPiB9DQo+DQo+DQo+IC8vIFJlcHJlc2VudHMgdGhlIHBhcmFt ZXRlcnMgdXNlZCB0byBlaXRoZXIgc2VuZCBvciByZWNlaXZlIGEgc3RyZWFtDQo+IC8vIG92ZXIg YSBQZWVyQ29ubmVjdGlvbi4NCj4gZGljdGlvbmFyeSBNZWRpYVN0cmVhbURlc2NyaXB0aW9uIHsN Cj4gICAgTWVkaWFTdHJlYW1UcmFja0Rlc2NyaXB0aW9uW10gdHJhY2tzOw0KPiB9DQo+DQo+DQo+ IC8vIFJlcHJlc2VudHMgdGhlIHBhcmFtZXRlcnMgdXNlZCB0byBlaXRoZXIgc2VuZCBvciByZWNl aXZlIGEgdHJhY2sgb3Zlcg0KPiAvLyBhIFBlZXJDb25uZWN0aW9uLiAgQSB0cmFjayBoYXMgbWFu eSAiZmxvd3MiLCB3aGljaCBjYW4gYmUgZ3JvdXBlZA0KPiAvLyB0b2dldGhlci4NCj4gZGljdGlv bmFyeSBNZWRpYVN0cmVhbVRyYWNrRGVzY3JpcHRpb24gew0KPiAgICAvLyBTYW1lIGFzIHRoZSBN ZWRpYVN0cmVhbVRyYWNrLmlkDQo+ICAgIERPTVN0cmluZyBpZDsNCj4NCj4gICAgLy8gU2FtZSBh cyB0aGUgTWVkaWFTdHJlYW1UcmFjay5raW5kDQo+ICAgIERPTVN0cmluZyBraW5kOw0KPg0KPiAg ICAvLyBBIHRyYWNrIGNhbiBoYXZlIG1hbnkgImZsb3dzIiwgc3VjaCBhcyBmb3IgU2ltdWxjYXN0 LCBGRUMsIGV0Yy4NCj4gICAgLy8gQW5kIHRoZXkgY2FuIGJlIGdyb3VwZWQgaW4gYXJiaXRyYXJ5 IHdheXMuDQo+ICAgIE1lZGlhRmxvd0Rlc2NyaXB0aW9uW10gZmxvd3M7DQo+ICAgIE1lZGlhRmxv d0dyb3VwW10gZmxvd0dyb3VwczsNCj4gfQ0KPg0KPiAvLyBSZXByZXNlbnRzIHRoZSBwYXJhbWV0 ZXJzIHVzZWQgdG8gZWl0aGVyIHNlbmQgb3IgcmVjZWl2ZSBhICJmbG93Ig0KPiAvLyBvdmVyIGEg UGVlckNvbm5lY3Rpb24uICBBICJmbG93IiBpcyBhIG1lZGlhIHRoYXQgYXJyaXZlcyB3aXRoIGEN Cj4gLy8gc2luZ2xlLCB1bmlxdWUgU1NSQy4gIE9uZSB0byBtYW55IGZsb3dzIHRvZ2V0aGVyIG1h a2UgdXAgdGhlIG1lZGlhDQo+IC8vIGZvciBhIHRyYWNrLiAgRm9yIGV4YW1wbGUsIHRoZXJlIG1h eSBiZSBTaW11bGNhc3QsIEZFQywgYW5kIFJUWA0KPiAvLyBmbG93cy4NCj4gZGljdGlvbmF5IE1l ZGlhRmxvd0Rlc2NyaXB0aW9uIHsNCj4gICAgLy8gVGhlICJmbG93IGlkIiBtdXN0IGJlIHVuaXF1 ZSB0byB0aGUgdHJhY2ssIGJ1dCBuZWVkIG5vdCBiZSB1bmlxdWUNCj4gICAgLy8gb3V0c2lkZSBv ZiB0aGUgdHJhY2sgKHR3byB0cmFja3MgY291bGQgYm90aCBoYXZlIGEgZmxvdyB3aXRoIHRoZQ0K PiAgICAvLyBzYW1lIGZsb3cgSUQpLg0KPiAgICBET01TdHJpbmcgaWQ7DQo+DQo+ICAgIC8vIEVh Y2ggZmxvdyBjYW4gZ28gb3ZlciBpdHMgb3duIHRyYW5zcG9ydC4gIElmIHRoZSBKUyBzZXRzIHRo aXMgdG8gYQ0KPiAgICAvLyB0cmFuc3BvcnRJZCB0aGF0IGRvZXNuJ3QgaGF2ZSBhIHRyYW5zcG9y dCBzZXR1cCBhbHJlYWR5LCB0aGUNCj4gICAgLy8gYnJvd3NlciB3aWxsIHVzZSBTRFAgbmVnb3Rp YXRpb24gdG8gc2V0dXAgYSB0cmFuc3BvcnQgdG8gYmFjayB0aGF0DQo+ICAgIC8vIHRyYW5zcG9y dElkLiAgSWYgVGhpcyBpcyBzZXQgdG8gYW4gTUlEIGluIHRoZSBTRFAsIHRoZW4gdGhhdCBNSUQn cw0KPiAgICAvLyB0cmFuc3BvcnQgaXMgdXNlZC4NCj4gICAgRE9NU3RyaW5nIHRyYW5zcG9ydElk Ow0KV2hlcmUgZnJvbSBkbyB5b3UgZ2V0IHRyYW5zcG9ydElkIChlLmcuIGlmIHlvdSB3YW50IHRv IHJlLXVzZSBvbmUpPw0KDQpGaXJzdCwgdGhlIGJyb3dzZXIgd291bGQgZmlsbCBpdCBpbiB2aWEg Y3JlYXRlTG9jYWxTdHJlYW0uICBTbyBpbiBhbG1vc3QgYWxsIGNhc2VzLCB0aGUgSlMgd291bGQg bm90IG5lZWQgdG8gc2V0IGl0LiAgSW4gdmVyeSBhZHZhbmNlZCBhcHBsaWNhdGlvbnMgdGhhdCB3 YW50IHRvIGRvIHRyaWNreSB0aGluZ3Mgd2l0aCB0cmFuc3BvcnRzLCB0aGVuIHRoZSB2YWx1ZSBz aG91bGQgYmUgdGhlIE1JRCBmb3IgdGhhdCB0cmFuc3BvcnQgZm91bmQgaW4gdGhlIFNEUCwgYXMg aXQgc2F5cyBpbiB0aGUgY29tbWVudC4NCg0KDQo+DQo+ICAgIC8vIFRoZSBTU1JDIHVzZWQgdG8g c2VuZCB0aGUgZmxvdy4NCj4gICAgdW5zaWduZWQgaW50IHNzcmM7DQo+DQo+ICAgIC8vIFdoZW4g dXNlZCBhcyByZWNlaXZlIHBhcmFtZXRlcnMsIHRoaXMgaW5kaWNhdGVzIHRoZSBwb3NzaWJsZSBs aXN0DQo+ICAgIC8vIG9mIGNvZGVjcyB0aGF0IG1pZ2h0IGNvbWUgaW4gZm9yIHRoaXMgZmxvdy4g IEZvciBleG1hbXBsZSwgYSBnaXZlbg0KPiAgICAvLyByZWNlaXZlIGZsb3cgY291bGQgYmUgc2V0 dXAgdG8gcmVjZWl2ZSBhbnkgb2YgT1BVUywgSVNBQywgb3IgUENNVS4NCj4gICAgLy8gV2hlbiB1 c2VkIGFzIHNlbmQgcGFyYW1ldGVycywgdGhpcyBpbmRpY2F0ZXMgdGhhdCB0aGUgZmlyc3QgY29k ZWMNCj4gICAgLy8gc2hvdWxkIGJlIHVzZWQsIGJ1dCB0aGUgYnJvd3NlciBjYW4gdXNlIHNlbmQg b3RoZXIgY29kZWNzIGlmIGl0DQo+ICAgIC8vIG5lZWRzIHRvIGJlY2F1c2Ugb2YgZWl0aGVyIGJh bmR3aWR0aCBvciBDUFUgY29uc3RyYWludHMuDQo+ICAgIE1lZGlhQ29kZWNEZXNjcmlwdGlvbltd IGNvZGVjczsNCj4gfQ0KPg0KPg0KPiBkaWN0aW9uYXJ5IE1lZGlhRmxvd0dyb3VwIHsNCj4gICAg RE9NU3RyaW5nIHR5cGU7ICAvLyAiU0lNIiBmb3IgU2ltdWxjYXN0LCAiRkVDIiBmb3IgRkVDLCBl dGMNCj4gICAgRE9NU3RyaW5nW10gZmxvd2lkczsNCj4gfQ0KPg0KPiBkaWN0aW9uYXJ5IE1lZGlh Q29kZWNEZXNjcmlwdGlvbiB7DQo+ICAgIHVuc2lnbmVkIGJ5dGUgcGF5bG9hZFR5cGU7DQo+ICAg IERPTVN0cmluZyBuYW1lOw0KPiAgICB1bnNpZ25lZCBpbnQ/IGNsb2NrUmF0ZTsNCj4gICAgdW5z aWduZWQgaW50PyBiaXRSYXRlOw0KPiAgICAvLyBBIGdyYWIgYmFnIG9mIG90aGVyIGZtdHAgdGhh dCB3aWxsIG5lZWQgdG8gYmUgZnVydGhlciBkZWZpbmVkLg0KPiAgICBNZWRpYUNvZGVjUGFyYW1b XSBwYXJhbXM7DQo+IH0NCj4NCj4gZGljdGlvbmFyeSBNZWRpYUNvZGVjUGFyYW0gew0KPiAgICBE T01TdHJpbmcga2V5Ow0KPiAgICBET01TdHJpbmcgdmFsdWU7DQo+IH0NCj4NCj4NCj4gTm90ZXM6 DQo+DQo+IC0gV2hlbiBMb2NhbE1lZGlhU3RyZWFtcyBhcmUgYWRkZWQgdXNpbmcgYWRkU3RyZWFt LCBvbm5lZ290aWF0ZWRuZWVkZWQNCj4gaXMgbm90IGNhbGxlZCwgYW5kIHRob3NlIHN0cmVhbXMg YXJlIG5ldmVyIHJlZmxlY3RlZCBpbiBmdXR1cmUgU0RQDQo+IGV4Y2hhbmdlcy4gIEluZGVlZCwg aXQgd291bGQgYmUgaW1wb3NzaWJsZSB0byBwdXQgdGhlbSBpbiB0aGUgU0RQDQo+IHdpdGhvdXQg Zmlyc3QgcmVzb2x2aW5nIGlmIHRoYXQgd291bGQgYmUgUGxhbiBBIFNEUCBvciBQbGFuIEIgU0RQ Lg0KPg0KPiAtIEp1c3QgbGlrZSBwaWxlcyBvZiBhdHRyaWJ1dGVzIHdvdWxkIG5lZWQgdG8gYmUg ZGVmaW5lZCBmb3IgUGxhbiBBIGFuZA0KPiBmb3IgUGxhbiBCLCBzaW1pbGFyIGF0dHJpYnV0ZXMg d291bGQgbmVlZCB0byBiZSBkZWZpbmVkIGhlcmUgKEx1Y2tpbHksDQo+ICAgbXVjaCB3b3JrIGhh cyBhbHJlYWR5IGJlZW4gZG9uZSBmaWd1cmluZyBvdXQgd2hhdCB0aG9zZSBwYXJhbWV0ZXJzIGFy ZSA6KS4NCj4NCj4NCj4gUHJvczoNCj4NCj4gLSBFaXRoZXIgUGxhbiBBIG9yIFBsYW4gQiBvciBj b3VsZCBiZSBpbXBsZW1lbnRlZCBpbiBKYXZhc2NyaXB0IHVzaW5nDQo+IHRoaXMgQVBJDQo+IC0g SXQgZXhwb3NlcyBhbGwgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eSB0byB0aGUgSmF2YXNjcmlwdCBh cyBTRFAsIGJ1dCBpbg0KPiBhIG11Y2ggbmljZXIgZm9ybWF0IHRoYXQgaXMgbXVjaCBlYXNpZXIg dG8gd29yayB3aXRoLg0KPiAtIEFueSBvdGhlciBzaWduYWxsaW5nIG1lY2hhbmlzbSwgc3VjaCBh cyBKaW5nbGUgb3IgQ0xVRSBjb3VsZCBiZQ0KPiBpbXBsZW1lbnRlZCB1c2luZyB0aGlzIEFQSS4N Cj4gLSBUaGVyZSBpcyBhbG1vc3Qgbm8gcmlzayBvZiBzaWduYWxsaW5nIGdsYXJlLg0KPiAtIERl YnVnZ2luZyBlcnJvcnMgd2l0aCBtaXNjb25maWd1cmVkIGRlc2NyaXB0aW9ucyBzaG91bGQgYmUg bXVjaCBlYXNpZXINCj4gd2l0aCB0aGlzIHRoYW4gd2l0aCBsYXJnZSBTRFAgYmxvYnMuDQo+DQo+ DQo+IENvbnM6DQo+DQo+IC0gTm93IHRoZXJlIGFyZSB0d28gc2xpZ2h0bHkgZGlmZmVyZW50IHdh eXMgdG8gYWRkIHN0cmVhbXM6IGJ5IGNyZWF0aW5nDQo+IGEgTG9jYWxNZWRpYVN0cmVhbSBmaXJz dCwgYW5kIG5vdC4gIFRoaXMgaXMsIGhvd2V2ZXIsIGFuYWxvZ291cyB0bw0KPiBzZXR0aW5nICJu ZWdvdGlhdGVkOiB0cnVlIiBpbiBjcmVhdGVEYXRhQ2hhbm5lbC4gIE9uIHdheSBpcyAiSnVzdCBX b3JrIiwNCj4gYW5kIHRoZSBvdGhlciBpcyBtb3JlIGFkdmFuY2VkIGNvbnRyb2wuDQo+DQo+IC0g QWxsIHRoZSBvcHRpb25zIGluIE1lZGlhQ29kZWNEZXNjcmlwdGlvbiBhcmUgYSBiaXQgY29tcGxp Y2F0ZWQuDQo+ICAgUmVhbGx5LCB0aGlzIGlzIG9ubHkgbmVjZXNzYXJ5IGJlY2F1c2UgUGxhbiBB IHJlcXVpcmVzIGJlaW5nIGFibGUgdG8NCj4gc3BlY2lmeSBjb2RlYyBwYXJhbWV0ZXJzIHBlciBT U1JDLCBhbmQgc2V0IGVhY2ggZmxvdyBvbiBkaWZmZXJlbnQNCj4gdHJhbnNwb3J0cy4gIElmIHdl IGRpZCBub3QgaGF2ZSB0aGlzIHJlcXVpcmVtZW50LCB3ZSBjb3VsZCBzaW1wbGlmeS4NCj4NCj4N Cj4gRXhhbXBsZSBVc2FnZToNCj4NCj4gLy8gSW1hZ2luZSBJIGhhdmUgTXlBcHAsIGhhbmRsZXMg Y3JlYXRpbmcgYSBQZWVyQ29ubmVjdGlvbiwNCj4gLy8gc2lnbmFsbGluZywgYW5kIHJlbmRlcmlu ZyBzdHJlYW1zLiAgVGhpcyBpcyBob3cgdGhlIG5ldyBBUEkgY291bGQgYmUNCj4gLy8gdXNlZC4N Cj4gdmFyIHBlZXJDb25uZWN0aW9uID0gTXlBcHAuY3JlYXRlUGVlckNvbm5lY3Rpb24oKTsNCj4N Cj4gLy8gT24gc2VuZGVyIHNpZGU6DQo+IHZhciBzdHJlYW0gPSBNeUFwcC5nZXRNZWRpYVN0cmVh bSgpOw0KPiB2YXIgbG9jYWxTdHJlYW0gPSBwZWVyQ29ubmVjdGlvbi5jcmVhdGVTZW5kU3RyZWFt KHN0cmVhbSk7DQo+IHNlbmRTdHJlYW0uZGVzY3JpcHRpb24gPSBNeUFwcC5tb2RpZnlTdHJlYW0o bG9jYWxTdHJlYW0uZGVzY3JpcHRpb24pDQpTaG91bGQgaXQgc2F5ICJsb2NhbFN0cmVhbS5kZXNj cmlwdGlvbiI/DQoNClllcy4gVGhlcmUgd2FzIGEgbGFzdC1taW51dGUgcmVuYW1lIGFuZCBJIG1p c3NlZCBhIHNwb3QuICBBbnl3aGVyZSB5b3Ugc2VlICJzZW5kU3RyZWFtIiwgaXQgc2hvdWxkIGJl ICJsb2NhbFN0cmVhbSIuDQoNCg0KPiBNeUFwcC5zaWduYWxBZGRTdHJlYW0obG9jYWxTdHJlYW0u ZGVzY3JpcHRpb24sIGZ1bmN0aW9uKHJlc3BvbnNlKSkgew0KPiAgICBpZiAoIXJlc3BvbnNlLnJl amVjdGVkKSB7DQo+ICAgICAgLy8gTWVkaWEgd2lsbCBub3QgYmUgc2VudC4NCj4gICAgICBwZWVy Q29ubmVjdGlvbi5hZGRTdHJlYW0obG9jYWxTdHJlYW0pOw0KPiAgICB9DQo+IH0NCj4NCj4gLy8g T24gcmVjZWl2ZXIgc2lkZToNCj4gTXlBcHAub25BZGRTdHJlYW1TaWduYWxsZWQgPSBmdW5jdGlv bihzdHJlYW1EZXNjcmlwdGlvbikgew0KPiAgICB2YXIgc3RyZWFtID0gcGVlckNvbm5lY3Rpb24u Y3JlYXRlUmVjZWl2ZVN0cmVhbShzdHJlYW1EZXNjcmlwdGlvbik7DQo+ICAgIE15QXBwLnJlbmRl clN0cmVhbShzdHJlYW0pOw0KPiB9DQo+DQo+DQo+IC8vIEluIHRoaXMgZXhjaGFuZ2UsIHRoZSBN ZWRpYVN0cmVhbURlc2NyaXB0aW9uIHNpZ25hbGxlZCBmcm9tIHRoZQ0KPiAvLyBzZW5kZXIgdG8g dGhlIHJlY2VpdmVyIG1heSBoYXZlIGxvb2tlZCBzb21ldGhpbmcgbGlrZSB0aGlzOg0KPg0KPiB7 DQo+ICAgIHRyYWNrczogWw0KPiAgICB7DQo+ICAgICAgaWQ6ICJhdWRpbzEiLA0KPiAgICAgIGtp bmQ6ICJhdWRpbyIsDQo+ICAgICAgZmxvd3M6IFsNCj4gICAgICB7DQo+IGlkOiAibWFpbiIsDQo+ ICAgICAgICB0cmFuc3BvcnRJZDogInRyYW5zcG9ydDEiLA0KPiAgICAgICAgc3NyYzogMTExMSwN Cj4gICAgICAgIGNvZGVjczogWw0KPiAgICAgICAgew0KPiAgICAgICAgICBwYXlsb2FkVHlwZTog MTExLA0KPiAgICAgICAgICBuYW1lOiAib3B1cyIsDQo+ICAgICAgICAgIC8vIC4uLiBtb3JlIGNv ZGVjIGRldGFpbHMNCj4gICAgICAgIH0sDQo+ICAgICAgICB7DQo+ICAgICAgICAgIHBheWxvYWRU eXBlOiAxMTIsDQo+ICAgICAgICAgIG5hbWU6ICJwY211IiwNCj4gLy8gLi4uIG1vcmUgY29kZWMg ZGV0YWlscw0KPiAgICAgICAgfV0NCj4gICAgIH1dDQo+ICAgfSwNCj4gICB7DQo+ICAgICAgaWQ6 ICJ2aWRlbzEiLA0KPiAgICAgIGtpbmQ6ICJ2aWRlbyIsDQo+ICAgICAgZmxvd3M6IFsNCj4gICAg ICB7DQo+ICAgICAgICBpZDogInNpbTAiLA0KPiAgICAgICAgdHJhbnNwb3J0SWQ6ICJ0cmFuc3Bv cnQyIiwNCj4gICAgICAgIHNzcmM6IDIyMjIsDQo+ICAgICAgICBjb2RlY3M6IFsNCj4gICAgICAg IHsNCj4gICAgICAgICAgcGF5bG9hZFR5cGU6IDEyMiwNCj4gICAgICAgICAgbmFtZTogInZwOCIN Cj4gLy8gLi4uIG1vcmUgY29kZWMgZGV0YWlscw0KPiAgICAgICAgfV0NCj4gICAgIH0sDQo+ICAg ICB7DQo+ICAgICAgIGlkOiAic2ltMSIsDQo+ICAgICAgIHRyYW5zcG9ydElkOiAidHJhbnNwb3J0 MiIsDQo+ICAgICAgIHNzcmM6IDIyMjMsDQo+ICAgICAgIGNvZGVjczogWw0KPiAgICAgICB7DQo+ ICAgICAgICAgcGF5bG9hZFR5cGU6IDEyMiwNCj4gICAgICAgICBuYW1lOiAidnA4IiwNCj4gLy8g Li4uIG1vcmUgY29kZWMgZGV0YWlscw0KPiAgICAgICB9XQ0KPiAgICAgfSwNCj4gICAgIHsNCj4g ICAgICAgaWQ6ICJzaW0yIiwNCj4gICAgICAgdHJhbnNwb3J0SWQ6ICJ0cmFuc3BvcnQyIiwNCj4g ICAgICAgc3NyYzogMjIyNCwNCj4gICAgICAgY29kZWNzOiBbDQo+ICAgICAgIHsNCj4gICAgICAg ICBwYXlsb2FkVHlwZTogMTIyLA0KPiAgICAgICAgIG5hbWU6ICJ2cDgiLA0KPiAvLyAuLi4gbW9y ZSBjb2RlYyBkZXRhaWxzDQo+ICAgICAgIH1dDQo+ICAgICB9LA0KPg0KPiAgICAgew0KPiAgICAg ICBpZDogInNpbTBmZWMiLA0KPiAgICAgICB0cmFuc3BvcnRJZDogInRyYW5zcG9ydDIiLA0KPiAg ICAgICBzc3JjOiAyMjI1LA0KPiAgICAgICBjb2RlY3M6IFsNCj4gICAgICAgew0KPiAgICAgICAg IHBheWxvYWRUeXBlOiAxMjIsDQo+ICAgICAgICAgbmFtZTogInZwOCIsDQo+ICAgICAgICAgLy8g Li4uDQo+ICAgICAgIH1dDQo+ICAgICB9XSwNCj4gICAgIGZsb3dHcm91cHM6IFsNCj4gICAgIHsN Cj4gICAgICAgc2VtYW50aWNzOiAiU0lNIiwNCj4gICAgICAgc3NyY3M6IFsyMjIyLCAyMjIzLCAy MjI0XQ0KPiAgICAgfSwNCj4gICAgIHsNCj4gICAgICAgc2VtYW50aWNzOiAiRkVDIiwNCj4gICAg ICAgc3NyY3M6IFsyMjIyLCAyMjI1XQ0KPiAgICAgfV0NCj4gICB9XQ0KPiB9DQo+DQo+DQo+IENv bnN0cnVjdGl2ZSBmZWVkYmFjayBpcyB3ZWxjb21lIDopLg0KDQo= --_000_57A15FAF9E58F841B2B1651FFE16D28104C918GENSJZMBX01msgint_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAy IDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFy Z2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTk5NDI2MTc1 MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTYxOTI4 ODcxMiA4NzEzNjk4OTYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC1zdGFydC1hdDoxNjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Ik1TIE1pbmNo byI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGF0IGNhbiB5b3UgbW9kaWZ5IGluIGEgTG9jYWxN ZWRpYVN0cmVhbSBieSBlZGl0aW5nIGl0cyBkZXNjcmlwdGlvbj8mbmJzcDsgQ2FuIHlvdSBhZGQg YSB2aWRlbyB0cmFjayB0byBpdD8mbmJzcDsgVGhhdCB3b3VsZCBpbXBseSBjYWxsaW5nIGdVTSwg YW5kIHlvdeKAmWQmbmJzcDsgaGF2ZSB0byB0aHJlYWQNCiBpdOKAmXMgc3VjY2VzcyBhbmQgZmFp bHVyZSBjYWxsYmFja3MgdXAgdG8gdGhlIGVkaXRpbmcgb3BlcmF0aW9uLiZuYnNwOyBPciBpcyB0 aGUgdHJhY2sgbGlzdCBmaXhlZCwgc28gdGhhdCB5b3UgY2FuIG9ubHkgdHdlYWsgdHJhbnNwb3J0 IGluZm8gYnkgZWRpdGluZyB0aGUgTG9jYWxNZWRpYVN0cmVhbeKAmXMgZGVzY3JpcHRpb24/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkppbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UGV0 ZXIgVGhhdGNoZXI8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdW5lIDE3LCAyMDEzIDExOjEz IEFNPGJyPg0KPGI+VG86PC9iPiBTdGVmYW4gSMOla2Fuc3NvbiBMSzxicj4NCjxiPkNjOjwvYj4g Jmx0O3J0Y3dlYkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJd IFByb3Bvc2FsIGZvciBhIEpTIEFQSSBmb3IgTm9QbGFuIChhZGRpbmcgbXVsdGlwbGUgc291cmNl cyB3aXRob3V0IGVuY29kaW5nIHRoZW0gaW4gU0RQKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5zd2Vyczo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgSnVuIDE3LCAy MDEzIGF0IDY6NTggQU0sIFN0ZWZhbiBIw6VrYW5zc29uIExLICZsdDs8YSBocmVmPSJtYWlsdG86 c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5zdGVmYW4u bGsuaGFrYW5zc29uQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBjb3VwbGUgb2YgcXVlc3Rpb25zICh0byBoZWxwIG1lIHVu ZGVyc3RhbmQpIGluLWxpbmUgLy9TdGVmYW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpP biAyMDEzLTA2LTE3IDE0OjU3LCBQZXRlciBUaGF0Y2hlciB3cm90ZTo8YnI+DQomZ3Q7IEdvb2ds ZSBpcyBpbiBmdWxsIHN1cHBvcnQgb2YgJnF1b3Q7UGxhbiBCJnF1b3Q7IGZvciBlbmNvZGluZyBt dWx0aXBsZSBtZWRpYTxicj4NCiZndDsgc291cmNlcyBpbiBTRFAsIGFuZCB3b3VsZCBsaWtlIHRv IHNlZSB0aGUgUGxhbiBBIHZzLiBQbGFuIEIgZGVjaXNpb248YnI+DQomZ3Q7IHJlc29sdmVkIHNv b24uICZuYnNwO1JlY2VudGx5LCB0aG91Z2gsIGEgdGhpcmQgb3B0aW9uLCBjYWxsZWQgJnF1b3Q7 Tm9QbGFuJnF1b3Q7IGhhczxicj4NCiZndDsgYmVlbiBwcm9wb3NlZCwgYnV0IGl0IGxhY2tlZCB0 aGUgZGV0YWlscyBvZiB3aGF0IGEgSlMgQVBJIHdvdWxkIGxvb2s8YnI+DQomZ3Q7IGxpa2UgZm9y IE5vUGxhbi4gJm5ic3A7Q3VsbGVuIGFza2VkIHRvIHNlZSBzdWNoIGFuIEFQSSBwcm9wb3NhbCwg YW5kIHNvIEk8YnI+DQomZ3Q7IGhhdmUgd29ya2VkIHdpdGggRW1pbCB0byBtYWtlIG9uZS4gJm5i c3A7SGUgd2lsbCBiZSBhZGRpbmcgaXQgdG8gdGhlIE5vUGxhbjxicj4NCiZndDsgZHJhZnQsIGJ1 dCBJIHdpbGwgYWxzbyBpbmNsdWRlIGl0IGluIHRoaXMgZW1haWwuPGJyPg0KJmd0Ozxicj4NCiZn dDsgQWdhaW4sIEdvb2dsZSBpcyBpbiBmdWxsIHN1cHBvcnQgb2YgJnF1b3Q7UGxhbiBCJnF1b3Q7 LiAmbmJzcDtCdXQgaWYgUGxhbiBBIHZzLiBQbGFuIEI8YnI+DQomZ3Q7IGNhbm5vdCBiZSBkZWNp ZGVkLCB0aGVuIHdlIHN1cHBvcnQgTm9QbGFuIHdpdGggdGhlIGZvbGxvd2luZyBhZGRpdGlvbnM8 YnI+DQomZ3Q7IHRvIHRoZSBXZWJSVEMgSlMgQVBJIGFzIGFuIG9wdGlvbiB0aGF0IGFsbG93cyBp bXBsZW1lbnRpbmcgZWl0aGVyIFBsYW4gQTxicj4NCiZndDsgb3IgUGxhbiBCICZuYnNwO2luIEph dmFzY3JpcHQuICZuYnNwO0FuZCBldmVuIGlmIFBsYW4gQSB2cy4gUGxhbiBCIGlzIHJlc29sdmVk LDxicj4NCiZndDsgdGhlc2UgQVBJIGFkZGl0aW9ucyB3b3VsZCBzdGlsbCBiZSBhIGJpZyBpbXBy b3ZlbWVudCBmb3IgdGhvc2UgV2ViUlRDPGJyPg0KJmd0OyBhcHBsaWNhdGlvbnMgdGhhdCBkb24n dCB1c2UgU0RQIGZvciBzaWduYWxsaW5nLjxicj4NCiZndDs8YnI+DQomZ3Q7IEl0IGlzIGEgYml0 IGxvbmcgYmVjYXVzZSBJIGhhdmUgYWRkZWQgbWFueSBjb21tZW50cyBhbmQgZXhhbXBsZXMsIGJ1 dDxicj4NCiZndDsgdGhlIGFjdHVhbGx5IGFkZGl0aW9ucyBvbmx5IGluY2x1ZGUgdHdvIG5ldyBt ZXRob2RzIG9uIFBlZXJDb25uZWN0aW9uPGJyPg0KJmd0OyBhbmQgYSBmZXcgbmV3IGRpY3Rpb25h cmllcy4gJm5ic3A7U28gZG9uJ3QgYmUgb3ZlcndoZWxtZWQgOikuPGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbnRybzogVGhpcyBmb2xsb3dzIHRoZSBtb2RlbCBvZiBj cmVhdGVEYXRhQ2hhbm5lbCwgd2hpY2ggaGFzIGEgSlM8YnI+DQomZ3Q7IG1ldGhvZCBvbiBQZWVy Q29ubmVjdGlvbiB0aGF0IG1ha2VzIGl0IHBvc3NpYmxlIHRvIGFkZCBkYXRhIGNoYW5uZWxzPGJy Pg0KJmd0OyB3aXRob3V0IGdvaW5nIHRocm91Z2ggU0RQLiAmbmJzcDtGdXJ0aGVybW9yZSwganVz dCBsaWtlIGNyZWF0ZURhdGFDaGFubmVsPGJyPg0KJmd0OyBhbGxvd3MgMiB3YXlzIHRvIGhhbmRs ZSBuZW9naXRhdGlvbiAodGhlICZxdW90O0kga25vdyB3aGF0IEknbSBkb2luZzsgJm5ic3A7SGVy ZSdzPGJyPg0KJmd0OyB3aGF0IEkgd2FudCB0byBzZW5kOyBMZXQgbWUgc2lnbmFsIGV2ZXJ5dGhp bmcmcXVvdDsgbW9kZSBhbmQgdGhlICZxdW90O3BsZWFzZSB0YWtlPGJyPg0KJmd0OyBjYXJlIG9m IGl0IGZvciBtZTsgJm5ic3A7c2VuZCBhbiBPUEVOIG1lc3NhZ2UmcXVvdDsgbW9kZSksIHRoaXMg YWxzbyBoYXMgMiB3YXlzIHRvPGJyPg0KJmd0OyBoYW5kbGUgbmVnb3RpYXRpb24gKHRoZSAmcXVv dDtJIGtub3cgd2hhdCBJJ20gZG9pbmc7IEhlcmUncyB3aGF0IEkgd2FudCB0bzxicj4NCiZndDsg c2VuZDsgTGV0IG1lIHNpZ25hbCBldmVyeXRoaW5nJnF1b3Q7IG1vZGUgYW5kIHRoZSAmcXVvdDtw bGVhc2UgdGFrZSBjYXJlIG9mIGl0IGZvcjxicj4NCiZndDsgbWU7ICZuYnNwO3NlbmQgU0RQIGJh Y2sgYW5kIGZvcnRoJnF1b3Q7IG1vZGUpLjxicj4NCiZndDs8YnI+DQomZ3Q7IEZvbGxvd2luZyB0 aGUgc3VjY2VzcyBvZiBjcmVhdGVEYXRhQ2hhbm5lbCwgdGhpcyBhbGxvd3Mgc2ltcGxlPGJyPg0K Jmd0OyBhcHBsaWNhdGlvbnMgdG8gSnVzdCBXb3JrIGFuZCBtb3JlIGFkdmFuY2VkIGFwcGxpY2F0 aW9ucyB0byBlYXNpbHk8YnI+DQomZ3Q7IGNvbnRyb2wgd2hhdCB0aGV5IG5lZWQgdG8uICZuYnNw O0luIHBhcnRpY3VsYXIsIGl0J3MgcG9zc2libGUgdG8gdXNlIHRoaXMgQVBJPGJyPg0KJmd0OyB0 byBpbXBsZW1lbnQgZWl0aGVyIFBsYW4gQSBvciBQbGFuIEIuPGJyPg0KJmd0Ozxicj4NCiZndDsg Ly8gVGhlIGZvbGxvd2luZyB0d28gbWV0aG9kIGFyZSBhZGRlZCB0byBSVENQZWVyQ29ubmVjdGlv bjxicj4NCiZndDsgcGFydGlhbCBpbnRlcmZhY2UgUlRDUGVlckNvbm5lY3Rpb24gezxicj4NCiZn dDsgJm5ic3A7IC8vIENyZWF0ZSBhIHN0cmVhbSB0aGF0IGlzIHVzZWQgdG8gc2VuZCBhIHNvdXJj ZSBzdHJlYW0uPGJyPg0KJmd0OyAmbmJzcDsgLy8gVGhlIE1lZGlhU2VuZFN0cmVhbS5kZXNjcmlw dGlvbiBjYW4gYmUgdXNlZCBmb3Igc2lnbmFsbGluZy48YnI+DQomZ3Q7ICZuYnNwOyAvLyBObyBt ZWRpYSBpcyBzZW50IHVudGlsIGFkZFN0cmVhbShNZWRpYVNlbmRTdHJlYW0pIGlzIGNhbGxlZC48 YnI+DQomZ3Q7ICZuYnNwOyBMb2NhbE1lZGlhU3RyZWFtIGNyZWF0ZUxvY2FsU3RyZWFtKE1lZGlh U3RyZWFtIHNvdXJjZVN0cmVhbSk7PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7IC8vIENyZWF0 ZSBhIHN0cmVhbSB0aGF0IGlzIHVzZWQgdG8gcmVjZWl2ZSBtZWRpYSBmcm9tIHRoZSByZW1vdGUg c2lkZSw8YnI+DQomZ3Q7ICZuYnNwOyAvLyBnaXZlbiB0aGUgcGFyYW1ldGVycyBzaWduYWxsZWQg ZnJvbSBNZWRhaVNlbmRTdHJlYW0uZGVzY3JpcHRpb24uPGJyPg0KJmd0OyAmbmJzcDsgTWVkaWFT dHJlYW0gY3JlYXRlUmVtb3RlU3RyZWFtKE1lZGlhU3RyZWFtRGVzY3JpcHRpb24gZGVzY3JpcHRp b24pOzxicj4NCiZndDsgfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPndoYXQgd291bGQgaGFwcGVuIGlmIHRoZSBhcHBsaWNhdGlvbiBhZGRzIG9y IHJlbW92ZXMgYSB0cmFjayBmcm9tPGJyPg0Kc291cmNlU3RyZWFtIChJJ20gdGhpbmtpbmcgb24g aG93IHdoYXQgd291bGQgaW1wYWN0IHRoZSBjcmVhdGVkPGJyPg0KTG9jYWxNZWRpYVN0cmVhbSBh bmQgdGhlIE1lZGlhU3RyZWFtIGF0IHRoZSByZW1vdGUgZW5kKT88bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R29vZCBxdWVzdGlv bi4gJm5ic3A7SSdkIGhhdmUgdG8gdGhpbmsgYWJvdXQgaXQgc29tZSBtb3JlLCBidXQgb2ZmIHRo ZSBiYXQsIEknZCBzYXkgdGhhdCBvbiB0aGUgc2VuZGVyIHNpZGUsIGFkZGluZyBvciByZW1vdmlu ZyB0cmFja3MgZnJvbSB0aGUgc291cmNlIE1lZGlhU3RyZWFtIHdvdWxkIGhhdmUgbm8gZWZmZWN0 IG9uIHdoYXQgaXMgc2VudC4gJm5ic3A7SW4gb3RoZXIgd29yZHMsIGl0J3MgYXMgaWYgdGhlIHNv dXJjZSBNZWRpYVN0cmVhbQ0KIHdlcmUgY2xvbmVkIHdoZW4gY3JlYXRlTG9jYWxTdHJlYW0gd2Fz IGNhbGxlZC4gJm5ic3A7SWYgeW91IHdhbnQgdG8gbW9kaWZ5IHRoZSBMb2NhbFN0cmVhbSwgeW91 IGhhdmUgdG8gZ28gdGhyb3VnaCB0aGUgLmRlc2NyaXB0aW9uLiAmbmJzcDsgT24gdGhlIHJlY2Vp dmVyIHNpZGUsIGl0IHdvdWxkIGxvb2sgbGlrZSBhbnkgb3RoZXIgcmVjZWl2ZWQgTWVkaWFTdHJl YW06IGlmIHlvdSByZW1vdmUgdGhlIHRyYWNrLCBpdCBqdXN0IGRvZXNuJ3QgcGxheSBvdXQgYW55 bW9yZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IGludGVyZmFjZSBMb2NhbE1lZGlhU3RyZWFtIGltcGxlbWVu dHMgTWVkaWFTdHJlYW0gezxicj4NCiZndDsgJm5ic3A7ICZuYnNwOy8vIFRoaXMgY2FuIGJlIGNo YW5nZWQgYXQgYW55IHRpbWUsIGJ1dCBlc3BlY2lhbGx5IGJlZm9yZSBjYWxsaW5nPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7Ly8gUGVlckNvbm5lY3Rpb24uYWRkU3RyZWFtPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7YXR0cmlidXRlIE1lZGlhU3RyZWFtRGVzY3JpcHRpb24gZGVzY3JpcHRpb247PGJy Pg0KJmd0OyB9PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IC8vIFJlcHJlc2VudHMgdGhl IHBhcmFtZXRlcnMgdXNlZCB0byBlaXRoZXIgc2VuZCBvciByZWNlaXZlIGEgc3RyZWFtPGJyPg0K Jmd0OyAvLyBvdmVyIGEgUGVlckNvbm5lY3Rpb24uPGJyPg0KJmd0OyBkaWN0aW9uYXJ5IE1lZGlh U3RyZWFtRGVzY3JpcHRpb24gezxicj4NCiZndDsgJm5ic3A7ICZuYnNwO01lZGlhU3RyZWFtVHJh Y2tEZXNjcmlwdGlvbltdIHRyYWNrczs8YnI+DQomZ3Q7IH08YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsgLy8gUmVwcmVzZW50cyB0aGUgcGFyYW1ldGVycyB1c2VkIHRvIGVpdGhlciBzZW5k IG9yIHJlY2VpdmUgYSB0cmFjayBvdmVyPGJyPg0KJmd0OyAvLyBhIFBlZXJDb25uZWN0aW9uLiAm bmJzcDtBIHRyYWNrIGhhcyBtYW55ICZxdW90O2Zsb3dzJnF1b3Q7LCB3aGljaCBjYW4gYmUgZ3Jv dXBlZDxicj4NCiZndDsgLy8gdG9nZXRoZXIuPGJyPg0KJmd0OyBkaWN0aW9uYXJ5IE1lZGlhU3Ry ZWFtVHJhY2tEZXNjcmlwdGlvbiB7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Ly8gU2FtZSBhcyB0 aGUgTWVkaWFTdHJlYW1UcmFjay5pZDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO0RPTVN0cmluZyBp ZDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Ly8gU2FtZSBhcyB0aGUgTWVkaWFT dHJlYW1UcmFjay5raW5kPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7RE9NU3RyaW5nIGtpbmQ7PGJy Pg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOy8vIEEgdHJhY2sgY2FuIGhhdmUgbWFueSAm cXVvdDtmbG93cyZxdW90Oywgc3VjaCBhcyBmb3IgU2ltdWxjYXN0LCBGRUMsIGV0Yy48YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsvLyBBbmQgdGhleSBjYW4gYmUgZ3JvdXBlZCBpbiBhcmJpdHJhcnkg d2F5cy48YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtNZWRpYUZsb3dEZXNjcmlwdGlvbltdIGZsb3dz Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwO01lZGlhRmxvd0dyb3VwW10gZmxvd0dyb3Vwczs8YnI+ DQomZ3Q7IH08YnI+DQomZ3Q7PGJyPg0KJmd0OyAvLyBSZXByZXNlbnRzIHRoZSBwYXJhbWV0ZXJz IHVzZWQgdG8gZWl0aGVyIHNlbmQgb3IgcmVjZWl2ZSBhICZxdW90O2Zsb3cmcXVvdDs8YnI+DQom Z3Q7IC8vIG92ZXIgYSBQZWVyQ29ubmVjdGlvbi4gJm5ic3A7QSAmcXVvdDtmbG93JnF1b3Q7IGlz IGEgbWVkaWEgdGhhdCBhcnJpdmVzIHdpdGggYTxicj4NCiZndDsgLy8gc2luZ2xlLCB1bmlxdWUg U1NSQy4gJm5ic3A7T25lIHRvIG1hbnkgZmxvd3MgdG9nZXRoZXIgbWFrZSB1cCB0aGUgbWVkaWE8 YnI+DQomZ3Q7IC8vIGZvciBhIHRyYWNrLiAmbmJzcDtGb3IgZXhhbXBsZSwgdGhlcmUgbWF5IGJl IFNpbXVsY2FzdCwgRkVDLCBhbmQgUlRYPGJyPg0KJmd0OyAvLyBmbG93cy48YnI+DQomZ3Q7IGRp Y3Rpb25heSBNZWRpYUZsb3dEZXNjcmlwdGlvbiB7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Ly8g VGhlICZxdW90O2Zsb3cgaWQmcXVvdDsgbXVzdCBiZSB1bmlxdWUgdG8gdGhlIHRyYWNrLCBidXQg bmVlZCBub3QgYmUgdW5pcXVlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Ly8gb3V0c2lkZSBvZiB0 aGUgdHJhY2sgKHR3byB0cmFja3MgY291bGQgYm90aCBoYXZlIGEgZmxvdyB3aXRoIHRoZTxicj4N CiZndDsgJm5ic3A7ICZuYnNwOy8vIHNhbWUgZmxvdyBJRCkuPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7RE9NU3RyaW5nIGlkOzxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsvLyBFYWNo IGZsb3cgY2FuIGdvIG92ZXIgaXRzIG93biB0cmFuc3BvcnQuICZuYnNwO0lmIHRoZSBKUyBzZXRz IHRoaXMgdG8gYTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOy8vIHRyYW5zcG9ydElkIHRoYXQgZG9l c24ndCBoYXZlIGEgdHJhbnNwb3J0IHNldHVwIGFscmVhZHksIHRoZTxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOy8vIGJyb3dzZXIgd2lsbCB1c2UgU0RQIG5lZ290aWF0aW9uIHRvIHNldHVwIGEgdHJh bnNwb3J0IHRvIGJhY2sgdGhhdDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOy8vIHRyYW5zcG9ydElk LiAmbmJzcDtJZiBUaGlzIGlzIHNldCB0byBhbiBNSUQgaW4gdGhlIFNEUCwgdGhlbiB0aGF0IE1J RCdzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Ly8gdHJhbnNwb3J0IGlzIHVzZWQuPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7RE9NU3RyaW5nIHRyYW5zcG9ydElkOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZXJlIGZyb20gZG8geW91IGdldCB0 cmFuc3BvcnRJZCAoZS5nLiBpZiB5b3Ugd2FudCB0byByZS11c2Ugb25lKT88bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZpcnN0LCB0 aGUgYnJvd3NlciB3b3VsZCBmaWxsIGl0IGluIHZpYSBjcmVhdGVMb2NhbFN0cmVhbS4gJm5ic3A7 U28gaW4gYWxtb3N0IGFsbCBjYXNlcywgdGhlIEpTIHdvdWxkIG5vdCBuZWVkIHRvIHNldCBpdC4g Jm5ic3A7SW4gdmVyeSBhZHZhbmNlZCBhcHBsaWNhdGlvbnMgdGhhdCB3YW50IHRvIGRvIHRyaWNr eSB0aGluZ3Mgd2l0aCB0cmFuc3BvcnRzLCB0aGVuIHRoZSB2YWx1ZSBzaG91bGQgYmUgdGhlIE1J RCBmb3IgdGhhdA0KIHRyYW5zcG9ydCBmb3VuZCBpbiB0aGUgU0RQLCBhcyBpdCBzYXlzIGluIHRo ZSBjb21tZW50LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOy8vIFRoZSBTU1JDIHVzZWQg dG8gc2VuZCB0aGUgZmxvdy48YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt1bnNpZ25lZCBpbnQgc3Ny Yzs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Ly8gV2hlbiB1c2VkIGFzIHJlY2Vp dmUgcGFyYW1ldGVycywgdGhpcyBpbmRpY2F0ZXMgdGhlIHBvc3NpYmxlIGxpc3Q8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsvLyBvZiBjb2RlY3MgdGhhdCBtaWdodCBjb21lIGluIGZvciB0aGlzIGZs b3cuICZuYnNwO0ZvciBleG1hbXBsZSwgYSBnaXZlbjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOy8v IHJlY2VpdmUgZmxvdyBjb3VsZCBiZSBzZXR1cCB0byByZWNlaXZlIGFueSBvZiBPUFVTLCBJU0FD LCBvciBQQ01VLjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOy8vIFdoZW4gdXNlZCBhcyBzZW5kIHBh cmFtZXRlcnMsIHRoaXMgaW5kaWNhdGVzIHRoYXQgdGhlIGZpcnN0IGNvZGVjPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7Ly8gc2hvdWxkIGJlIHVzZWQsIGJ1dCB0aGUgYnJvd3NlciBjYW4gdXNlIHNl bmQgb3RoZXIgY29kZWNzIGlmIGl0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Ly8gbmVlZHMgdG8g YmVjYXVzZSBvZiBlaXRoZXIgYmFuZHdpZHRoIG9yIENQVSBjb25zdHJhaW50cy48YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDtNZWRpYUNvZGVjRGVzY3JpcHRpb25bXSBjb2RlY3M7PGJyPg0KJmd0OyB9 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IGRpY3Rpb25hcnkgTWVkaWFGbG93R3JvdXAg ezxicj4NCiZndDsgJm5ic3A7ICZuYnNwO0RPTVN0cmluZyB0eXBlOyAmbmJzcDsvLyAmcXVvdDtT SU0mcXVvdDsgZm9yIFNpbXVsY2FzdCwgJnF1b3Q7RkVDJnF1b3Q7IGZvciBGRUMsIGV0Yzxicj4N CiZndDsgJm5ic3A7ICZuYnNwO0RPTVN0cmluZ1tdIGZsb3dpZHM7PGJyPg0KJmd0OyB9PGJyPg0K Jmd0Ozxicj4NCiZndDsgZGljdGlvbmFyeSBNZWRpYUNvZGVjRGVzY3JpcHRpb24gezxicj4NCiZn dDsgJm5ic3A7ICZuYnNwO3Vuc2lnbmVkIGJ5dGUgcGF5bG9hZFR5cGU7PGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7RE9NU3RyaW5nIG5hbWU7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7dW5zaWduZWQg aW50PyBjbG9ja1JhdGU7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7dW5zaWduZWQgaW50PyBiaXRS YXRlOzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOy8vIEEgZ3JhYiBiYWcgb2Ygb3RoZXIgZm10cCB0 aGF0IHdpbGwgbmVlZCB0byBiZSBmdXJ0aGVyIGRlZmluZWQuPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7TWVkaWFDb2RlY1BhcmFtW10gcGFyYW1zOzxicj4NCiZndDsgfTxicj4NCiZndDs8YnI+DQom Z3Q7IGRpY3Rpb25hcnkgTWVkaWFDb2RlY1BhcmFtIHs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtE T01TdHJpbmcga2V5Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwO0RPTVN0cmluZyB2YWx1ZTs8YnI+ DQomZ3Q7IH08YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgTm90ZXM6PGJyPg0KJmd0Ozxi cj4NCiZndDsgLSBXaGVuIExvY2FsTWVkaWFTdHJlYW1zIGFyZSBhZGRlZCB1c2luZyBhZGRTdHJl YW0sIG9ubmVnb3RpYXRlZG5lZWRlZDxicj4NCiZndDsgaXMgbm90IGNhbGxlZCwgYW5kIHRob3Nl IHN0cmVhbXMgYXJlIG5ldmVyIHJlZmxlY3RlZCBpbiBmdXR1cmUgU0RQPGJyPg0KJmd0OyBleGNo YW5nZXMuICZuYnNwO0luZGVlZCwgaXQgd291bGQgYmUgaW1wb3NzaWJsZSB0byBwdXQgdGhlbSBp biB0aGUgU0RQPGJyPg0KJmd0OyB3aXRob3V0IGZpcnN0IHJlc29sdmluZyBpZiB0aGF0IHdvdWxk IGJlIFBsYW4gQSBTRFAgb3IgUGxhbiBCIFNEUC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtIEp1c3Qg bGlrZSBwaWxlcyBvZiBhdHRyaWJ1dGVzIHdvdWxkIG5lZWQgdG8gYmUgZGVmaW5lZCBmb3IgUGxh biBBIGFuZDxicj4NCiZndDsgZm9yIFBsYW4gQiwgc2ltaWxhciBhdHRyaWJ1dGVzIHdvdWxkIG5l ZWQgdG8gYmUgZGVmaW5lZCBoZXJlIChMdWNraWx5LDxicj4NCiZndDsgJm5ic3A7IG11Y2ggd29y ayBoYXMgYWxyZWFkeSBiZWVuIGRvbmUgZmlndXJpbmcgb3V0IHdoYXQgdGhvc2UgcGFyYW1ldGVy cyBhcmUgOikuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFByb3M6PGJyPg0KJmd0Ozxi cj4NCiZndDsgLSBFaXRoZXIgUGxhbiBBIG9yIFBsYW4gQiBvciBjb3VsZCBiZSBpbXBsZW1lbnRl ZCBpbiBKYXZhc2NyaXB0IHVzaW5nPGJyPg0KJmd0OyB0aGlzIEFQSTxicj4NCiZndDsgLSBJdCBl eHBvc2VzIGFsbCB0aGUgc2FtZSBmdW5jdGlvbmFsaXR5IHRvIHRoZSBKYXZhc2NyaXB0IGFzIFNE UCwgYnV0IGluPGJyPg0KJmd0OyBhIG11Y2ggbmljZXIgZm9ybWF0IHRoYXQgaXMgbXVjaCBlYXNp ZXIgdG8gd29yayB3aXRoLjxicj4NCiZndDsgLSBBbnkgb3RoZXIgc2lnbmFsbGluZyBtZWNoYW5p c20sIHN1Y2ggYXMgSmluZ2xlIG9yIENMVUUgY291bGQgYmU8YnI+DQomZ3Q7IGltcGxlbWVudGVk IHVzaW5nIHRoaXMgQVBJLjxicj4NCiZndDsgLSBUaGVyZSBpcyBhbG1vc3Qgbm8gcmlzayBvZiBz aWduYWxsaW5nIGdsYXJlLjxicj4NCiZndDsgLSBEZWJ1Z2dpbmcgZXJyb3JzIHdpdGggbWlzY29u ZmlndXJlZCBkZXNjcmlwdGlvbnMgc2hvdWxkIGJlIG11Y2ggZWFzaWVyPGJyPg0KJmd0OyB3aXRo IHRoaXMgdGhhbiB3aXRoIGxhcmdlIFNEUCBibG9icy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgQ29uczo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtIE5vdyB0aGVyZSBhcmUgdHdvIHNsaWdo dGx5IGRpZmZlcmVudCB3YXlzIHRvIGFkZCBzdHJlYW1zOiBieSBjcmVhdGluZzxicj4NCiZndDsg YSBMb2NhbE1lZGlhU3RyZWFtIGZpcnN0LCBhbmQgbm90LiAmbmJzcDtUaGlzIGlzLCBob3dldmVy LCBhbmFsb2dvdXMgdG88YnI+DQomZ3Q7IHNldHRpbmcgJnF1b3Q7bmVnb3RpYXRlZDogdHJ1ZSZx dW90OyBpbiBjcmVhdGVEYXRhQ2hhbm5lbC4gJm5ic3A7T24gd2F5IGlzICZxdW90O0p1c3QgV29y ayZxdW90Oyw8YnI+DQomZ3Q7IGFuZCB0aGUgb3RoZXIgaXMgbW9yZSBhZHZhbmNlZCBjb250cm9s Ljxicj4NCiZndDs8YnI+DQomZ3Q7IC0gQWxsIHRoZSBvcHRpb25zIGluIE1lZGlhQ29kZWNEZXNj cmlwdGlvbiBhcmUgYSBiaXQgY29tcGxpY2F0ZWQuPGJyPg0KJmd0OyAmbmJzcDsgUmVhbGx5LCB0 aGlzIGlzIG9ubHkgbmVjZXNzYXJ5IGJlY2F1c2UgUGxhbiBBIHJlcXVpcmVzIGJlaW5nIGFibGUg dG88YnI+DQomZ3Q7IHNwZWNpZnkgY29kZWMgcGFyYW1ldGVycyBwZXIgU1NSQywgYW5kIHNldCBl YWNoIGZsb3cgb24gZGlmZmVyZW50PGJyPg0KJmd0OyB0cmFuc3BvcnRzLiAmbmJzcDtJZiB3ZSBk aWQgbm90IGhhdmUgdGhpcyByZXF1aXJlbWVudCwgd2UgY291bGQgc2ltcGxpZnkuPGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEV4YW1wbGUgVXNhZ2U6PGJyPg0KJmd0Ozxicj4NCiZndDsg Ly8gSW1hZ2luZSBJIGhhdmUgTXlBcHAsIGhhbmRsZXMgY3JlYXRpbmcgYSBQZWVyQ29ubmVjdGlv biw8YnI+DQomZ3Q7IC8vIHNpZ25hbGxpbmcsIGFuZCByZW5kZXJpbmcgc3RyZWFtcy4gJm5ic3A7 VGhpcyBpcyBob3cgdGhlIG5ldyBBUEkgY291bGQgYmU8YnI+DQomZ3Q7IC8vIHVzZWQuPGJyPg0K Jmd0OyB2YXIgcGVlckNvbm5lY3Rpb24gPSBNeUFwcC5jcmVhdGVQZWVyQ29ubmVjdGlvbigpOzxi cj4NCiZndDs8YnI+DQomZ3Q7IC8vIE9uIHNlbmRlciBzaWRlOjxicj4NCiZndDsgdmFyIHN0cmVh bSA9IE15QXBwLmdldE1lZGlhU3RyZWFtKCk7PGJyPg0KJmd0OyB2YXIgbG9jYWxTdHJlYW0gPSBw ZWVyQ29ubmVjdGlvbi5jcmVhdGVTZW5kU3RyZWFtKHN0cmVhbSk7PGJyPg0KJmd0OyBzZW5kU3Ry ZWFtLmRlc2NyaXB0aW9uID0gTXlBcHAubW9kaWZ5U3RyZWFtKGxvY2FsU3RyZWFtLmRlc2NyaXB0 aW9uKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlNob3VsZCBpdCBzYXkgJnF1b3Q7bG9jYWxTdHJlYW0uZGVzY3JpcHRpb24mcXVvdDs/PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Z ZXMuIFRoZXJlIHdhcyBhIGxhc3QtbWludXRlIHJlbmFtZSBhbmQgSSBtaXNzZWQgYSBzcG90LiAm bmJzcDtBbnl3aGVyZSB5b3Ugc2VlICZxdW90O3NlbmRTdHJlYW0mcXVvdDssIGl0IHNob3VsZCBi ZSAmcXVvdDtsb2NhbFN0cmVhbSZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxicj4NCiZndDsgTXlBcHAuc2lnbmFsQWRkU3RyZWFtKGxvY2FsU3Ry ZWFtLmRlc2NyaXB0aW9uLCBmdW5jdGlvbihyZXNwb25zZSkpIHs8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDtpZiAoIXJlc3BvbnNlLnJlamVjdGVkKSB7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOy8vIE1lZGlhIHdpbGwgbm90IGJlIHNlbnQuPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwO3BlZXJDb25uZWN0aW9uLmFkZFN0cmVhbShsb2NhbFN0cmVhbSk7PGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7fTxicj4NCiZndDsgfTxicj4NCiZndDs8YnI+DQomZ3Q7IC8vIE9uIHJlY2VpdmVy IHNpZGU6PGJyPg0KJmd0OyBNeUFwcC5vbkFkZFN0cmVhbVNpZ25hbGxlZCA9IGZ1bmN0aW9uKHN0 cmVhbURlc2NyaXB0aW9uKSB7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7dmFyIHN0cmVhbSA9IHBl ZXJDb25uZWN0aW9uLmNyZWF0ZVJlY2VpdmVTdHJlYW0oc3RyZWFtRGVzY3JpcHRpb24pOzxicj4N CiZndDsgJm5ic3A7ICZuYnNwO015QXBwLnJlbmRlclN0cmVhbShzdHJlYW0pOzxicj4NCiZndDsg fTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAvLyBJbiB0aGlzIGV4Y2hhbmdlLCB0aGUg TWVkaWFTdHJlYW1EZXNjcmlwdGlvbiBzaWduYWxsZWQgZnJvbSB0aGU8YnI+DQomZ3Q7IC8vIHNl bmRlciB0byB0aGUgcmVjZWl2ZXIgbWF5IGhhdmUgbG9va2VkIHNvbWV0aGluZyBsaWtlIHRoaXM6 PGJyPg0KJmd0Ozxicj4NCiZndDsgezxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3RyYWNrczogWzxi cj4NCiZndDsgJm5ic3A7ICZuYnNwO3s8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aWQ6 ICZxdW90O2F1ZGlvMSZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7a2luZDog JnF1b3Q7YXVkaW8mcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Zsb3dzOiBb PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3s8YnI+DQomZ3Q7IGlkOiAmcXVvdDttYWlu JnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHJhbnNwb3J0SWQ6 ICZxdW90O3RyYW5zcG9ydDEmcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtzc3JjOiAxMTExLDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29k ZWNzOiBbPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt7PGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGF5bG9hZFR5cGU6IDExMSw8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtuYW1lOiAmcXVvdDtvcHVzJnF1 b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy8vIC4uLiBt b3JlIGNvZGVjIGRldGFpbHM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO30s PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt7PGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGF5bG9hZFR5cGU6IDExMiw8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtuYW1lOiAmcXVvdDtwY211JnF1b3Q7LDxi cj4NCiZndDsgLy8gLi4uIG1vcmUgY29kZWMgZGV0YWlsczxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7fV08YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfV08YnI+DQomZ3Q7ICZu YnNwOyB9LDxicj4NCiZndDsgJm5ic3A7IHs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 aWQ6ICZxdW90O3ZpZGVvMSZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7a2lu ZDogJnF1b3Q7dmlkZW8mcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Zsb3dz OiBbPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3s8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2lkOiAmcXVvdDtzaW0wJnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7dHJhbnNwb3J0SWQ6ICZxdW90O3RyYW5zcG9ydDImcXVvdDssPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzc3JjOiAyMjIyLDxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29kZWNzOiBbPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7cGF5bG9hZFR5cGU6IDEyMiw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtuYW1lOiAmcXVvdDt2cDgmcXVvdDs8YnI+DQomZ3Q7IC8vIC4uLiBtb3JlIGNv ZGVjIGRldGFpbHM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO31dPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7IH0sPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHs8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlkOiAmcXVvdDtzaW0xJnF1b3Q7LDxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgdHJhbnNwb3J0SWQ6ICZxdW90O3RyYW5zcG9ydDImcXVvdDssPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzc3JjOiAyMjIzLDxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgY29kZWNzOiBbPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB7 PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcGF5bG9hZFR5cGU6IDEyMiw8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBuYW1lOiAmcXVvdDt2cDgmcXVv dDssPGJyPg0KJmd0OyAvLyAuLi4gbW9yZSBjb2RlYyBkZXRhaWxzPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB9XTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB9LDxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyB7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpZDogJnF1b3Q7c2lt MiZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRyYW5zcG9ydElkOiAmcXVv dDt0cmFuc3BvcnQyJnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc3NyYzog MjIyNCw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvZGVjczogWzxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgezxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHBheWxvYWRUeXBlOiAxMjIsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgbmFtZTogJnF1b3Q7dnA4JnF1b3Q7LDxicj4NCiZndDsgLy8gLi4uIG1vcmUgY29kZWMgZGV0 YWlsczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfV08YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgfSw8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHs8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IGlkOiAmcXVvdDtzaW0wZmVjJnF1b3Q7LDxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgdHJhbnNwb3J0SWQ6ICZxdW90O3RyYW5zcG9ydDImcXVvdDssPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzc3JjOiAyMjI1LDxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgY29kZWNzOiBbPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB7 PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcGF5bG9hZFR5cGU6IDEyMiw8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBuYW1lOiAmcXVvdDt2cDgmcXVv dDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLy8gLi4uPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB9XTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB9XSw8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgZmxvd0dyb3VwczogWzxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyB7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzZW1hbnRpY3M6ICZxdW90O1NJTSZx dW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNzcmNzOiBbMjIyMiwgMjIyMywg MjIyNF08YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfSw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg ezxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2VtYW50aWNzOiAmcXVvdDtGRUMmcXVv dDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzc3JjczogWzIyMjIsIDIyMjVdPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7IH1dPGJyPg0KJmd0OyAmbmJzcDsgfV08YnI+DQomZ3Q7IH08 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQ29uc3RydWN0aXZlIGZlZWRiYWNrIGlzIHdl bGNvbWUgOikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_57A15FAF9E58F841B2B1651FFE16D28104C918GENSJZMBX01msgint_-- From pthatcher@google.com Mon Jun 17 09:21:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCAB21F9AAA for ; Mon, 17 Jun 2013 09:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukrHHmeloYLK for ; Mon, 17 Jun 2013 09:21:33 -0700 (PDT) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by ietfa.amsl.com (Postfix) with ESMTP id 983D421F99AB for ; Mon, 17 Jun 2013 09:21:33 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id 10so2927805pdc.5 for ; Mon, 17 Jun 2013 09:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8QU1U9Bl0ZItHk2Xwynz3weM+QaHwUDeRWrhRHlR0Mo=; b=lPmfHEx/qW0vWhZq7E3D6JUt95gQ0RvzVJgZpgdPqiLLwq3FXSwbLZKz8k0z3YnAxF 0KT8VcEFw5WqpEtVEVl1fgDmMJwDaWKz0PAKGZCI3M9fJHy/0fjbo8Sohn5VnxLBx5Io tdWt2uXs6GYm6Ltus9XZCSuPhk7JRnxpoTVJ+SIMauYnS2f7TcYVxKYX6WdemXTnp1Mz vxung60L6qznhFTMIjEo3ffItBI9006mAwYAaQpBAv1hXwrp+Z5k74MOVdS93XQAw8Cq VNDmMfPYM/Pqg7qPwkdzHV5Hx230i6/2nIFaXNpnUnWjzsuBtLTvQMOpiky+7pBMxEPE /ZzA== 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=8QU1U9Bl0ZItHk2Xwynz3weM+QaHwUDeRWrhRHlR0Mo=; b=lTeIj/490ecSLfaTdI4XhNP6CXBvHSfExRY3qvCEfeElMc5AsAZ7GiBe6wcKaxgEes jG4ryUASPUlKOgUA+Sx5+JBtcz/WMtb+cWymeOi+apWyCB5zQz7PVdpSHKeenRt4caew lrPToV/FhdEUcCRhdFMB05zrUAMJPrggx/P0PFwOW/lrWPG8yhW7XFYbvdvnVFudZwRI iuWoJQY+iWaZ3XDoTFZN3/Rh7piDEDng0zu8nHe3UZDHsd41+bx8rsfKqn1q/8XWqjKt 4RhU4aMO1Q+cV5+zEZxI6m4iP6sMkQNxsmE6Bea7guW6NYBnoPhXMsvpc3F5ali+aV0i kwXQ== X-Received: by 10.68.164.97 with SMTP id yp1mr5196397pbb.77.1371486093103; Mon, 17 Jun 2013 09:21:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Mon, 17 Jun 2013 09:20:52 -0700 (PDT) In-Reply-To: <57A15FAF9E58F841B2B1651FFE16D28104C918@GENSJZMBX01.msg.int.genesyslab.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C2FC071@ESESSMB209.ericsson.se> <57A15FAF9E58F841B2B1651FFE16D28104C918@GENSJZMBX01.msg.int.genesyslab.com> From: Peter Thatcher Date: Mon, 17 Jun 2013 09:20:52 -0700 Message-ID: To: Jim Barnett Content-Type: multipart/alternative; boundary=047d7bae446e64f5cc04df5bfdfe X-Gm-Message-State: ALoCoQkVExLa4g2SRuxMzTKbntyoMnAx3fjslgA6FoCBuL1hUzCGCUt/STb6Y6sET42BgD0g+pvqqOJD2EMLgjIC2ls8P4qZIQThc6TWszxWgCEVJNphnqaHf3Zl/jnqaiWrGYZ0vmEk71AfnYd+uIIqIgvg3lImaGQvoRotLq/lt6TjuS9W0agXc4psvdZ71KgmMiP7G0Ij Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 16:21:38 -0000 --047d7bae446e64f5cc04df5bfdfe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 17, 2013 at 8:21 AM, Jim Barnett wr= ote: > What can you modify in a LocalMediaStream by editing its description? > Can you add a video track to it? That would imply calling gUM, and you= =E2=80=99d > have to thread it=E2=80=99s success and failure callbacks up to the editi= ng > operation. Or is the track list fixed, so that you can only tweak > transport info by editing the LocalMediaStream=E2=80=99s description?**** > > ** > If the JS calls gUM to get a second MediaStreamTrack (say, for screencast), it could simply call createLocalStream again to add it, in a different LocalMediaStream, and the remote end would get a second MediaStream by calling createRemoteStream. Why would you want more than one video MediaStreamTrack in MediaStream at the same time? In general, before you start sending or receiving, you can edit everything side of the MediaStreamTrackDescription: change the ssrcs, codecs, transport, video resolution to send with, what repair flows to include, whether to use simulcast, etc. Basically, anything on a track level. But I don't really see a use case where you would need to add tracks to a MediaStreamTrackDescription, other than when parsing signalling and building the MediaStreamTrackDescription to send down into createRemoteStream. Perhaps if we had a use case, we could define such support. But otherwise, I'd say it's not allowed. - **Jim**** ** ** *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Peter Thatcher *Sent:* Monday, June 17, 2013 11:13 AM *To:* Stefan H=C3=A5kansson LK *Cc:* *Subject:* Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)**** ** ** Answers:**** ** ** On Mon, Jun 17, 2013 at 6:58 AM, Stefan H=C3=A5kansson LK < stefan.lk.hakansson@ericsson.com> wrote:**** A couple of questions (to help me understand) in-line //Stefan**** On 2013-06-17 14:57, Peter Thatcher wrote: > Google is in full support of "Plan B" for encoding multiple media > sources in SDP, and would like to see the Plan A vs. Plan B decision > resolved soon. Recently, though, a third option, called "NoPlan" has > been proposed, but it lacked the details of what a JS API would look > like for NoPlan. Cullen asked to see such an API proposal, and so I > have worked with Emil to make one. He will be adding it to the NoPlan > draft, but I will also include it in this email. > > Again, Google is in full support of "Plan B". But if Plan A vs. Plan B > cannot be decided, then we support NoPlan with the following additions > to the WebRTC JS API as an option that allows implementing either Plan A > or Plan B in Javascript. And even if Plan A vs. Plan B is resolved, > these API additions would still be a big improvement for those WebRTC > applications that don't use SDP for signalling. > > It is a bit long because I have added many comments and examples, but > the actually additions only include two new methods on PeerConnection > and a few new dictionaries. So don't be overwhelmed :). > > > > Intro: This follows the model of createDataChannel, which has a JS > method on PeerConnection that makes it possible to add data channels > without going through SDP. Furthermore, just like createDataChannel > allows 2 ways to handle neogitation (the "I know what I'm doing; Here's > what I want to send; Let me signal everything" mode and the "please take > care of it for me; send an OPEN message" mode), this also has 2 ways to > handle negotiation (the "I know what I'm doing; Here's what I want to > send; Let me signal everything" mode and the "please take care of it for > me; send SDP back and forth" mode). > > Following the success of createDataChannel, this allows simple > applications to Just Work and more advanced applications to easily > control what they need to. In particular, it's possible to use this API > to implement either Plan A or Plan B. > > // The following two method are added to RTCPeerConnection > partial interface RTCPeerConnection { > // Create a stream that is used to send a source stream. > // The MediaSendStream.description can be used for signalling. > // No media is sent until addStream(MediaSendStream) is called. > LocalMediaStream createLocalStream(MediaStream sourceStream); > > // Create a stream that is used to receive media from the remote side, > // given the parameters signalled from MedaiSendStream.description. > MediaStream createRemoteStream(MediaStreamDescription description); > }**** what would happen if the application adds or removes a track from sourceStream (I'm thinking on how what would impact the created LocalMediaStream and the MediaStream at the remote end)?**** ** ** ** ** Good question. I'd have to think about it some more, but off the bat, I'd say that on the sender side, adding or removing tracks from the source MediaStream would have no effect on what is sent. In other words, it's as if the source MediaStream were cloned when createLocalStream was called. If you want to modify the LocalStream, you have to go through the .description. On the receiver side, it would look like any other received MediaStream: if you remove the track, it just doesn't play out anymore.**** ** ** **** > > > interface LocalMediaStream implements MediaStream { > // This can be changed at any time, but especially before calling > // PeerConnection.addStream > attribute MediaStreamDescription description; > } > > > // Represents the parameters used to either send or receive a stream > // over a PeerConnection. > dictionary MediaStreamDescription { > MediaStreamTrackDescription[] tracks; > } > > > // Represents the parameters used to either send or receive a track over > // a PeerConnection. A track has many "flows", which can be grouped > // together. > dictionary MediaStreamTrackDescription { > // Same as the MediaStreamTrack.id > DOMString id; > > // Same as the MediaStreamTrack.kind > DOMString kind; > > // A track can have many "flows", such as for Simulcast, FEC, etc. > // And they can be grouped in arbitrary ways. > MediaFlowDescription[] flows; > MediaFlowGroup[] flowGroups; > } > > // Represents the parameters used to either send or receive a "flow" > // over a PeerConnection. A "flow" is a media that arrives with a > // single, unique SSRC. One to many flows together make up the media > // for a track. For example, there may be Simulcast, FEC, and RTX > // flows. > dictionay MediaFlowDescription { > // The "flow id" must be unique to the track, but need not be unique > // outside of the track (two tracks could both have a flow with the > // same flow ID). > DOMString id; > > // Each flow can go over its own transport. If the JS sets this to a > // transportId that doesn't have a transport setup already, the > // browser will use SDP negotiation to setup a transport to back that > // transportId. If This is set to an MID in the SDP, then that MID's > // transport is used. > DOMString transportId;**** Where from do you get transportId (e.g. if you want to re-use one)?**** ** ** First, the browser would fill it in via createLocalStream. So in almost all cases, the JS would not need to set it. In very advanced applications that want to do tricky things with transports, then the value should be the MID for that transport found in the SDP, as it says in the comment. **** **** > > // The SSRC used to send the flow. > unsigned int ssrc; > > // When used as receive parameters, this indicates the possible list > // of codecs that might come in for this flow. For exmample, a given > // receive flow could be setup to receive any of OPUS, ISAC, or PCMU. > // When used as send parameters, this indicates that the first codec > // should be used, but the browser can use send other codecs if it > // needs to because of either bandwidth or CPU constraints. > MediaCodecDescription[] codecs; > } > > > dictionary MediaFlowGroup { > DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc > DOMString[] flowids; > } > > dictionary MediaCodecDescription { > unsigned byte payloadType; > DOMString name; > unsigned int? clockRate; > unsigned int? bitRate; > // A grab bag of other fmtp that will need to be further defined. > MediaCodecParam[] params; > } > > dictionary MediaCodecParam { > DOMString key; > DOMString value; > } > > > Notes: > > - When LocalMediaStreams are added using addStream, onnegotiatedneeded > is not called, and those streams are never reflected in future SDP > exchanges. Indeed, it would be impossible to put them in the SDP > without first resolving if that would be Plan A SDP or Plan B SDP. > > - Just like piles of attributes would need to be defined for Plan A and > for Plan B, similar attributes would need to be defined here (Luckily, > much work has already been done figuring out what those parameters are :). > > > Pros: > > - Either Plan A or Plan B or could be implemented in Javascript using > this API > - It exposes all the same functionality to the Javascript as SDP, but in > a much nicer format that is much easier to work with. > - Any other signalling mechanism, such as Jingle or CLUE could be > implemented using this API. > - There is almost no risk of signalling glare. > - Debugging errors with misconfigured descriptions should be much easier > with this than with large SDP blobs. > > > Cons: > > - Now there are two slightly different ways to add streams: by creating > a LocalMediaStream first, and not. This is, however, analogous to > setting "negotiated: true" in createDataChannel. On way is "Just Work", > and the other is more advanced control. > > - All the options in MediaCodecDescription are a bit complicated. > Really, this is only necessary because Plan A requires being able to > specify codec parameters per SSRC, and set each flow on different > transports. If we did not have this requirement, we could simplify. > > > Example Usage: > > // Imagine I have MyApp, handles creating a PeerConnection, > // signalling, and rendering streams. This is how the new API could be > // used. > var peerConnection =3D MyApp.createPeerConnection(); > > // On sender side: > var stream =3D MyApp.getMediaStream(); > var localStream =3D peerConnection.createSendStream(stream); > sendStream.description =3D MyApp.modifyStream(localStream.description)***= * Should it say "localStream.description"?**** ** ** Yes. There was a last-minute rename and I missed a spot. Anywhere you see "sendStream", it should be "localStream".**** **** > MyApp.signalAddStream(localStream.description, function(response)) { > if (!response.rejected) { > // Media will not be sent. > peerConnection.addStream(localStream); > } > } > > // On receiver side: > MyApp.onAddStreamSignalled =3D function(streamDescription) { > var stream =3D peerConnection.createReceiveStream(streamDescription); > MyApp.renderStream(stream); > } > > > // In this exchange, the MediaStreamDescription signalled from the > // sender to the receiver may have looked something like this: > > { > tracks: [ > { > id: "audio1", > kind: "audio", > flows: [ > { > id: "main", > transportId: "transport1", > ssrc: 1111, > codecs: [ > { > payloadType: 111, > name: "opus", > // ... more codec details > }, > { > payloadType: 112, > name: "pcmu", > // ... more codec details > }] > }] > }, > { > id: "video1", > kind: "video", > flows: [ > { > id: "sim0", > transportId: "transport2", > ssrc: 2222, > codecs: [ > { > payloadType: 122, > name: "vp8" > // ... more codec details > }] > }, > { > id: "sim1", > transportId: "transport2", > ssrc: 2223, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... more codec details > }] > }, > { > id: "sim2", > transportId: "transport2", > ssrc: 2224, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... more codec details > }] > }, > > { > id: "sim0fec", > transportId: "transport2", > ssrc: 2225, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... > }] > }], > flowGroups: [ > { > semantics: "SIM", > ssrcs: [2222, 2223, 2224] > }, > { > semantics: "FEC", > ssrcs: [2222, 2225] > }] > }] > } > > > Constructive feedback is welcome :).**** ** ** --047d7bae446e64f5cc04df5bfdfe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Mon, Jun 17, 2013 at 8:21 AM, Jim Barnett <= Jim.Barnett= @genesyslab.com> wrote:

    What can you modify in a LocalMediaStream by editing = its description?=C2=A0 Can you add a video track to it?=C2=A0 That would im= ply calling gUM, and you=E2=80=99d=C2=A0 have to thread it=E2=80=99s success and failure callbacks up to the editing operation.=C2= =A0 Or is the track list fixed, so that you can only tweak transport info b= y editing the LocalMediaStream=E2=80=99s description?<= /p>

    =C2=A0


    If the JS calls gUM to get a second MediaStreamTrack (say, = for screencast), it could simply call createLocalStream again to add it, in= a different LocalMediaStream, and the remote end would get a second MediaS= tream by calling createRemoteStream. =C2=A0Why would you want more than one= video MediaStreamTrack in MediaStream at the same time?

    In general, before you start sending or receiving, you = can edit everything side of the MediaStreamTrackDescription: =C2=A0change t= he ssrcs, codecs, transport, video resolution to send with, what repair flo= ws to include, whether to use simulcast, etc. =C2=A0Basically, anything on = a track level.

    But I don't really see a use case where you would n= eed to add tracks to a MediaStreamTrackDescription, other than when parsing= signalling and building the MediaStreamTrackDescription to send down into = createRemoteStream. =C2=A0Perhaps if we had a use case, we could define suc= h support. =C2=A0But otherwise, I'd say it's not allowed.


    =

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

    =C2=A0

    From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Peter Thatcher
    Sent: Monday, June 17, 2013 11:13 AM
    To: Stefan H=C3=A5kansson LK
    Cc: <rtcweb@= ietf.org>
    Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multi= ple sources without encoding them in SDP)

    =C2=A0

    Answers:

    =C2=A0

    On Mon, Jun 17, 2013 at 6:58 AM, Stefan H=C3=A5kansson LK <= ;stef= an.lk.hakansson@ericsson.com> wrote:

    A couple of questions (to help me understand) in-line //Stefa= n


    On 2013-06-17 14:57, Peter Thatcher wrote:
    > Google is in full support of "Plan B" for encoding multiple = media
    > sources in SDP, and would like to see the Plan A vs. Plan B decision > resolved soon. =C2=A0Recently, though, a third option, called "No= Plan" has
    > been proposed, but it lacked the details of what a JS API would look > like for NoPlan. =C2=A0Cullen asked to see such an API proposal, and s= o I
    > have worked with Emil to make one. =C2=A0He will be adding it to the N= oPlan
    > draft, but I will also include it in this email.
    >
    > Again, Google is in full support of "Plan B". =C2=A0But if P= lan A vs. Plan B
    > cannot be decided, then we support NoPlan with the following additions=
    > to the WebRTC JS API as an option that allows implementing either Plan= A
    > or Plan B =C2=A0in Javascript. =C2=A0And even if Plan A vs. Plan B is = resolved,
    > these API additions would still be a big improvement for those WebRTC<= br> > applications that don't use SDP for signalling.
    >
    > It is a bit long because I have added many comments and examples, but<= br> > the actually additions only include two new methods on PeerConnection<= br> > and a few new dictionaries. =C2=A0So don't be overwhelmed :).
    >
    >
    >
    > Intro: This follows the model of createDataChannel, which has a JS
    > method on PeerConnection that makes it possible to add data channels > without going through SDP. =C2=A0Furthermore, just like createDataChan= nel
    > allows 2 ways to handle neogitation (the "I know what I'm doi= ng; =C2=A0Here's
    > what I want to send; Let me signal everything" mode and the "= ;please take
    > care of it for me; =C2=A0send an OPEN message" mode), this also h= as 2 ways to
    > handle negotiation (the "I know what I'm doing; Here's wh= at I want to
    > send; Let me signal everything" mode and the "please take ca= re of it for
    > me; =C2=A0send SDP back and forth" mode).
    >
    > Following the success of createDataChannel, this allows simple
    > applications to Just Work and more advanced applications to easily
    > control what they need to. =C2=A0In particular, it's possible to u= se this API
    > to implement either Plan A or Plan B.
    >
    > // The following two method are added to RTCPeerConnection
    > partial interface RTCPeerConnection {
    > =C2=A0 // Create a stream that is used to send a source stream.
    > =C2=A0 // The MediaSendStream.description can be used for signalling.<= br> > =C2=A0 // No media is sent until addStream(MediaSendStream) is called.=
    > =C2=A0 LocalMediaStream createLocalStream(MediaStream sourceStream); >
    > =C2=A0 // Create a stream that is used to receive media from the remot= e side,
    > =C2=A0 // given the parameters signalled from MedaiSendStream.descript= ion.
    > =C2=A0 MediaStream createRemoteStream(MediaStreamDescription descripti= on);
    > }

    what would happen if the application adds or removes a track = from
    sourceStream (I'm thinking on how what would impact the created
    LocalMediaStream and the MediaStream at the remote end)?

    =C2=A0

    =C2=A0

    Good question. =C2=A0I'd have to think about it some more= , but off the bat, I'd say that on the sender side, adding or removing = tracks from the source MediaStream would have no effect on what is sent. = =C2=A0In other words, it's as if the source MediaStream were cloned when createLocalStream was called. =C2=A0If you want to modify= the LocalStream, you have to go through the .description. =C2=A0 On the re= ceiver side, it would look like any other received MediaStream: if you remo= ve the track, it just doesn't play out anymore.

    =C2=A0

    =C2=A0

    >
    >
    > interface LocalMediaStream implements MediaStream {
    > =C2=A0 =C2=A0// This can be changed at any time, but especially before= calling
    > =C2=A0 =C2=A0// PeerConnection.addStream
    > =C2=A0 =C2=A0attribute MediaStreamDescription description;
    > }
    >
    >
    > // Represents the parameters used to either send or receive a stream > // over a PeerConnection.
    > dictionary MediaStreamDescription {
    > =C2=A0 =C2=A0MediaStreamTrackDescription[] tracks;
    > }
    >
    >
    > // Represents the parameters used to either send or receive a track ov= er
    > // a PeerConnection. =C2=A0A track has many "flows", which c= an be grouped
    > // together.
    > dictionary MediaStreamTrackDescription {
    > =C2=A0 =C2=A0// Same as the MediaStreamTrack.id
    > =C2=A0 =C2=A0DOMString id;
    >
    > =C2=A0 =C2=A0// Same as the MediaStreamTrack.kind
    > =C2=A0 =C2=A0DOMString kind;
    >
    > =C2=A0 =C2=A0// A track can have many "flows", such as for S= imulcast, FEC, etc.
    > =C2=A0 =C2=A0// And they can be grouped in arbitrary ways.
    > =C2=A0 =C2=A0MediaFlowDescription[] flows;
    > =C2=A0 =C2=A0MediaFlowGroup[] flowGroups;
    > }
    >
    > // Represents the parameters used to either send or receive a "fl= ow"
    > // over a PeerConnection. =C2=A0A "flow" is a media that arr= ives with a
    > // single, unique SSRC. =C2=A0One to many flows together make up the m= edia
    > // for a track. =C2=A0For example, there may be Simulcast, FEC, and RT= X
    > // flows.
    > dictionay MediaFlowDescription {
    > =C2=A0 =C2=A0// The "flow id" must be unique to the track, b= ut need not be unique
    > =C2=A0 =C2=A0// outside of the track (two tracks could both have a flo= w with the
    > =C2=A0 =C2=A0// same flow ID).
    > =C2=A0 =C2=A0DOMString id;
    >
    > =C2=A0 =C2=A0// Each flow can go over its own transport. =C2=A0If the = JS sets this to a
    > =C2=A0 =C2=A0// transportId that doesn't have a transport setup al= ready, the
    > =C2=A0 =C2=A0// browser will use SDP negotiation to setup a transport = to back that
    > =C2=A0 =C2=A0// transportId. =C2=A0If This is set to an MID in the SDP= , then that MID's
    > =C2=A0 =C2=A0// transport is used.
    > =C2=A0 =C2=A0DOMString transportId;

    Where from do you get transportId (e.g. if you want to re-use= one)?

    =C2=A0

    First, the browser would fill it in via createLocalStream. = =C2=A0So in almost all cases, the JS would not need to set it. =C2=A0In ver= y advanced applications that want to do tricky things with transports, then= the value should be the MID for that transport found in the SDP, as it says in the comment.=C2=A0=

    =C2=A0


    >
    > =C2=A0 =C2=A0// The SSRC used to send the flow.
    > =C2=A0 =C2=A0unsigned int ssrc;
    >
    > =C2=A0 =C2=A0// When used as receive parameters, this indicates the po= ssible list
    > =C2=A0 =C2=A0// of codecs that might come in for this flow. =C2=A0For = exmample, a given
    > =C2=A0 =C2=A0// receive flow could be setup to receive any of OPUS, IS= AC, or PCMU.
    > =C2=A0 =C2=A0// When used as send parameters, this indicates that the = first codec
    > =C2=A0 =C2=A0// should be used, but the browser can use send other cod= ecs if it
    > =C2=A0 =C2=A0// needs to because of either bandwidth or CPU constraint= s.
    > =C2=A0 =C2=A0MediaCodecDescription[] codecs;
    > }
    >
    >
    > dictionary MediaFlowGroup {
    > =C2=A0 =C2=A0DOMString type; =C2=A0// "SIM" for Simulcast, &= quot;FEC" for FEC, etc
    > =C2=A0 =C2=A0DOMString[] flowids;
    > }
    >
    > dictionary MediaCodecDescription {
    > =C2=A0 =C2=A0unsigned byte payloadType;
    > =C2=A0 =C2=A0DOMString name;
    > =C2=A0 =C2=A0unsigned int? clockRate;
    > =C2=A0 =C2=A0unsigned int? bitRate;
    > =C2=A0 =C2=A0// A grab bag of other fmtp that will need to be further = defined.
    > =C2=A0 =C2=A0MediaCodecParam[] params;
    > }
    >
    > dictionary MediaCodecParam {
    > =C2=A0 =C2=A0DOMString key;
    > =C2=A0 =C2=A0DOMString value;
    > }
    >
    >
    > Notes:
    >
    > - When LocalMediaStreams are added using addStream, onnegotiatedneeded=
    > is not called, and those streams are never reflected in future SDP
    > exchanges. =C2=A0Indeed, it would be impossible to put them in the SDP=
    > without first resolving if that would be Plan A SDP or Plan B SDP.
    >
    > - Just like piles of attributes would need to be defined for Plan A an= d
    > for Plan B, similar attributes would need to be defined here (Luckily,=
    > =C2=A0 much work has already been done figuring out what those paramet= ers are :).
    >
    >
    > Pros:
    >
    > - Either Plan A or Plan B or could be implemented in Javascript using<= br> > this API
    > - It exposes all the same functionality to the Javascript as SDP, but = in
    > a much nicer format that is much easier to work with.
    > - Any other signalling mechanism, such as Jingle or CLUE could be
    > implemented using this API.
    > - There is almost no risk of signalling glare.
    > - Debugging errors with misconfigured descriptions should be much easi= er
    > with this than with large SDP blobs.
    >
    >
    > Cons:
    >
    > - Now there are two slightly different ways to add streams: by creatin= g
    > a LocalMediaStream first, and not. =C2=A0This is, however, analogous t= o
    > setting "negotiated: true" in createDataChannel. =C2=A0On wa= y is "Just Work",
    > and the other is more advanced control.
    >
    > - All the options in MediaCodecDescription are a bit complicated.
    > =C2=A0 Really, this is only necessary because Plan A requires being ab= le to
    > specify codec parameters per SSRC, and set each flow on different
    > transports. =C2=A0If we did not have this requirement, we could simpli= fy.
    >
    >
    > Example Usage:
    >
    > // Imagine I have MyApp, handles creating a PeerConnection,
    > // signalling, and rendering streams. =C2=A0This is how the new API co= uld be
    > // used.
    > var peerConnection =3D MyApp.createPeerConnection();
    >
    > // On sender side:
    > var stream =3D MyApp.getMediaStream();
    > var localStream =3D peerConnection.createSendStream(stream);
    > sendStream.description =3D MyApp.modifyStream(localStream.description)=

    Should it say "localStream.description"?<= /u>

    =C2=A0

    Yes. There was a last-minute rename and I missed a spot. =C2= =A0Anywhere you see "sendStream", it should be "localStream&= quot;.

    =C2=A0


    > MyApp.signalAddStream(localStream.description, function(response)) { > =C2=A0 =C2=A0if (!response.rejected) {
    > =C2=A0 =C2=A0 =C2=A0// Media will not be sent.
    > =C2=A0 =C2=A0 =C2=A0peerConnection.addStream(localStream);
    > =C2=A0 =C2=A0}
    > }
    >
    > // On receiver side:
    > MyApp.onAddStreamSignalled =3D function(streamDescription) {
    > =C2=A0 =C2=A0var stream =3D peerConnection.createReceiveStream(streamD= escription);
    > =C2=A0 =C2=A0MyApp.renderStream(stream);
    > }
    >
    >
    > // In this exchange, the MediaStreamDescription signalled from the
    > // sender to the receiver may have looked something like this:
    >
    > {
    > =C2=A0 =C2=A0tracks: [
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0id: "audio1",
    > =C2=A0 =C2=A0 =C2=A0kind: "audio",
    > =C2=A0 =C2=A0 =C2=A0flows: [
    > =C2=A0 =C2=A0 =C2=A0{
    > id: "main",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0transportId: "transport1",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0ssrc: 1111,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0codecs: [
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 111,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "opus",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0},
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 112,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "pcmu",
    > // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0}]
    > =C2=A0 =C2=A0 }]
    > =C2=A0 },
    > =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0id: "video1",
    > =C2=A0 =C2=A0 =C2=A0kind: "video",
    > =C2=A0 =C2=A0 =C2=A0flows: [
    > =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0id: "sim0",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0ssrc: 2222,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0codecs: [
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "vp8"
    > // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0}]
    > =C2=A0 =C2=A0 },
    > =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 id: "sim1",
    > =C2=A0 =C2=A0 =C2=A0 transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0 ssrc: 2223,
    > =C2=A0 =C2=A0 =C2=A0 codecs: [
    > =C2=A0 =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 name: "vp8",
    > // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 }]
    > =C2=A0 =C2=A0 },
    > =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 id: "sim2",
    > =C2=A0 =C2=A0 =C2=A0 transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0 ssrc: 2224,
    > =C2=A0 =C2=A0 =C2=A0 codecs: [
    > =C2=A0 =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 name: "vp8",
    > // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 }]
    > =C2=A0 =C2=A0 },
    >
    > =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 id: "sim0fec",
    > =C2=A0 =C2=A0 =C2=A0 transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0 ssrc: 2225,
    > =C2=A0 =C2=A0 =C2=A0 codecs: [
    > =C2=A0 =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 name: "vp8",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ...
    > =C2=A0 =C2=A0 =C2=A0 }]
    > =C2=A0 =C2=A0 }],
    > =C2=A0 =C2=A0 flowGroups: [
    > =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 semantics: "SIM",
    > =C2=A0 =C2=A0 =C2=A0 ssrcs: [2222, 2223, 2224]
    > =C2=A0 =C2=A0 },
    > =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 semantics: "FEC",
    > =C2=A0 =C2=A0 =C2=A0 ssrcs: [2222, 2225]
    > =C2=A0 =C2=A0 }]
    > =C2=A0 }]
    > }
    >
    >
    > Constructive feedback is welcome :).

    =C2=A0


    --047d7bae446e64f5cc04df5bfdfe-- From ibc@aliax.net Mon Jun 17 09:35:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E7221F9D61 for ; Mon, 17 Jun 2013 09:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VenwIcFKg+ZB for ; Mon, 17 Jun 2013 09:35:13 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 33D4821F9D59 for ; Mon, 17 Jun 2013 09:35:13 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id f14so1571035qak.7 for ; Mon, 17 Jun 2013 09:35:12 -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=KMxuL7EW57rNAuHzbshcvGiwyfYMDBnthb0j7kMT1Zc=; b=bHSFzU18XSUyTAh5mdklV87s6Xs8wpyUHLGmhmnqPPOf1T0ddpuPzH6evc9hKmL5dK xWKXq7ql202lylH+67kyMvB+MFEwFWNG8TPh30vI+8FSrswefL048FeGAeA2rsFCJeY2 LzNhgXiKDZdSdhoOwX/0mRJh8lV3S8katbzNOwq9Zcxg8uOytRx/tfjE7CeWSuCiu99V xyne9Bit5XrkF1q0r2tmEgG1Zv40SFYmpZdnC/ZOTZfocJbcToHwN19ziUOboDugZtZf Ac0EXWkSGMIMLHdbdDF8aiICUGYPJRK/zmXZe0sowK56nilo249bjJYnU8E0xuLEAz5Z DL1w== X-Received: by 10.229.25.5 with SMTP id x5mr2722783qcb.35.1371486912605; Mon, 17 Jun 2013 09:35:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Mon, 17 Jun 2013 09:34:52 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C2FC071@ESESSMB209.ericsson.se> <57A15FAF9E58F841B2B1651FFE16D28104C918@GENSJZMBX01.msg.int.genesyslab.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 17 Jun 2013 18:34:52 +0200 Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnxsH8uyt+Y/McNI/icjmHHgHaUTBGNAx0g1RIzUWki0C0OXOC5SIBetG3Lkv8Ms20lTBwb Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 16:35:15 -0000 2013/6/17 Peter Thatcher : > But I don't really see a use case where you would need to add tracks to a > MediaStreamTrackDescription, other than when parsing signalling and build= ing > the MediaStreamTrackDescription to send down into createRemoteStream. > Perhaps if we had a use case, we could define such support. But otherwis= e, > I'd say it's not allowed. Use case: - Start a session/call with just audio (no video requested to the user via getUserMedia). - Latter the user wants to add video. - For that a new getUserMedia(video: true) is requested. - Extract the video track from the obtained MediaStream and add it to the P= C. Hope this is an enough common use case. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Jun 17 09:53:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBA621F9D4B for ; Mon, 17 Jun 2013 09:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnl5zmE2Npsa for ; Mon, 17 Jun 2013 09:53:26 -0700 (PDT) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 00A8A21F9D48 for ; Mon, 17 Jun 2013 09:53:25 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id 1so1807957qee.26 for ; Mon, 17 Jun 2013 09:53:25 -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=uNe+j+isdNa9j7NhK11+pfaWiq1SdgldD/y5aRBToC4=; b=A9BrV7x7u7E0JGtYctkR11nwp57e1mySMDcCFtOLVVSqNcutqyC042LsrZCioSmVOx vRFwF7mJd/ImmK0yD+rO/k0lknlGdQxAhsIMoi6SNAPpmje5sd+M31JTgU7yl69wCho8 U1ieHoTxKkjkXo9Xhy1ErOocg15RZPeXKtExltZfOnzyK1Yyh2u+KX6tqjgPf7MtTrgj zt3T9MwjTPvdzLoL+EVCQS8w8YfYaeKueKnsnb3fR7LXbdZnFS/DhlC4w3jX/E/Vltg5 Y2Yq+CD168jfgYCs+Jd7dJlXSG+vpwPIMQ0nXbTdE1gRJv5CELeMRwkrdDbd440Adl5X FACQ== X-Received: by 10.49.35.233 with SMTP id l9mr21717749qej.23.1371488005361; Mon, 17 Jun 2013 09:53:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Mon, 17 Jun 2013 09:53:05 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 17 Jun 2013 18:53:05 +0200 Message-ID: To: Jim Barnett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlvpL5KE0eGAgs9LzC8kRb6j7X78fSD1ZF0hjcd9bOndD+xSwDTAQ1aFGkOVOaz+YF85GXj Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Why is required to have local streams before running ICE gathering? (another SDP limitation?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 16:53:31 -0000 Thanks to both, it seems what we need for implementing the desired feature. 2013/6/14 Jim Barnett : > You can call updateICE at any point. I also recall us agreeing to let yo= u specify the number of candidates, but it's not in the spec. If it gets ad= ded to updateICE then you would be able to specify the number of candidates= before setLocal. > > On Jun 14, 2013, at 10:01 AM, "Eric Rescorla" > wrote: > > > > > On Fri, Jun 14, 2013 at 4:53 AM, I=C3=B1aki Baz Castillo > wrote: > 2013/6/13 Eric Rescorla >: >>> 1. There is agreement that there should be a mechanism to pre-specify >>> the size of a candidate pool to gather, though I just glanced in the sp= ec >>> and I didn't see it. (May have missed it though). >> >> >> I see that there still is some (not quite up to date) text here: >> >> Create an ICE Agent as defined in [ICE] and let connection's >> RTCPeerConnection ICE Agent be that ICE Agent and provide it the STUN an= d >> TURN servers from the configuration array. The ICE Agent will proceed wi= th >> gathering as soon as the IceTransports constraint is not set to "none". = At >> this point the ICE Agent does not know how many ICE components it needs = (and >> hence the number of candidates to gather), but it can make a reasonable >> assumption such as 2. As the RTCPeerConnection object gets more informat= ion, >> the ICE Agent can adjust the number of components. > > > Hi Eric, thanks a lot for the information you provide. > > Is it feasible with the current API to ask for N ICE candidates prior > to having the local SDP set as local descriptor in the PeerConnection? > > > That has been discussed (and I thought agreed upon) but I don't see > it in the spec. > > -Ekr > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 I=C3=B1aki Baz Castillo From pthatcher@google.com Mon Jun 17 11:00:23 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3731921F9DA3 for ; Mon, 17 Jun 2013 11:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw3wJ4qwhc-K for ; Mon, 17 Jun 2013 11:00:22 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6173921F9D7E for ; Mon, 17 Jun 2013 11:00:22 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so2985812pbb.8 for ; Mon, 17 Jun 2013 11:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dJCH+CF2zIZa/PoVUB1kx3Bju/KNu1OELxoaxEESgF8=; b=leAXb9zYty27X16WyWg6OqJiGFTpfaxRy51emRmHYbB5ZElEWFOJkUqR0Y6q5Lqmlq 9H2bvtOahUjyBaTB6nuLtD0rymzkuCa74aK25rkLXdEkf6iwKhFGXUblHtOvQV3X1fNH Lz6OBvBCtgqbEY88BVcvbqTJ26wLQwNnksPNDkNyvu+oeFmd11GK3BOSzBhbFXDYfdld ZljcVUKiB/73rAi2OuImNZVQ0aAcxL39m93qPjxJGE3CgSag/yiSnBzuPKuaKr6bbXyi CnFC3SJjc6WxWRKLd1DrlEstHEuc7JOGnmzN/wxPH/ghMjCyWZNqD/7NKIPZ4zBTUw3c HFzw== 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=dJCH+CF2zIZa/PoVUB1kx3Bju/KNu1OELxoaxEESgF8=; b=nCzHRxGDWUVz4nnnln6xi1GI0862Ok5xqiT19RQJd/UG3LfzVERYtf90nxFS1V+yHl wSNLxumDv9Zd/2N8luFjlBPf9/+LXoqdB6oKUOrV1dFCt1JYMO/y2Bm3BOyEcwbI4cPb uCL6JbB0IIwTse505gPvL3thXpBlj297khtC2LV4NfpY5CBn6WyCTADcCvOV2BI/aVJ7 DWfnLFUwH8HMl1x0xF28dawoCbU1ndSqyZJMx385pBAMAlyN2Q47Ykbn22CqXB5+XDsp Tx6xYiKQsKANFJ1oBJKaDR/b4CUQNAk2DOeMDy+/EE+nI95M+fKgjgqAm7toalXkliG/ lhQg== X-Received: by 10.68.175.68 with SMTP id by4mr13972252pbc.53.1371492021924; Mon, 17 Jun 2013 11:00:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Mon, 17 Jun 2013 10:59:41 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C2FC071@ESESSMB209.ericsson.se> <57A15FAF9E58F841B2B1651FFE16D28104C918@GENSJZMBX01.msg.int.genesyslab.com> From: Peter Thatcher Date: Mon, 17 Jun 2013 10:59:41 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7bd6c6acc78e5604df5d5e17 X-Gm-Message-State: ALoCoQlsHH55ApgayQbBV53JNJgzkztqZLEWs0r4oKb4LUZBh38OJ4URGm4hhUhBPqF2g0V3GDyUq5kRhIggiN3zLjCau5U2DiHDavZXXaTTzywx+2NZQ2wIgwV3x4AsXXE9Ka02GvN1IRTNhnYS5BWxozRLkn7uZlciS0KXhyJSFp2ChoehYw+HdWeeWlVE1I7S1zfrVyEz Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 18:00:23 -0000 --047d7bd6c6acc78e5604df5d5e17 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In that use case, just call createLocalStream again with the new MediaStream from GetUserMedia and get a new LocalMediaStream. There's no need to alter the existing one. On Mon, Jun 17, 2013 at 9:34 AM, I=C3=B1aki Baz Castillo wr= ote: > 2013/6/17 Peter Thatcher : > > But I don't really see a use case where you would need to add tracks to= a > > MediaStreamTrackDescription, other than when parsing signalling and > building > > the MediaStreamTrackDescription to send down into createRemoteStream. > > Perhaps if we had a use case, we could define such support. But > otherwise, > > I'd say it's not allowed. > > Use case: > > - Start a session/call with just audio (no video requested to the user > via getUserMedia). > - Latter the user wants to add video. > - For that a new getUserMedia(video: true) is requested. > - Extract the video track from the obtained MediaStream and add it to the > PC. > > Hope this is an enough common use case. > > > -- > I=C3=B1aki Baz Castillo > > --047d7bd6c6acc78e5604df5d5e17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    In that use case, just call createLocalStream again with t= he new MediaStream from GetUserMedia and get a new LocalMediaStream. =C2=A0= There's no need to alter the existing one.


    On Mon, Jun 17, 2013 at 9:34 AM, I=C3=B1aki = Baz Castillo <ibc@aliax.net> wrote:
    2013/6/17 Peter Thatcher <pthatc= her@google.com>:
    > But I don't really see a use case where you woul= d need to add tracks to a
    > MediaStreamTrackDescription, other than when parsing signalling and bu= ilding
    > the MediaStreamTrackDescription to send down into createRemoteStream.<= br> > Perhaps if we had a use case, we could define such support. =C2=A0But = otherwise,
    > I'd say it's not allowed.

    Use case:

    - Start a session/call with just audio (no video requested to the user
    via getUserMedia).
    - Latter the user wants to add video.
    - For that a new getUserMedia(video: true) is requested.
    - Extract the video track from the obtained MediaStream and add it to the P= C.

    Hope this is an enough common use case.


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

    --047d7bd6c6acc78e5604df5d5e17-- From jmillan@aliax.net Mon Jun 17 11:52:16 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96E821F9CD8 for ; Mon, 17 Jun 2013 11:52:16 -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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptkyovaJuiwr for ; Mon, 17 Jun 2013 11:52:16 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3001E21F9CEA for ; Mon, 17 Jun 2013 11:52:12 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id 10so2222147vbe.19 for ; Mon, 17 Jun 2013 11:52:01 -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=kUBnFj0N0lqfAzCpGjbi/jcpIxTfJybyLV/WiZNbI/o=; b=neQj2THsfPOPje+NnsnniB+ejh1mbqUqKiS/iuVCNAjOM/UU89MuPQuHM8k8s1nSdh /w8EbKvP2rOgGRpTcdUtPVIx/ANnm+MfjZmFkEB1+LwwyAM3U+QxKOb7qXVhhMeZdBo0 enr9LrOOecLDyhbfflwqLBovaAsva4kojSQFDw1K0nNqYDGY0vyqtkKS26Sz9qQKbpKN JnHKUq/SASJQ/zzjq5LFyW1SGpIeshTXx8RWFLJpwE2DcQJ9jysqV+gzk/ZZmiYndbQB AI/GxUXvxcgjS6908Y+bkbzEdVwPpI8sCpHFZ23AVRueTUDnsApzCmSIgEy7mhZHFNUb bpJg== MIME-Version: 1.0 X-Received: by 10.220.59.69 with SMTP id k5mr4248812vch.34.1371495121664; Mon, 17 Jun 2013 11:52:01 -0700 (PDT) Received: by 10.220.215.131 with HTTP; Mon, 17 Jun 2013 11:52:01 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C2FC071@ESESSMB209.ericsson.se> <57A15FAF9E58F841B2B1651FFE16D28104C918@GENSJZMBX01.msg.int.genesyslab.com> Date: Mon, 17 Jun 2013 20:52:01 +0200 Message-ID: From: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= To: Peter Thatcher Content-Type: multipart/alternative; boundary=001a11c2012c89cfa704df5e1731 X-Gm-Message-State: ALoCoQnm7HGNQDbHE7cZqW1YubnNvhg4ku/KKbdlrS07tRaS8q69UyW6XXZakcPDWiuWoJqLpQ/J Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 18:52:17 -0000 --001a11c2012c89cfa704df5e1731 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, 2013/6/17 Peter Thatcher > In that use case, just call createLocalStream again with the new > MediaStream from GetUserMedia and get a new LocalMediaStream. There's no > need to alter the existing one. > > On the receiver side, I would expect to represent each remote MediaStream on its own audio+video display element. If, as a sender, I create a new LocalStream to represent a change in an existent media stream source, how will the receiver notice that the NEW MediaStream does refer to the previous one? > > On Mon, Jun 17, 2013 at 9:34 AM, I=C3=B1aki Baz Castillo = wrote: > >> 2013/6/17 Peter Thatcher : >> > But I don't really see a use case where you would need to add tracks t= o >> a >> > MediaStreamTrackDescription, other than when parsing signalling and >> building >> > the MediaStreamTrackDescription to send down into createRemoteStream. >> > Perhaps if we had a use case, we could define such support. But >> otherwise, >> > I'd say it's not allowed. >> >> Use case: >> >> - Start a session/call with just audio (no video requested to the user >> via getUserMedia). >> - Latter the user wants to add video. >> - For that a new getUserMedia(video: true) is requested. >> - Extract the video track from the obtained MediaStream and add it to th= e >> PC. >> >> Hope this is an enough common use case. >> >> >> -- >> I=C3=B1aki Baz Castillo >> >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --=20 Jos=C3=A9 Luis Mill=C3=A1n --001a11c2012c89cfa704df5e1731 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi,


    2013/6/17 Peter Thatcher <pthatcher@google.com>
    In that use case, just call createLocalStream again with t= he new MediaStream from GetUserMedia and get a new LocalMediaStream. =C2=A0= There's no need to alter the existing one.
    <= div class=3D"h5">


    On the receiver side, I would expect to represent each remote MediaS= tream on its own audio+video display element.

    If, = as a sender, I create a new LocalStream to represent a change in an existen= t media stream source, how will the receiver notice that the NEW MediaStrea= m does refer to the previous one?


    =C2=A0

    On Mon, Jun 17, 2013 at 9:34 AM, I=C3=B1aki = Baz Castillo <ibc@aliax.net> wrote:
    2013/6/17 Peter Thatcher <pthatcher@google.com>:
    > But I don't really see a use case where you would need to add= tracks to a
    > MediaStreamTrackDescription, other than when parsing signalling and bu= ilding
    > the MediaStreamTrackDescription to send down into createRemoteStream.<= br> > Perhaps if we had a use case, we could define such support. =C2=A0But = otherwise,
    > I'd say it's not allowed.

    Use case:

    - Start a session/call with just audio (no video requested to the user
    via getUserMedia).
    - Latter the user wants to add video.
    - For that a new getUserMedia(video: true) is requested.
    - Extract the video track from the obtained MediaStream and add it to the P= C.

    Hope this is an enough common use case.


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


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




    --
    Jos=C3= =A9 Luis Mill=C3=A1n
    --001a11c2012c89cfa704df5e1731-- From martin.thomson@gmail.com Mon Jun 17 11:57:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F06C21F9A86 for ; Mon, 17 Jun 2013 11:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Hvvfg2cVI8R for ; Mon, 17 Jun 2013 11:57:46 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id EC2AB21F9A74 for ; Mon, 17 Jun 2013 11:57:45 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b12so2743658wgh.7 for ; Mon, 17 Jun 2013 11:57:45 -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=8MiANTaxlB4K8KPhd2mhm9gA0ES3E/JeT5cxvHiBRg4=; b=r1+MXt+M+cFqoqQkCM+4ekh8ZJNfKXyCI9l9lL7kRrje7BNgS+kCRrwlBtMDQBHY27 Xf9MkFhQvnFeQWDgFBTyHAZQeGNBbw+yTi/EjcS1qIDcrlsM1wKHXjnGXrzcOCUgMEMY vizVLzjDlfXLj4AZwdQurMSAZ0RuYkWtsxQd1tcWVPWxkKdDdr0c8r+vbTXf+MLdASeK 3ztXTYWlp+I1S38aVbABnEEJ/zUcoyRkpChZg757VVPKlos7v2m5N8Fbbe13bYAA06pZ bCenWVszjtWozOWQyObw6Sli7ROBWiVk6x/9uYrEwlpYhZ/nVtuvztdHWFgqE3KC2vbJ aGcQ== MIME-Version: 1.0 X-Received: by 10.180.39.236 with SMTP id s12mr5664069wik.14.1371495464598; Mon, 17 Jun 2013 11:57:44 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 17 Jun 2013 11:57:44 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Jun 2013 11:57:44 -0700 Message-ID: From: Martin Thomson To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 18:57:47 -0000 Maybe you'd expect me to be more supportive of something that looked so much like CU-RTC-Web. It inherits all the worst properties of JSEP (Offer/Answer, SDP editing) with a partial implementation of a clean API. It's comment 22-lite. It's an abomination. If you are going to do this, do it properly. On 17 June 2013 05:57, Peter Thatcher wrote: > Google is in full support of "Plan B" for encoding multiple media sources in > SDP, and would like to see the Plan A vs. Plan B decision resolved soon. > Recently, though, a third option, called "NoPlan" has been proposed, but it > lacked the details of what a JS API would look like for NoPlan. Cullen > asked to see such an API proposal, and so I have worked with Emil to make > one. He will be adding it to the NoPlan draft, but I will also include it > in this email. > > Again, Google is in full support of "Plan B". But if Plan A vs. Plan B > cannot be decided, then we support NoPlan with the following additions to > the WebRTC JS API as an option that allows implementing either Plan A or > Plan B in Javascript. And even if Plan A vs. Plan B is resolved, these API > additions would still be a big improvement for those WebRTC applications > that don't use SDP for signalling. > > It is a bit long because I have added many comments and examples, but the > actually additions only include two new methods on PeerConnection and a few > new dictionaries. So don't be overwhelmed :). > > > > Intro: This follows the model of createDataChannel, which has a JS method on > PeerConnection that makes it possible to add data channels without going > through SDP. Furthermore, just like createDataChannel allows 2 ways to > handle neogitation (the "I know what I'm doing; Here's what I want to send; > Let me signal everything" mode and the "please take care of it for me; send > an OPEN message" mode), this also has 2 ways to handle negotiation (the "I > know what I'm doing; Here's what I want to send; Let me signal everything" > mode and the "please take care of it for me; send SDP back and forth" > mode). > > Following the success of createDataChannel, this allows simple applications > to Just Work and more advanced applications to easily control what they need > to. In particular, it's possible to use this API to implement either Plan A > or Plan B. > > // The following two method are added to RTCPeerConnection > partial interface RTCPeerConnection { > // Create a stream that is used to send a source stream. > // The MediaSendStream.description can be used for signalling. > // No media is sent until addStream(MediaSendStream) is called. > LocalMediaStream createLocalStream(MediaStream sourceStream); > > // Create a stream that is used to receive media from the remote side, > // given the parameters signalled from MedaiSendStream.description. > MediaStream createRemoteStream(MediaStreamDescription description); > } > > > interface LocalMediaStream implements MediaStream { > // This can be changed at any time, but especially before calling > // PeerConnection.addStream > attribute MediaStreamDescription description; > } > > > // Represents the parameters used to either send or receive a stream > // over a PeerConnection. > dictionary MediaStreamDescription { > MediaStreamTrackDescription[] tracks; > } > > > // Represents the parameters used to either send or receive a track over // > a PeerConnection. A track has many "flows", which can be grouped > // together. > dictionary MediaStreamTrackDescription { > // Same as the MediaStreamTrack.id > DOMString id; > > // Same as the MediaStreamTrack.kind > DOMString kind; > > // A track can have many "flows", such as for Simulcast, FEC, etc. > // And they can be grouped in arbitrary ways. > MediaFlowDescription[] flows; > MediaFlowGroup[] flowGroups; > } > > // Represents the parameters used to either send or receive a "flow" > // over a PeerConnection. A "flow" is a media that arrives with a > // single, unique SSRC. One to many flows together make up the media > // for a track. For example, there may be Simulcast, FEC, and RTX > // flows. > dictionay MediaFlowDescription { > // The "flow id" must be unique to the track, but need not be unique > // outside of the track (two tracks could both have a flow with the > // same flow ID). > DOMString id; > > // Each flow can go over its own transport. If the JS sets this to a > // transportId that doesn't have a transport setup already, the > // browser will use SDP negotiation to setup a transport to back that > // transportId. If This is set to an MID in the SDP, then that MID's > // transport is used. > DOMString transportId; > > // The SSRC used to send the flow. > unsigned int ssrc; > > // When used as receive parameters, this indicates the possible list > // of codecs that might come in for this flow. For exmample, a given > // receive flow could be setup to receive any of OPUS, ISAC, or PCMU. > // When used as send parameters, this indicates that the first codec > // should be used, but the browser can use send other codecs if it > // needs to because of either bandwidth or CPU constraints. > MediaCodecDescription[] codecs; > } > > > dictionary MediaFlowGroup { > DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc > DOMString[] flowids; > } > > dictionary MediaCodecDescription { > unsigned byte payloadType; > DOMString name; > unsigned int? clockRate; > unsigned int? bitRate; > // A grab bag of other fmtp that will need to be further defined. > MediaCodecParam[] params; > } > > dictionary MediaCodecParam { > DOMString key; > DOMString value; > } > > > Notes: > > - When LocalMediaStreams are added using addStream, onnegotiatedneeded is > not called, and those streams are never reflected in future SDP exchanges. > Indeed, it would be impossible to put them in the SDP without first > resolving if that would be Plan A SDP or Plan B SDP. > > - Just like piles of attributes would need to be defined for Plan A and for > Plan B, similar attributes would need to be defined here (Luckily, much > work has already been done figuring out what those parameters are :). > > > Pros: > > - Either Plan A or Plan B or could be implemented in Javascript using this > API > - It exposes all the same functionality to the Javascript as SDP, but in a > much nicer format that is much easier to work with. > - Any other signalling mechanism, such as Jingle or CLUE could be > implemented using this API. > - There is almost no risk of signalling glare. > - Debugging errors with misconfigured descriptions should be much easier > with this than with large SDP blobs. > > > Cons: > > - Now there are two slightly different ways to add streams: by creating a > LocalMediaStream first, and not. This is, however, analogous to setting > "negotiated: true" in createDataChannel. On way is "Just Work", and the > other is more advanced control. > > - All the options in MediaCodecDescription are a bit complicated. Really, > this is only necessary because Plan A requires being able to specify codec > parameters per SSRC, and set each flow on different transports. If we did > not have this requirement, we could simplify. > > > Example Usage: > > // Imagine I have MyApp, handles creating a PeerConnection, > // signalling, and rendering streams. This is how the new API could be > // used. > var peerConnection = MyApp.createPeerConnection(); > > // On sender side: > var stream = MyApp.getMediaStream(); > var localStream = peerConnection.createSendStream(stream); > sendStream.description = MyApp.modifyStream(localStream.description) > MyApp.signalAddStream(localStream.description, function(response)) { > if (!response.rejected) { > // Media will not be sent. > peerConnection.addStream(localStream); > } > } > > // On receiver side: > MyApp.onAddStreamSignalled = function(streamDescription) { > var stream = peerConnection.createReceiveStream(streamDescription); > MyApp.renderStream(stream); > } > > > // In this exchange, the MediaStreamDescription signalled from the > // sender to the receiver may have looked something like this: > > { > tracks: [ > { > id: "audio1", > kind: "audio", > flows: [ > { > id: "main", > transportId: "transport1", > ssrc: 1111, > codecs: [ > { > payloadType: 111, > name: "opus", > // ... more codec details > }, > { > payloadType: 112, > name: "pcmu", > // ... more codec details > }] > }] > }, > { > id: "video1", > kind: "video", > flows: [ > { > id: "sim0", > transportId: "transport2", > ssrc: 2222, > codecs: [ > { > payloadType: 122, > name: "vp8" > // ... more codec details > }] > }, > { > id: "sim1", > transportId: "transport2", > ssrc: 2223, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... more codec details > }] > }, > { > id: "sim2", > transportId: "transport2", > ssrc: 2224, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... more codec details > }] > }, > > { > id: "sim0fec", > transportId: "transport2", > ssrc: 2225, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... > }] > }], > flowGroups: [ > { > semantics: "SIM", > ssrcs: [2222, 2223, 2224] > }, > { > semantics: "FEC", > ssrcs: [2222, 2225] > }] > }] > } > > > Constructive feedback is welcome :). > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From emil@sip-communicator.org Mon Jun 17 12:10:01 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376BC21F9057 for ; Mon, 17 Jun 2013 12:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqE5CQdgKww4 for ; Mon, 17 Jun 2013 12:09:59 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7858921F9A76 for ; Mon, 17 Jun 2013 12:09:59 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u53so2724477wes.9 for ; Mon, 17 Jun 2013 12:09:55 -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=wwQIJjcp0hg3Q5Y5mxa6v0FBD9GzV3F6V0b9CUkoDy8=; b=JvTDFuTrra0fWN46s3nS9hHlzL2eoV4WYkYxuMQxv49r3SPA7rHBpU9+Kd0b8GxgsJ hzANgdJO3shhzkIwPcbrOp3gXTyyrljSWXkUxhVFzC136VpJAwTzAupxDWGyec6JgwmR KdEJNEkn0AwNOMgp+K1sY6WAD7Yo29I5iA4eByi9JY6V14PWoG9GQkqZTRbNURK6l8LZ UO1XFPUFazNr9KGbmBT16ro1GVpzo3rcKTAZnfMd21TbzUeH3bICel7M5qRUZ4s1qiUo rQ0N9/deRsi13ep7l3dhvaEk4r8L2Xwumd8U2eqTQqpZcVTOnJvCI01FEy2IneIP4ms0 NZGA== X-Received: by 10.180.11.166 with SMTP id r6mr5618839wib.45.1371496195802; Mon, 17 Jun 2013 12:09:55 -0700 (PDT) Received: from camionet.local ([2a01:e35:2e2c:f600:b43d:dd37:b9b1:450]) by mx.google.com with ESMTPSA id r9sm24132931wik.1.2013.06.17.12.09.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Jun 2013 12:09:54 -0700 (PDT) Message-ID: <51BF5F00.90705@jitsi.org> Date: Mon, 17 Jun 2013 21:09:52 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Martin Thomson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQld9Cl6rZbv6CiN7pMEzby4i7WUZNvYxjvXnppGMVjVhP7G7ElRCEqlvR/RZMfXPvrUxnS4 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 19:10:01 -0000 On 17.06.13, 20:57, Martin Thomson wrote: > Maybe you'd expect me to be more supportive of something that looked > so much like CU-RTC-Web. No, but this doesn't mean you can't at least be constructive ... > It inherits all the worst properties of JSEP > (Offer/Answer, SDP editing) with a partial implementation of a clean > API. > > It's comment 22-lite. It's an abomination. If you are going to do > this, do it properly. So here's your chance: could you please share your view of how this would look if done properly? Emil > > On 17 June 2013 05:57, Peter Thatcher wrote: >> Google is in full support of "Plan B" for encoding multiple media sources in >> SDP, and would like to see the Plan A vs. Plan B decision resolved soon. >> Recently, though, a third option, called "NoPlan" has been proposed, but it >> lacked the details of what a JS API would look like for NoPlan. Cullen >> asked to see such an API proposal, and so I have worked with Emil to make >> one. He will be adding it to the NoPlan draft, but I will also include it >> in this email. >> >> Again, Google is in full support of "Plan B". But if Plan A vs. Plan B >> cannot be decided, then we support NoPlan with the following additions to >> the WebRTC JS API as an option that allows implementing either Plan A or >> Plan B in Javascript. And even if Plan A vs. Plan B is resolved, these API >> additions would still be a big improvement for those WebRTC applications >> that don't use SDP for signalling. >> >> It is a bit long because I have added many comments and examples, but the >> actually additions only include two new methods on PeerConnection and a few >> new dictionaries. So don't be overwhelmed :). >> >> >> >> Intro: This follows the model of createDataChannel, which has a JS method on >> PeerConnection that makes it possible to add data channels without going >> through SDP. Furthermore, just like createDataChannel allows 2 ways to >> handle neogitation (the "I know what I'm doing; Here's what I want to send; >> Let me signal everything" mode and the "please take care of it for me; send >> an OPEN message" mode), this also has 2 ways to handle negotiation (the "I >> know what I'm doing; Here's what I want to send; Let me signal everything" >> mode and the "please take care of it for me; send SDP back and forth" >> mode). >> >> Following the success of createDataChannel, this allows simple applications >> to Just Work and more advanced applications to easily control what they need >> to. In particular, it's possible to use this API to implement either Plan A >> or Plan B. >> >> // The following two method are added to RTCPeerConnection >> partial interface RTCPeerConnection { >> // Create a stream that is used to send a source stream. >> // The MediaSendStream.description can be used for signalling. >> // No media is sent until addStream(MediaSendStream) is called. >> LocalMediaStream createLocalStream(MediaStream sourceStream); >> >> // Create a stream that is used to receive media from the remote side, >> // given the parameters signalled from MedaiSendStream.description. >> MediaStream createRemoteStream(MediaStreamDescription description); >> } >> >> >> interface LocalMediaStream implements MediaStream { >> // This can be changed at any time, but especially before calling >> // PeerConnection.addStream >> attribute MediaStreamDescription description; >> } >> >> >> // Represents the parameters used to either send or receive a stream >> // over a PeerConnection. >> dictionary MediaStreamDescription { >> MediaStreamTrackDescription[] tracks; >> } >> >> >> // Represents the parameters used to either send or receive a track over // >> a PeerConnection. A track has many "flows", which can be grouped >> // together. >> dictionary MediaStreamTrackDescription { >> // Same as the MediaStreamTrack.id >> DOMString id; >> >> // Same as the MediaStreamTrack.kind >> DOMString kind; >> >> // A track can have many "flows", such as for Simulcast, FEC, etc. >> // And they can be grouped in arbitrary ways. >> MediaFlowDescription[] flows; >> MediaFlowGroup[] flowGroups; >> } >> >> // Represents the parameters used to either send or receive a "flow" >> // over a PeerConnection. A "flow" is a media that arrives with a >> // single, unique SSRC. One to many flows together make up the media >> // for a track. For example, there may be Simulcast, FEC, and RTX >> // flows. >> dictionay MediaFlowDescription { >> // The "flow id" must be unique to the track, but need not be unique >> // outside of the track (two tracks could both have a flow with the >> // same flow ID). >> DOMString id; >> >> // Each flow can go over its own transport. If the JS sets this to a >> // transportId that doesn't have a transport setup already, the >> // browser will use SDP negotiation to setup a transport to back that >> // transportId. If This is set to an MID in the SDP, then that MID's >> // transport is used. >> DOMString transportId; >> >> // The SSRC used to send the flow. >> unsigned int ssrc; >> >> // When used as receive parameters, this indicates the possible list >> // of codecs that might come in for this flow. For exmample, a given >> // receive flow could be setup to receive any of OPUS, ISAC, or PCMU. >> // When used as send parameters, this indicates that the first codec >> // should be used, but the browser can use send other codecs if it >> // needs to because of either bandwidth or CPU constraints. >> MediaCodecDescription[] codecs; >> } >> >> >> dictionary MediaFlowGroup { >> DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc >> DOMString[] flowids; >> } >> >> dictionary MediaCodecDescription { >> unsigned byte payloadType; >> DOMString name; >> unsigned int? clockRate; >> unsigned int? bitRate; >> // A grab bag of other fmtp that will need to be further defined. >> MediaCodecParam[] params; >> } >> >> dictionary MediaCodecParam { >> DOMString key; >> DOMString value; >> } >> >> >> Notes: >> >> - When LocalMediaStreams are added using addStream, onnegotiatedneeded is >> not called, and those streams are never reflected in future SDP exchanges. >> Indeed, it would be impossible to put them in the SDP without first >> resolving if that would be Plan A SDP or Plan B SDP. >> >> - Just like piles of attributes would need to be defined for Plan A and for >> Plan B, similar attributes would need to be defined here (Luckily, much >> work has already been done figuring out what those parameters are :). >> >> >> Pros: >> >> - Either Plan A or Plan B or could be implemented in Javascript using this >> API >> - It exposes all the same functionality to the Javascript as SDP, but in a >> much nicer format that is much easier to work with. >> - Any other signalling mechanism, such as Jingle or CLUE could be >> implemented using this API. >> - There is almost no risk of signalling glare. >> - Debugging errors with misconfigured descriptions should be much easier >> with this than with large SDP blobs. >> >> >> Cons: >> >> - Now there are two slightly different ways to add streams: by creating a >> LocalMediaStream first, and not. This is, however, analogous to setting >> "negotiated: true" in createDataChannel. On way is "Just Work", and the >> other is more advanced control. >> >> - All the options in MediaCodecDescription are a bit complicated. Really, >> this is only necessary because Plan A requires being able to specify codec >> parameters per SSRC, and set each flow on different transports. If we did >> not have this requirement, we could simplify. >> >> >> Example Usage: >> >> // Imagine I have MyApp, handles creating a PeerConnection, >> // signalling, and rendering streams. This is how the new API could be >> // used. >> var peerConnection = MyApp.createPeerConnection(); >> >> // On sender side: >> var stream = MyApp.getMediaStream(); >> var localStream = peerConnection.createSendStream(stream); >> sendStream.description = MyApp.modifyStream(localStream.description) >> MyApp.signalAddStream(localStream.description, function(response)) { >> if (!response.rejected) { >> // Media will not be sent. >> peerConnection.addStream(localStream); >> } >> } >> >> // On receiver side: >> MyApp.onAddStreamSignalled = function(streamDescription) { >> var stream = peerConnection.createReceiveStream(streamDescription); >> MyApp.renderStream(stream); >> } >> >> >> // In this exchange, the MediaStreamDescription signalled from the >> // sender to the receiver may have looked something like this: >> >> { >> tracks: [ >> { >> id: "audio1", >> kind: "audio", >> flows: [ >> { >> id: "main", >> transportId: "transport1", >> ssrc: 1111, >> codecs: [ >> { >> payloadType: 111, >> name: "opus", >> // ... more codec details >> }, >> { >> payloadType: 112, >> name: "pcmu", >> // ... more codec details >> }] >> }] >> }, >> { >> id: "video1", >> kind: "video", >> flows: [ >> { >> id: "sim0", >> transportId: "transport2", >> ssrc: 2222, >> codecs: [ >> { >> payloadType: 122, >> name: "vp8" >> // ... more codec details >> }] >> }, >> { >> id: "sim1", >> transportId: "transport2", >> ssrc: 2223, >> codecs: [ >> { >> payloadType: 122, >> name: "vp8", >> // ... more codec details >> }] >> }, >> { >> id: "sim2", >> transportId: "transport2", >> ssrc: 2224, >> codecs: [ >> { >> payloadType: 122, >> name: "vp8", >> // ... more codec details >> }] >> }, >> >> { >> id: "sim0fec", >> transportId: "transport2", >> ssrc: 2225, >> codecs: [ >> { >> payloadType: 122, >> name: "vp8", >> // ... >> }] >> }], >> flowGroups: [ >> { >> semantics: "SIM", >> ssrcs: [2222, 2223, 2224] >> }, >> { >> semantics: "FEC", >> ssrcs: [2222, 2225] >> }] >> }] >> } >> >> >> Constructive feedback is welcome :). >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- https://jitsi.org From pthatcher@google.com Mon Jun 17 12:26:49 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867CD21F9D24 for ; Mon, 17 Jun 2013 12:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOqopmaq8S7Q for ; Mon, 17 Jun 2013 12:26:48 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id DBC0B21F8FF3 for ; Mon, 17 Jun 2013 12:26:47 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id xa12so3087971pbc.39 for ; Mon, 17 Jun 2013 12:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=X8qotrMCpY/s52kZRy25zxvEk+Qx/K7jlTyE78DKXmM=; b=LkBEjfkpi8o23j7cDDcimigIrMsjdQeWyWpB0YEDYqU6WJnlt9sI1DnKYo30T+C261 7zcha0qdyCxhwVVZG52UhCg8XapK4bhLP1JFOatY5nUQVPjSEmA133hTR4wMqZtwO+HM SCaaSosGKAuUgLdqEFK2B3ZyeReXts1nvtbR0WzTO2xsMvn9HmJfMvQwnC+0FkI9kZRk DXPnGll7/9VS3+bwZx4hwazUKEV+yfv/jfdd2mMkQfdgMhBIeY7Mv4/CRzidhc1HpUdO iCfIFzuWCmcRI4gcFranhHHHMG6flNg5F3L618tdP3ruTyfbh2km/lAdOvaRGLaC+xDy zjpA== 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=X8qotrMCpY/s52kZRy25zxvEk+Qx/K7jlTyE78DKXmM=; b=XvHSzSCYGY7mH9XGppOejtW/uACtYphSA2r26/bNCVA4/KgMqqlJt/DIPBS3VqQt8w gLpowPl/KVrFJkd51QItL2KCgNg0/c7NrO8CYWPxsLi8lFLVh+Lfdm1bigPBC7tWxPsr Xcw2KScdPoIbJSASfJ240tblHmLCVZy7aM4cxpgGAYtKK2RslLdj7d2ecIZPWSprANP3 NL5YU3BAEL9gbUe7JQA5HvwnsOToW2FMlk5GhzWDAwFsfRgENv2/U4YYjFq8ZMUTa5Yz T2T5b2LLlXkOGQfriYRDARuRh84U5jM5MSl2ct9onSZMEKgBYDIYy6NVvJPtC4dCvLKV czCQ== X-Received: by 10.68.1.226 with SMTP id 2mr14386627pbp.150.1371497207535; Mon, 17 Jun 2013 12:26:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Mon, 17 Jun 2013 12:26:07 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Mon, 17 Jun 2013 12:26:07 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=bcaec5314817ddbb9004df5e933c X-Gm-Message-State: ALoCoQkh4PE0aGQiPT6ibbOjGhGEeFCwdsPde8RRbg+S3dhgNe+2R0dFi/HHphNXJLXSpzx/q3LEa+0n5Mu8xQoVxvp0zeM9X7l9/+zD8MXtt/A/5ECQ+mnYCJKGSzj+D30dv5rpaXkLZ+Zn0dprVpZtwBLjhROdjHDOBBTXo6/PWrWYZTTpEf0htaQ87lP/0M+J9N2BqEUB Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 19:26:49 -0000 --bcaec5314817ddbb9004df5e933c Content-Type: text/plain; charset=UTF-8 Yes, I was expecting you to be more supportive. I'm surprised out how your want "all or nothing". I'm afraid if our options for a clean API are all or nothing, we'll just end up with nothing. I'd prefer to try incremental improvements to word toward (eventually) a clean API. Do you think it is impossible to work toward a clean API in an incremental approach? If you think it's possible, I'd like to hear your thoughts on how. By the way, these API additions would greatly minimize the amount of SDP editing necessary for JS clients that don't use SDP for signalling. And later incremental improvements could reduce it further. Also, it's no longer necessary to do offer/answer for adding tracks. It's only the intial PeerConnection setup that needs to do Offer/Answer. So, it doesn't inherit all the problems quite as much as you described. It may be slightly abominable, but I certainly consider it less abominable than the SDP editing necessary without it. On Mon, Jun 17, 2013 at 11:57 AM, Martin Thomson wrote: > Maybe you'd expect me to be more supportive of something that looked > so much like CU-RTC-Web. It inherits all the worst properties of JSEP > (Offer/Answer, SDP editing) with a partial implementation of a clean > API. > > It's comment 22-lite. It's an abomination. If you are going to do > this, do it properly. > > On 17 June 2013 05:57, Peter Thatcher wrote: > > Google is in full support of "Plan B" for encoding multiple media > sources in > > SDP, and would like to see the Plan A vs. Plan B decision resolved soon. > > Recently, though, a third option, called "NoPlan" has been proposed, but > it > > lacked the details of what a JS API would look like for NoPlan. Cullen > > asked to see such an API proposal, and so I have worked with Emil to make > > one. He will be adding it to the NoPlan draft, but I will also include > it > > in this email. > > > > Again, Google is in full support of "Plan B". But if Plan A vs. Plan B > > cannot be decided, then we support NoPlan with the following additions to > > the WebRTC JS API as an option that allows implementing either Plan A or > > Plan B in Javascript. And even if Plan A vs. Plan B is resolved, these > API > > additions would still be a big improvement for those WebRTC applications > > that don't use SDP for signalling. > > > > It is a bit long because I have added many comments and examples, but the > > actually additions only include two new methods on PeerConnection and a > few > > new dictionaries. So don't be overwhelmed :). > > > > > > > > Intro: This follows the model of createDataChannel, which has a JS > method on > > PeerConnection that makes it possible to add data channels without going > > through SDP. Furthermore, just like createDataChannel allows 2 ways to > > handle neogitation (the "I know what I'm doing; Here's what I want to > send; > > Let me signal everything" mode and the "please take care of it for me; > send > > an OPEN message" mode), this also has 2 ways to handle negotiation (the > "I > > know what I'm doing; Here's what I want to send; Let me signal > everything" > > mode and the "please take care of it for me; send SDP back and forth" > > mode). > > > > Following the success of createDataChannel, this allows simple > applications > > to Just Work and more advanced applications to easily control what they > need > > to. In particular, it's possible to use this API to implement either > Plan A > > or Plan B. > > > > // The following two method are added to RTCPeerConnection > > partial interface RTCPeerConnection { > > // Create a stream that is used to send a source stream. > > // The MediaSendStream.description can be used for signalling. > > // No media is sent until addStream(MediaSendStream) is called. > > LocalMediaStream createLocalStream(MediaStream sourceStream); > > > > // Create a stream that is used to receive media from the remote side, > > // given the parameters signalled from MedaiSendStream.description. > > MediaStream createRemoteStream(MediaStreamDescription description); > > } > > > > > > interface LocalMediaStream implements MediaStream { > > // This can be changed at any time, but especially before calling > > // PeerConnection.addStream > > attribute MediaStreamDescription description; > > } > > > > > > // Represents the parameters used to either send or receive a stream > > // over a PeerConnection. > > dictionary MediaStreamDescription { > > MediaStreamTrackDescription[] tracks; > > } > > > > > > // Represents the parameters used to either send or receive a track over > // > > a PeerConnection. A track has many "flows", which can be grouped > > // together. > > dictionary MediaStreamTrackDescription { > > // Same as the MediaStreamTrack.id > > DOMString id; > > > > // Same as the MediaStreamTrack.kind > > DOMString kind; > > > > // A track can have many "flows", such as for Simulcast, FEC, etc. > > // And they can be grouped in arbitrary ways. > > MediaFlowDescription[] flows; > > MediaFlowGroup[] flowGroups; > > } > > > > // Represents the parameters used to either send or receive a "flow" > > // over a PeerConnection. A "flow" is a media that arrives with a > > // single, unique SSRC. One to many flows together make up the media > > // for a track. For example, there may be Simulcast, FEC, and RTX > > // flows. > > dictionay MediaFlowDescription { > > // The "flow id" must be unique to the track, but need not be unique > > // outside of the track (two tracks could both have a flow with the > > // same flow ID). > > DOMString id; > > > > // Each flow can go over its own transport. If the JS sets this to a > > // transportId that doesn't have a transport setup already, the > > // browser will use SDP negotiation to setup a transport to back that > > // transportId. If This is set to an MID in the SDP, then that MID's > > // transport is used. > > DOMString transportId; > > > > // The SSRC used to send the flow. > > unsigned int ssrc; > > > > // When used as receive parameters, this indicates the possible list > > // of codecs that might come in for this flow. For exmample, a given > > // receive flow could be setup to receive any of OPUS, ISAC, or PCMU. > > // When used as send parameters, this indicates that the first codec > > // should be used, but the browser can use send other codecs if it > > // needs to because of either bandwidth or CPU constraints. > > MediaCodecDescription[] codecs; > > } > > > > > > dictionary MediaFlowGroup { > > DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc > > DOMString[] flowids; > > } > > > > dictionary MediaCodecDescription { > > unsigned byte payloadType; > > DOMString name; > > unsigned int? clockRate; > > unsigned int? bitRate; > > // A grab bag of other fmtp that will need to be further defined. > > MediaCodecParam[] params; > > } > > > > dictionary MediaCodecParam { > > DOMString key; > > DOMString value; > > } > > > > > > Notes: > > > > - When LocalMediaStreams are added using addStream, onnegotiatedneeded is > > not called, and those streams are never reflected in future SDP > exchanges. > > Indeed, it would be impossible to put them in the SDP without first > > resolving if that would be Plan A SDP or Plan B SDP. > > > > - Just like piles of attributes would need to be defined for Plan A and > for > > Plan B, similar attributes would need to be defined here (Luckily, much > > work has already been done figuring out what those parameters are :). > > > > > > Pros: > > > > - Either Plan A or Plan B or could be implemented in Javascript using > this > > API > > - It exposes all the same functionality to the Javascript as SDP, but in > a > > much nicer format that is much easier to work with. > > - Any other signalling mechanism, such as Jingle or CLUE could be > > implemented using this API. > > - There is almost no risk of signalling glare. > > - Debugging errors with misconfigured descriptions should be much easier > > with this than with large SDP blobs. > > > > > > Cons: > > > > - Now there are two slightly different ways to add streams: by creating a > > LocalMediaStream first, and not. This is, however, analogous to setting > > "negotiated: true" in createDataChannel. On way is "Just Work", and the > > other is more advanced control. > > > > - All the options in MediaCodecDescription are a bit complicated. > Really, > > this is only necessary because Plan A requires being able to specify > codec > > parameters per SSRC, and set each flow on different transports. If we > did > > not have this requirement, we could simplify. > > > > > > Example Usage: > > > > // Imagine I have MyApp, handles creating a PeerConnection, > > // signalling, and rendering streams. This is how the new API could be > > // used. > > var peerConnection = MyApp.createPeerConnection(); > > > > // On sender side: > > var stream = MyApp.getMediaStream(); > > var localStream = peerConnection.createSendStream(stream); > > sendStream.description = MyApp.modifyStream(localStream.description) > > MyApp.signalAddStream(localStream.description, function(response)) { > > if (!response.rejected) { > > // Media will not be sent. > > peerConnection.addStream(localStream); > > } > > } > > > > // On receiver side: > > MyApp.onAddStreamSignalled = function(streamDescription) { > > var stream = peerConnection.createReceiveStream(streamDescription); > > MyApp.renderStream(stream); > > } > > > > > > // In this exchange, the MediaStreamDescription signalled from the > > // sender to the receiver may have looked something like this: > > > > { > > tracks: [ > > { > > id: "audio1", > > kind: "audio", > > flows: [ > > { > > id: "main", > > transportId: "transport1", > > ssrc: 1111, > > codecs: [ > > { > > payloadType: 111, > > name: "opus", > > // ... more codec details > > }, > > { > > payloadType: 112, > > name: "pcmu", > > // ... more codec details > > }] > > }] > > }, > > { > > id: "video1", > > kind: "video", > > flows: [ > > { > > id: "sim0", > > transportId: "transport2", > > ssrc: 2222, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8" > > // ... more codec details > > }] > > }, > > { > > id: "sim1", > > transportId: "transport2", > > ssrc: 2223, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... more codec details > > }] > > }, > > { > > id: "sim2", > > transportId: "transport2", > > ssrc: 2224, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... more codec details > > }] > > }, > > > > { > > id: "sim0fec", > > transportId: "transport2", > > ssrc: 2225, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... > > }] > > }], > > flowGroups: [ > > { > > semantics: "SIM", > > ssrcs: [2222, 2223, 2224] > > }, > > { > > semantics: "FEC", > > ssrcs: [2222, 2225] > > }] > > }] > > } > > > > > > Constructive feedback is welcome :). > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > --bcaec5314817ddbb9004df5e933c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Yes, I was expecting you to be more supportive. =C2=A0I= 9;m surprised out how your want "all or nothing". =C2=A0I'm a= fraid if our options for a clean API are all or nothing, we'll just end= up with nothing. =C2=A0I'd prefer to try incremental improvements to w= ord toward (eventually) a clean API.=C2=A0

    Do you think it is impossible to work toward a clean API in = an incremental approach? =C2=A0If you think it's possible, I'd like= to hear your thoughts on how.=C2=A0


    By t= he way, these API additions would greatly minimize the amount of SDP editin= g necessary for JS clients that don't use SDP for signalling. =C2=A0And= later incremental improvements could reduce it further. =C2=A0Also, it'= ;s no longer necessary to do offer/answer for adding tracks. =C2=A0It's= only the intial PeerConnection setup that needs to do Offer/Answer. =C2=A0= So, it doesn't inherit all the problems quite as much as you described.= =C2=A0It may be slightly abominable, but I certainly consider it less abom= inable than the SDP editing necessary without it.


    On Mon,= Jun 17, 2013 at 11:57 AM, Martin Thomson <martin.thomson@gmail.com= > wrote:
    Maybe you'd expect me to be more support= ive of something that looked
    so much like CU-RTC-Web. =C2=A0It inherits all the worst properties of JSEP=
    (Offer/Answer, SDP editing) with a partial implementation of a clean
    API.

    It's comment 22-lite. =C2=A0It's an abomination. =C2=A0If you are g= oing to do
    this, do it properly.

    On 17 June 2013 05:57, Peter Thatcher <pthatcher@google.com> wrote:
    > Google is in full support of "Plan B" for encoding multiple = media sources in
    > SDP, and would like to see the Plan A vs. Plan B decision resolved soo= n.
    > Recently, though, a third option, called "NoPlan" has been p= roposed, but it
    > lacked the details of what a JS API would look like for NoPlan. =C2=A0= Cullen
    > asked to see such an API proposal, and so I have worked with Emil to m= ake
    > one. =C2=A0He will be adding it to the NoPlan draft, but I will also i= nclude it
    > in this email.
    >
    > Again, Google is in full support of "Plan B". =C2=A0But if P= lan A vs. Plan B
    > cannot be decided, then we support NoPlan with the following additions= to
    > the WebRTC JS API as an option that allows implementing either Plan A = or
    > Plan B =C2=A0in Javascript. =C2=A0And even if Plan A vs. Plan B is res= olved, these API
    > additions would still be a big improvement for those WebRTC applicatio= ns
    > that don't use SDP for signalling.
    >
    > It is a bit long because I have added many comments and examples, but = the
    > actually additions only include two new methods on PeerConnection and = a few
    > new dictionaries. =C2=A0So don't be overwhelmed :).
    >
    >
    >
    > Intro: This follows the model of createDataChannel, which has a JS met= hod on
    > PeerConnection that makes it possible to add data channels without goi= ng
    > through SDP. =C2=A0Furthermore, just like createDataChannel allows 2 w= ays to
    > handle neogitation (the "I know what I'm doing; =C2=A0Here= 9;s what I want to send;
    > Let me signal everything" mode and the "please take care of = it for me; =C2=A0send
    > an OPEN message" mode), this also has 2 ways to handle negotiatio= n (the "I
    > know what I'm doing; Here's what I want to send; Let me signal= everything"
    > mode and the "please take care of it for me; =C2=A0send SDP back = and forth"
    > mode).
    >
    > Following the success of createDataChannel, this allows simple applica= tions
    > to Just Work and more advanced applications to easily control what the= y need
    > to. =C2=A0In particular, it's possible to use this API to implemen= t either Plan A
    > or Plan B.
    >
    > // The following two method are added to RTCPeerConnection
    > partial interface RTCPeerConnection {
    > =C2=A0// Create a stream that is used to send a source stream.
    > =C2=A0// The MediaSendStream.description can be used for signalling. > =C2=A0// No media is sent until addStream(MediaSendStream) is called.<= br> > =C2=A0LocalMediaStream createLocalStream(MediaStream sourceStream); >
    > =C2=A0// Create a stream that is used to receive media from the remote= side,
    > =C2=A0// given the parameters signalled from MedaiSendStream.descripti= on.
    > =C2=A0MediaStream createRemoteStream(MediaStreamDescription descriptio= n);
    > }
    >
    >
    > interface LocalMediaStream implements MediaStream {
    > =C2=A0 // This can be changed at any time, but especially before calli= ng
    > =C2=A0 // PeerConnection.addStream
    > =C2=A0 attribute MediaStreamDescription description;
    > }
    >
    >
    > // Represents the parameters used to either send or receive a stream > // over a PeerConnection.
    > dictionary MediaStreamDescription {
    > =C2=A0 MediaStreamTrackDescription[] tracks;
    > }
    >
    >
    > // Represents the parameters used to either send or receive a track ov= er //
    > a PeerConnection. =C2=A0A track has many "flows", which can = be grouped
    > // together.
    > dictionary MediaStreamTrackDescription {
    > =C2=A0 // Same as the MediaStreamTrack.id
    > =C2=A0 DOMString id;
    >
    > =C2=A0 // Same as the MediaStreamTrack.kind
    > =C2=A0 DOMString kind;
    >
    > =C2=A0 // A track can have many "flows", such as for Simulca= st, FEC, etc.
    > =C2=A0 // And they can be grouped in arbitrary ways.
    > =C2=A0 MediaFlowDescription[] flows;
    > =C2=A0 MediaFlowGroup[] flowGroups;
    > }
    >
    > // Represents the parameters used to either send or receive a "fl= ow"
    > // over a PeerConnection. =C2=A0A "flow" is a media that arr= ives with a
    > // single, unique SSRC. =C2=A0One to many flows together make up the m= edia
    > // for a track. =C2=A0For example, there may be Simulcast, FEC, and RT= X
    > // flows.
    > dictionay MediaFlowDescription {
    > =C2=A0 // The "flow id" must be unique to the track, but nee= d not be unique
    > =C2=A0 // outside of the track (two tracks could both have a flow with= the
    > =C2=A0 // same flow ID).
    > =C2=A0 DOMString id;
    >
    > =C2=A0 // Each flow can go over its own transport. =C2=A0If the JS set= s this to a
    > =C2=A0 // transportId that doesn't have a transport setup already,= the
    > =C2=A0 // browser will use SDP negotiation to setup a transport to bac= k that
    > =C2=A0 // transportId. =C2=A0If This is set to an MID in the SDP, then= that MID's
    > =C2=A0 // transport is used.
    > =C2=A0 DOMString transportId;
    >
    > =C2=A0 // The SSRC used to send the flow.
    > =C2=A0 unsigned int ssrc;
    >
    > =C2=A0 // When used as receive parameters, this indicates the possible= list
    > =C2=A0 // of codecs that might come in for this flow. =C2=A0For exmamp= le, a given
    > =C2=A0 // receive flow could be setup to receive any of OPUS, ISAC, or= PCMU.
    > =C2=A0 // When used as send parameters, this indicates that the first = codec
    > =C2=A0 // should be used, but the browser can use send other codecs if= it
    > =C2=A0 // needs to because of either bandwidth or CPU constraints.
    > =C2=A0 MediaCodecDescription[] codecs;
    > }
    >
    >
    > dictionary MediaFlowGroup {
    > =C2=A0 DOMString type; =C2=A0// "SIM" for Simulcast, "F= EC" for FEC, etc
    > =C2=A0 DOMString[] flowids;
    > }
    >
    > dictionary MediaCodecDescription {
    > =C2=A0 unsigned byte payloadType;
    > =C2=A0 DOMString name;
    > =C2=A0 unsigned int? clockRate;
    > =C2=A0 unsigned int? bitRate;
    > =C2=A0 // A grab bag of other fmtp that will need to be further define= d.
    > =C2=A0 MediaCodecParam[] params;
    > }
    >
    > dictionary MediaCodecParam {
    > =C2=A0 DOMString key;
    > =C2=A0 DOMString value;
    > }
    >
    >
    > Notes:
    >
    > - When LocalMediaStreams are added using addStream, onnegotiatedneeded= is
    > not called, and those streams are never reflected in future SDP exchan= ges.
    > Indeed, it would be impossible to put them in the SDP without first > resolving if that would be Plan A SDP or Plan B SDP.
    >
    > - Just like piles of attributes would need to be defined for Plan A an= d for
    > Plan B, similar attributes would need to be defined here (Luckily, =C2= =A0much
    > work has already been done figuring out what those parameters are :).<= br> >
    >
    > Pros:
    >
    > - Either Plan A or Plan B or could be implemented in Javascript using = this
    > API
    > - It exposes all the same functionality to the Javascript as SDP, but = in a
    > much nicer format that is much easier to work with.
    > - Any other signalling mechanism, such as Jingle or CLUE could be
    > implemented using this API.
    > - There is almost no risk of signalling glare.
    > - Debugging errors with misconfigured descriptions should be much easi= er
    > with this than with large SDP blobs.
    >
    >
    > Cons:
    >
    > - Now there are two slightly different ways to add streams: by creatin= g a
    > LocalMediaStream first, and not. =C2=A0This is, however, analogous to = setting
    > "negotiated: true" in createDataChannel. =C2=A0On way is &qu= ot;Just Work", and the
    > other is more advanced control.
    >
    > - All the options in MediaCodecDescription are a bit complicated. =C2= =A0Really,
    > this is only necessary because Plan A requires being able to specify c= odec
    > parameters per SSRC, and set each flow on different transports. =C2=A0= If we did
    > not have this requirement, we could simplify.
    >
    >
    > Example Usage:
    >
    > // Imagine I have MyApp, handles creating a PeerConnection,
    > // signalling, and rendering streams. =C2=A0This is how the new API co= uld be
    > // used.
    > var peerConnection =3D MyApp.createPeerConnection();
    >
    > // On sender side:
    > var stream =3D MyApp.getMediaStream();
    > var localStream =3D peerConnection.createSendStream(stream);
    > sendStream.description =3D MyApp.modifyStream(localStream.description)=
    > MyApp.signalAddStream(localStream.description, function(response)) { > =C2=A0 if (!response.rejected) {
    > =C2=A0 =C2=A0 // Media will not be sent.
    > =C2=A0 =C2=A0 peerConnection.addStream(localStream);
    > =C2=A0 }
    > }
    >
    > // On receiver side:
    > MyApp.onAddStreamSignalled =3D function(streamDescription) {
    > =C2=A0 var stream =3D peerConnection.createReceiveStream(streamDescrip= tion);
    > =C2=A0 MyApp.renderStream(stream);
    > }
    >
    >
    > // In this exchange, the MediaStreamDescription signalled from the
    > // sender to the receiver may have looked something like this:
    >
    > {
    > =C2=A0 tracks: [
    > =C2=A0 {
    > =C2=A0 =C2=A0 id: "audio1",
    > =C2=A0 =C2=A0 kind: "audio",
    > =C2=A0 =C2=A0 flows: [
    > =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 id: "main",
    > =C2=A0 =C2=A0 =C2=A0 transportId: "transport1",
    > =C2=A0 =C2=A0 =C2=A0 ssrc: 1111,
    > =C2=A0 =C2=A0 =C2=A0 codecs: [
    > =C2=A0 =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 111,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 name: "opus",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 },
    > =C2=A0 =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 112,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 name: "pcmu",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 }]
    > =C2=A0 =C2=A0}]
    > =C2=A0},
    > =C2=A0{
    > =C2=A0 =C2=A0 id: "video1",
    > =C2=A0 =C2=A0 kind: "video",
    > =C2=A0 =C2=A0 flows: [
    > =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 id: "sim0",
    > =C2=A0 =C2=A0 =C2=A0 transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0 ssrc: 2222,
    > =C2=A0 =C2=A0 =C2=A0 codecs: [
    > =C2=A0 =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 name: "vp8"
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 }]
    > =C2=A0 =C2=A0},
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0id: "sim1",
    > =C2=A0 =C2=A0 =C2=A0transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0ssrc: 2223,
    > =C2=A0 =C2=A0 =C2=A0codecs: [
    > =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "vp8",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0// ... more codec details
    > =C2=A0 =C2=A0 =C2=A0}]
    > =C2=A0 =C2=A0},
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0id: "sim2",
    > =C2=A0 =C2=A0 =C2=A0transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0ssrc: 2224,
    > =C2=A0 =C2=A0 =C2=A0codecs: [
    > =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "vp8",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0// ... more codec details
    > =C2=A0 =C2=A0 =C2=A0}]
    > =C2=A0 =C2=A0},
    >
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0id: "sim0fec",
    > =C2=A0 =C2=A0 =C2=A0transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0ssrc: 2225,
    > =C2=A0 =C2=A0 =C2=A0codecs: [
    > =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "vp8",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0// ...
    > =C2=A0 =C2=A0 =C2=A0}]
    > =C2=A0 =C2=A0}],
    > =C2=A0 =C2=A0flowGroups: [
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0semantics: "SIM",
    > =C2=A0 =C2=A0 =C2=A0ssrcs: [2222, 2223, 2224]
    > =C2=A0 =C2=A0},
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0semantics: "FEC",
    > =C2=A0 =C2=A0 =C2=A0ssrcs: [2222, 2225]
    > =C2=A0 =C2=A0}]
    > =C2=A0}]
    > }
    >
    >
    > Constructive feedback is welcome :).
    >
    > _______________________________________________<= br> > rtcweb mailing list
    > rtcweb@ietf.org
    >     https://www.ietf.org/mailman/listinfo/rtcweb
    >

    --bcaec5314817ddbb9004df5e933c-- From pthatcher@google.com Mon Jun 17 12:33:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1B621E8054 for ; Mon, 17 Jun 2013 12:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTbZjuf38CaU for ; Mon, 17 Jun 2013 12:33:18 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id C169821E8053 for ; Mon, 17 Jun 2013 12:33:18 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id 14so3107109pdj.12 for ; Mon, 17 Jun 2013 12:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RLjYjdq1d7ZGtLe6oi7lig8+KH0QWWQUFJLxR9D1BHM=; b=EQJN9OvqDKUKN7LcsbAC3Gnh3qZmzcPKjoJWRjNbiexojRciQtQ3KZXBQ6qR9Y9+Ez ohK0aDqYHcE2iF+NI5eH7Z56+x5EI8WBMLpDgDZuHFa5DMbKZrkPY39U1tg2L+LI81P8 kxvT7X9Mi2kBFK6yjQbJRCU3wDwToJienYJzZr/6BvmL+aJ1973C6g0LY3KXHGkfSRsa RTepjIxm0ZHpgRmr0CqceXyimXSgtCvl3UY+2CRdI77ha8YCyDd5oZ1nSc6xBmKDcwTi 29pTclW09cHqHmPhY/dDA/pJAvskTlg28SQuTFOGYiD2Gs/uA8egPRVydIcpjtYZ1oyZ Jbig== 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=RLjYjdq1d7ZGtLe6oi7lig8+KH0QWWQUFJLxR9D1BHM=; b=An62nXXu/tnuDELqwghn396hCK/GwwXisX7G6pMQVnyjsyfUktYK9ggiIFrFl2z525 Xg7/naikKjxMNcx12K0WLcBFYLOb+/cQYXWvmSccjbG8783f+ImSVSNLUB+apvQKgHEL TG57QDVdZClkWbwNU2SvuB2jMGMGCfjUMq+Hz+2BLwRkaS5NtytEUsX7/wxemoN1FtHQ aYnhasTWCx5Vh+nQAsTG8bYVrmIFkXhXfolEZ8DNhb3aXwUy9lXQtpodjBQe5VODaBnr tjsuGArBfotWMveCTnaa4+5MCb6vyd7POdzANn+g7QrdFsBeK5ysMAImeUi/VLfg3MQi uJbw== X-Received: by 10.68.69.108 with SMTP id d12mr14207736pbu.187.1371497598423; Mon, 17 Jun 2013 12:33:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Mon, 17 Jun 2013 12:32:38 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C2FC071@ESESSMB209.ericsson.se> <57A15FAF9E58F841B2B1651FFE16D28104C918@GENSJZMBX01.msg.int.genesyslab.com> From: Peter Thatcher Date: Mon, 17 Jun 2013 12:32:38 -0700 Message-ID: To: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= Content-Type: multipart/alternative; boundary=0015174989ee2a392c04df5eab20 X-Gm-Message-State: ALoCoQnWj64WcH2p3ClMIt0Fsj/UlFOAok7LbHW6JCSxFEUdhkySZuk4wwSW9LYPRVdcAkc079Y8BDU0dI/ZdwkHqoWaB5EuO9aET6fV4/RDAacLWfTY5GoA4DwekZuEvJ5dB6jY97+wDBBzvrQ1IQ6kDmM/udJn5/TKbsNqjevhFe3fXiryWIM7mESuYNiw+yHsmcQziXUv Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 19:33:23 -0000 --0015174989ee2a392c04df5eab20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What do you mean by "change to an existing media stream"? Do you mean adding and removing tracks? I don't know of any other changes that can be made to a MediaStream. On Mon, Jun 17, 2013 at 11:52 AM, Jos=C3=A9 Luis Mill=C3=A1n wrote: > Hi, > > > 2013/6/17 Peter Thatcher > >> In that use case, just call createLocalStream again with the new >> MediaStream from GetUserMedia and get a new LocalMediaStream. There's n= o >> need to alter the existing one. >> >> > On the receiver side, I would expect to represent each remote MediaStream > on its own audio+video display element. > > If, as a sender, I create a new LocalStream to represent a change in an > existent media stream source, how will the receiver notice that the NEW > MediaStream does refer to the previous one? > > > > >> >> On Mon, Jun 17, 2013 at 9:34 AM, I=C3=B1aki Baz Castillo = wrote: >> >>> 2013/6/17 Peter Thatcher : >>> > But I don't really see a use case where you would need to add tracks >>> to a >>> > MediaStreamTrackDescription, other than when parsing signalling and >>> building >>> > the MediaStreamTrackDescription to send down into createRemoteStream. >>> > Perhaps if we had a use case, we could define such support. But >>> otherwise, >>> > I'd say it's not allowed. >>> >>> Use case: >>> >>> - Start a session/call with just audio (no video requested to the user >>> via getUserMedia). >>> - Latter the user wants to add video. >>> - For that a new getUserMedia(video: true) is requested. >>> - Extract the video track from the obtained MediaStream and add it to >>> the PC. >>> >>> Hope this is an enough common use case. >>> >>> >>> -- >>> I=C3=B1aki Baz Castillo >>> >>> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > > -- > Jos=C3=A9 Luis Mill=C3=A1n > --0015174989ee2a392c04df5eab20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    What do you mean by "change to an existing media stre= am"? =C2=A0Do you mean adding and removing tracks? =C2=A0I don't k= now of any other changes that can be made to a MediaStream.


    On Mon, Jun 17, 2013 at 11:52 AM, Jos=C3= =A9 Luis Mill=C3=A1n <jmillan@aliax.net> wrote:
    Hi,


    2013/6/17 Peter Thatcher <pthatcher@google.com= >
    In that use case, just call createLocalStream again with t= he new MediaStream from GetUserMedia and get a new LocalMediaStream. =C2=A0= There's no need to alter the existing one.


    On the receiver side, I would expect to represent each remote = MediaStream on its own audio+video display element.

    If, as a sender, I create a new LocalStream to represent a change in a= n existent media stream source, how will the receiver notice that the NEW M= ediaStream does refer to the previous one?


    =C2=A0

    On Mon, Jun 17, 2013 at 9:34 AM, I=C3=B1aki = Baz Castillo <ibc@aliax.net> wrote:
    2013/6/17 Peter Thatcher <pthatcher@google.com>:
    > But I don't really see a use case where you would need to add= tracks to a
    > MediaStreamTrackDescription, other than when parsing signalling and bu= ilding
    > the MediaStreamTrackDescription to send down into createRemoteStream.<= br> > Perhaps if we had a use case, we could define such support. =C2=A0But = otherwise,
    > I'd say it's not allowed.

    Use case:

    - Start a session/call with just audio (no video requested to the user
    via getUserMedia).
    - Latter the user wants to add video.
    - For that a new getUserMedia(video: true) is requested.
    - Extract the video track from the obtained MediaStream and add it to the P= C.

    Hope this is an enough common use case.


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


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


    <= br clear=3D"all">

    --
    Jos=C3=A9 Luis Mill=C3=A1n

    --0015174989ee2a392c04df5eab20-- From jmillan@aliax.net Mon Jun 17 12:42:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5179521F9DE5 for ; Mon, 17 Jun 2013 12:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBNBZZjefBHL for ; Mon, 17 Jun 2013 12:42:53 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 79ED821F9DE1 for ; Mon, 17 Jun 2013 12:42:53 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id gf11so2296469vcb.25 for ; Mon, 17 Jun 2013 12:42:52 -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=YZwPKbcUbnlrc76T6LAbZcoCgcsWOcvDxpcbmcaFRTM=; b=iVHuVf467YWFLjEN3DElbVRU+n6NXc5DBd/10OG5j58gcaREVvgfiLFq4kiscFa1IH wE4IWzRm8TinwbcRlu3nLGFzSWJ2Dk6DE7QCrmrs8LCtxUW+c/JrAByRBxt9+Zu2U0qn gvHeo4ExIiTyF9Qm5znTXiQmEQHNdQDhptQ9cj0CJ22GNxm03A1m5dtvovx5Imxz3Nxu 9EoVgjDCL1np7b9Druj+Eu1Hcq/PjemUkyXFKI23YQW0bjIdzuZhRPvCVVG5PNDJ+0KY ICK/dZp9A5QEpCLQEXR54scbChsTjdoF48if+6CR8JWptYwRIeHhQvjH6uK1TITc+AAu Wzug== MIME-Version: 1.0 X-Received: by 10.52.90.168 with SMTP id bx8mr676792vdb.62.1371498172794; Mon, 17 Jun 2013 12:42:52 -0700 (PDT) Received: by 10.220.215.131 with HTTP; Mon, 17 Jun 2013 12:42:52 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C2FC071@ESESSMB209.ericsson.se> <57A15FAF9E58F841B2B1651FFE16D28104C918@GENSJZMBX01.msg.int.genesyslab.com> Date: Mon, 17 Jun 2013 21:42:52 +0200 Message-ID: From: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= To: Peter Thatcher Content-Type: multipart/alternative; boundary=20cf307f3346665f7d04df5ecd65 X-Gm-Message-State: ALoCoQlTIXGF5fpm+6uf+mYVgMyigweKlb/pYVZ7P1NRXgBUaCd42G/qi4rs1AePApuBI9x2ZHsM Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 19:42:59 -0000 --20cf307f3346665f7d04df5ecd65 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, just adding and removing tracks. Regards 2013/6/17 Peter Thatcher > What do you mean by "change to an existing media stream"? Do you mean > adding and removing tracks? I don't know of any other changes that can b= e > made to a MediaStream. > > > On Mon, Jun 17, 2013 at 11:52 AM, Jos=C3=A9 Luis Mill=C3=A1n wrote: > >> Hi, >> >> >> 2013/6/17 Peter Thatcher >> >>> In that use case, just call createLocalStream again with the new >>> MediaStream from GetUserMedia and get a new LocalMediaStream. There's = no >>> need to alter the existing one. >>> >>> >> On the receiver side, I would expect to represent each remote MediaStrea= m >> on its own audio+video display element. >> >> If, as a sender, I create a new LocalStream to represent a change in an >> existent media stream source, how will the receiver notice that the NEW >> MediaStream does refer to the previous one? >> >> >> >> >>> >>> On Mon, Jun 17, 2013 at 9:34 AM, I=C3=B1aki Baz Castillo wrote: >>> >>>> 2013/6/17 Peter Thatcher : >>>> > But I don't really see a use case where you would need to add tracks >>>> to a >>>> > MediaStreamTrackDescription, other than when parsing signalling and >>>> building >>>> > the MediaStreamTrackDescription to send down into createRemoteStream= . >>>> > Perhaps if we had a use case, we could define such support. But >>>> otherwise, >>>> > I'd say it's not allowed. >>>> >>>> Use case: >>>> >>>> - Start a session/call with just audio (no video requested to the user >>>> via getUserMedia). >>>> - Latter the user wants to add video. >>>> - For that a new getUserMedia(video: true) is requested. >>>> - Extract the video track from the obtained MediaStream and add it to >>>> the PC. >>>> >>>> Hope this is an enough common use case. >>>> >>>> >>>> -- >>>> I=C3=B1aki Baz Castillo >>>> >>>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >> >> >> -- >> Jos=C3=A9 Luis Mill=C3=A1n >> > > --=20 Jos=C3=A9 Luis Mill=C3=A1n --20cf307f3346665f7d04df5ecd65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Yes, just adding and removing tracks.

    R= egards


    2013/6/17 Peter Thatcher <pthatcher@google.com>
    What do you mean by "c= hange to an existing media stream"? =C2=A0Do you mean adding and remov= ing tracks? =C2=A0I don't know of any other changes that can be made to= a MediaStream.


    On Mon, Jun 17, 2013 at 11:52 AM, Jos=C3= =A9 Luis Mill=C3=A1n <jmillan@aliax.net> wrote:
    Hi,


    2013/6/17 Peter Thatcher <pthatcher@google.com>
    In that use case, just call createLocalStream again with t= he new MediaStream from GetUserMedia and get a new LocalMediaStream. =C2=A0= There's no need to alter the existing one.


    On the receiver side, I would expect to represent each remote = MediaStream on its own audio+video display element.

    If, as a sender, I create a new LocalStream to represent a change in a= n existent media stream source, how will the receiver notice that the NEW M= ediaStream does refer to the previous one?


    =C2=A0

    On Mon, Jun 17, 2013 at 9:34 AM, I=C3=B1aki = Baz Castillo <ibc@aliax.net> wrote:
    2013/6/17 Peter Thatcher <pthatcher@google.com>:
    > But I don't really see a use case where you would need to add= tracks to a
    > MediaStreamTrackDescription, other than when parsing signalling and bu= ilding
    > the MediaStreamTrackDescription to send down into createRemoteStream.<= br> > Perhaps if we had a use case, we could define such support. =C2=A0But = otherwise,
    > I'd say it's not allowed.

    Use case:

    - Start a session/call with just audio (no video requested to the user
    via getUserMedia).
    - Latter the user wants to add video.
    - For that a new getUserMedia(video: true) is requested.
    - Extract the video track from the obtained MediaStream and add it to the P= C.

    Hope this is an enough common use case.


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


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



    =

    --
    Jos=C3=A9 Luis Mill=C3=A1n




    --
    = Jos=C3=A9 Luis Mill=C3=A1n --20cf307f3346665f7d04df5ecd65-- From pthatcher@google.com Mon Jun 17 12:54:25 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC08121F9CF3 for ; Mon, 17 Jun 2013 12:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.406 X-Spam-Level: X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-4+bj2xFeU4 for ; Mon, 17 Jun 2013 12:54:20 -0700 (PDT) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by ietfa.amsl.com (Postfix) with ESMTP id 5490D21F9CCA for ; Mon, 17 Jun 2013 12:54:16 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id 10so3096328pdi.25 for ; Mon, 17 Jun 2013 12:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LuzzBZijFelJwXW/l6RBougBrSbdEdLEmHfrrc8iFHE=; b=IYtxzj1KsTRy3zyLzu+LPBJ9chC06vAoO33IQ97KOZDTMvG/NuOOuztel7S1HJ7fDA xCOqjsePvaZcTppfl7hoCf+VDbOQS+Abg6vOw3IjhsaUd3ISPMNqAbeOc58/xF3FosTv LDEeHrFlVSImuFUTEuZ6bNWtkIrFQiUPNfWVxHAOPc10VK8ubwee5E5ft3aUxI3omUsq wDKQhhdLq5Bc9pFRZxFzB2ekWEB2WUAlfLL7wsC86wYiKB5ZmV+0zkH03GXR9ad+JjSD UkN1tFhpeu5D7tgsgog0bae7yzdvhkPleJvGPr2MsxFpZS6vQi8MaheUVy0SU2bm/CuQ eaBQ== 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=LuzzBZijFelJwXW/l6RBougBrSbdEdLEmHfrrc8iFHE=; b=YuJbYpBbTZF2adWg0tlQauCjajd6xR5rv0RNu6tQlb379OxqjDwU015Y4nhfJoVUG1 N043if7HoqDvUBk/bgJH70GZUBM2V5EXSUKPsdkHIywZx0OSP7pTQVkiLgR1idOuMflJ dpTW+KBe/w3Cfrs/llHCIFi6v5v5hqPxCsBoAyVxJD4b2Cf+kscHKk8VDTKNyYZrpv7C UAd+mX0rNGSdGRDQvWYcPgdKG5qbooTlCfik6vnfR2j4vaeRZaM410jIejNhiYXzqhFf k2fBBQ3TL+K5mu+FOs9sOnguVMNjDREVxCWyDBx2XxWrGbQwk4+Ma7bC4RzEgiBbePDM FQGA== X-Received: by 10.66.251.202 with SMTP id zm10mr14317328pac.53.1371498856022; Mon, 17 Jun 2013 12:54:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Mon, 17 Jun 2013 12:53:35 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C2FC071@ESESSMB209.ericsson.se> <57A15FAF9E58F841B2B1651FFE16D28104C918@GENSJZMBX01.msg.int.genesyslab.com> From: Peter Thatcher Date: Mon, 17 Jun 2013 12:53:35 -0700 Message-ID: To: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= Content-Type: multipart/alternative; boundary=047d7b15a3851f9bad04df5ef69c X-Gm-Message-State: ALoCoQkHg3a+fpQ0pSqdzGSBTQVLvKUAmUI8ghSApZXlHW6lZv4lYWlju8aeZat2DsMWZyfzv7QfFj2W4AMf3t71rJ6nd0S3pdfJBhUgx214IvADbz4GeDyqJ1AOR7FdPRcdG8ehjPlbhmsAXLGZOAbh9A5j8hCVVbuBFgr6xnjmN8dC4GjX5nW5pUqfgGTtPkOKLkk5XSmu Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 19:54:25 -0000 X-List-Received-Date: Mon, 17 Jun 2013 19:54:25 -0000 --047d7b15a3851f9bad04df5ef69c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To remove a track, stop/remove the track locally and signal the fact that the track is stopped to the remote side (in an app specific way). To add a track, don't modify the existing MediaStream. Create a new MediaStream and call createLocalStream with the new MediaStream, and then signal the MediaStreamDescription for it to the remote side. If you really want two MediaStreams to be merged into one MediaStream (the previous one and the new one), signal that desire to the remote side (in an app specific way), and the remote JS application can handle merging them. The key here is that that we need an API for telling the browser how to send tracks and how to receive tracks, and this provides it. How those tracks get arranged into MediaStreams can be done completely by JS and app-specific signalling. In fact, we could model this entirely as PeerConnection.createLocalTrack and createRemoteTrack instead of .createLocalStream and createRemoteStream, but we kept is stream-oriented because it works better with the existing methods in the simple cases. On Mon, Jun 17, 2013 at 12:42 PM, Jos=C3=A9 Luis Mill=C3=A1n wrote: > Yes, just adding and removing tracks. > > Regards > > > 2013/6/17 Peter Thatcher > >> What do you mean by "change to an existing media stream"? Do you mean >> adding and removing tracks? I don't know of any other changes that can = be >> made to a MediaStream. >> >> >> On Mon, Jun 17, 2013 at 11:52 AM, Jos=C3=A9 Luis Mill=C3=A1n wrote: >> >>> Hi, >>> >>> >>> 2013/6/17 Peter Thatcher >>> >>>> In that use case, just call createLocalStream again with the new >>>> MediaStream from GetUserMedia and get a new LocalMediaStream. There's= no >>>> need to alter the existing one. >>>> >>>> >>> On the receiver side, I would expect to represent each remote >>> MediaStream on its own audio+video display element. >>> >>> If, as a sender, I create a new LocalStream to represent a change in an >>> existent media stream source, how will the receiver notice that the NEW >>> MediaStream does refer to the previous one? >>> >>> >>> >>> >>>> >>>> On Mon, Jun 17, 2013 at 9:34 AM, I=C3=B1aki Baz Castillo wrote: >>>> >>>>> 2013/6/17 Peter Thatcher : >>>>> > But I don't really see a use case where you would need to add track= s >>>>> to a >>>>> > MediaStreamTrackDescription, other than when parsing signalling and >>>>> building >>>>> > the MediaStreamTrackDescription to send down into createRemoteStrea= m. >>>>> > Perhaps if we had a use case, we could define such support. But >>>>> otherwise, >>>>> > I'd say it's not allowed. >>>>> >>>>> Use case: >>>>> >>>>> - Start a session/call with just audio (no video requested to the use= r >>>>> via getUserMedia). >>>>> - Latter the user wants to add video. >>>>> - For that a new getUserMedia(video: true) is requested. >>>>> - Extract the video track from the obtained MediaStream and add it to >>>>> the PC. >>>>> >>>>> Hope this is an enough common use case. >>>>> >>>>> >>>>> -- >>>>> I=C3=B1aki Baz Castillo >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>> >>> >>> -- >>> Jos=C3=A9 Luis Mill=C3=A1n >>> >> >> > > > -- > Jos=C3=A9 Luis Mill=C3=A1n > --047d7b15a3851f9bad04df5ef69c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    To remove a track, stop/remove the track locally and signa= l the fact that the track is stopped to the remote side (in an app specific= way).

    To add a track, don't modify the existi= ng MediaStream. =C2=A0Create a new MediaStream and call createLocalStream w= ith the new MediaStream, and then signal the MediaStreamDescription for it = to the remote side. =C2=A0If you really want two MediaStreams to be merged = into one MediaStream (the previous one and the new one), signal that desire= to the remote side (in an app specific way), and the remote JS application= can handle merging them.

    The key here is that that we need an API fo= r telling the browser how to send tracks and how to receive tracks, and thi= s provides it. =C2=A0How those tracks get arranged into MediaStreams can be= done completely =C2=A0by JS and app-specific signalling. =C2=A0In fact, we= could model this entirely as PeerConnection.createLocalTrack and createRem= oteTrack instead of .createLocalStream and createRemoteStream, but we kept = is stream-oriented because it works better with the existing methods in the= simple cases.=C2=A0


    On Mon,= Jun 17, 2013 at 12:42 PM, Jos=C3=A9 Luis Mill=C3=A1n <= ;jmillan@aliax.net> wrote:
    Yes, just adding and removi= ng tracks.

    Regards


    2013/6/17 Peter Thatch= er <pthatcher@google.com>
    What do you mean by "c= hange to an existing media stream"? =C2=A0Do you mean adding and remov= ing tracks? =C2=A0I don't know of any other changes that can be made to= a MediaStream.


    On Mon, Jun 17, 2013 at 11:52 AM, Jos=C3= =A9 Luis Mill=C3=A1n <jmillan@aliax.net> wrote:
    Hi,


    2013/6/17 Peter Thatcher <pthatcher@google.com>
    In that use case, just call createLocalStream again with t= he new MediaStream from GetUserMedia and get a new LocalMediaStream. =C2=A0= There's no need to alter the existing one.


    On the receiver side, I would expect to represent each remote = MediaStream on its own audio+video display element.

    If, as a sender, I create a new LocalStream to represent a change in a= n existent media stream source, how will the receiver notice that the NEW M= ediaStream does refer to the previous one?


    =C2=A0

    On Mon, Jun 17, 2013 at 9:34 AM, I=C3=B1aki = Baz Castillo <ibc@aliax.net> wrote:
    2013/6/17 Peter Thatcher <pthatcher@google.com>:
    > But I don't really see a use case where you would need to add= tracks to a
    > MediaStreamTrackDescription, other than when parsing signalling and bu= ilding
    > the MediaStreamTrackDescription to send down into createRemoteStream.<= br> > Perhaps if we had a use case, we could define such support. =C2=A0But = otherwise,
    > I'd say it's not allowed.

    Use case:

    - Start a session/call with just audio (no video requested to the user
    via getUserMedia).
    - Latter the user wants to add video.
    - For that a new getUserMedia(video: true) is requested.
    - Extract the video track from the obtained MediaStream and add it to the P= C.

    Hope this is an enough common use case.


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


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



    =

    --
    Jos=C3=A9 Luis Mill=C3=A1n




    <= /div>--
    Jos=C3=A9 Luis M= ill=C3=A1n
    --047d7b15a3851f9bad04df5ef69c-- From jim.barnett@genesyslab.com Mon Jun 17 13:08:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C604F21F9B79 for ; Mon, 17 Jun 2013 13:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAc3zhXfQv0j for ; Mon, 17 Jun 2013 13:07:52 -0700 (PDT) Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id 6C04D21F9C19 for ; Mon, 17 Jun 2013 13:07:49 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.3 [168.75.250.3]) (Using TLS) by service107-us.mimecast.com; Mon, 17 Jun 2013 16:07:47 -0400 Received: from GENSJZMBX01.msg.int.genesyslab.com ([fe80::c80a:d985:3cca:a5e7]) by GENSJZFE01.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 13:07:44 -0700 From: Jim Barnett To: Peter Thatcher , Martin Thomson Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) Thread-Index: AQHOa1pIZXTOQ/GlLUKrYtD/Xog7c5k6t70AgAAH7oD//5TcoA== Date: Mon, 17 Jun 2013 20:07:44 +0000 Message-ID: <57A15FAF9E58F841B2B1651FFE16D28104FB3E@GENSJZMBX01.msg.int.genesyslab.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.7.220.231] MIME-Version: 1.0 X-MC-Unique: 113061716074705901 Content-Type: multipart/alternative; boundary="_000_57A15FAF9E58F841B2B1651FFE16D28104FB3EGENSJZMBX01msgint_" Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 20:08:08 -0000 --_000_57A15FAF9E58F841B2B1651FFE16D28104FB3EGENSJZMBX01msgint_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 UGV0ZXIsDQpZb3Ugc2F5IHRoYXQgb25seSBpbml0aWFsIFBlZXJDb25uZWN0aW9uIHNldCB1cCBy ZXF1aXJlcyBvZmZlciBhbnN3ZXIuICAgV2hlcmUgaXMgdGhhdCBpbiB5b3VyIGV4YW1wbGU/ICBJ biB0aGUgZXhhbXBsZSwgYWxsIHdlIHNlZSBvbiB0aGUgcmVjZWl2aW5nIHNpZGUgaXMgdGhhdCBp dCBjYWxscyBjcmVhdGVSZWNlaXZlU3RyZWFtLg0KDQoNCi0gICAgICAgICAgSmltDQoNCkZyb206 IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBQZXRlciBUaGF0Y2hlcg0KU2VudDogTW9uZGF5LCBKdW5lIDE3LCAyMDEz IDM6MjYgUE0NClRvOiBNYXJ0aW4gVGhvbXNvbg0KQ2M6IDxydGN3ZWJAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW3J0Y3dlYl0gUHJvcG9zYWwgZm9yIGEgSlMgQVBJIGZvciBOb1BsYW4gKGFkZGlu ZyBtdWx0aXBsZSBzb3VyY2VzIHdpdGhvdXQgZW5jb2RpbmcgdGhlbSBpbiBTRFApDQoNClllcywg SSB3YXMgZXhwZWN0aW5nIHlvdSB0byBiZSBtb3JlIHN1cHBvcnRpdmUuICBJJ20gc3VycHJpc2Vk IG91dCBob3cgeW91ciB3YW50ICJhbGwgb3Igbm90aGluZyIuICBJJ20gYWZyYWlkIGlmIG91ciBv cHRpb25zIGZvciBhIGNsZWFuIEFQSSBhcmUgYWxsIG9yIG5vdGhpbmcsIHdlJ2xsIGp1c3QgZW5k IHVwIHdpdGggbm90aGluZy4gIEknZCBwcmVmZXIgdG8gdHJ5IGluY3JlbWVudGFsIGltcHJvdmVt ZW50cyB0byB3b3JkIHRvd2FyZCAoZXZlbnR1YWxseSkgYSBjbGVhbiBBUEkuDQoNCkRvIHlvdSB0 aGluayBpdCBpcyBpbXBvc3NpYmxlIHRvIHdvcmsgdG93YXJkIGEgY2xlYW4gQVBJIGluIGFuIGlu Y3JlbWVudGFsIGFwcHJvYWNoPyAgSWYgeW91IHRoaW5rIGl0J3MgcG9zc2libGUsIEknZCBsaWtl IHRvIGhlYXIgeW91ciB0aG91Z2h0cyBvbiBob3cuDQoNCg0KQnkgdGhlIHdheSwgdGhlc2UgQVBJ IGFkZGl0aW9ucyB3b3VsZCBncmVhdGx5IG1pbmltaXplIHRoZSBhbW91bnQgb2YgU0RQIGVkaXRp bmcgbmVjZXNzYXJ5IGZvciBKUyBjbGllbnRzIHRoYXQgZG9uJ3QgdXNlIFNEUCBmb3Igc2lnbmFs bGluZy4gIEFuZCBsYXRlciBpbmNyZW1lbnRhbCBpbXByb3ZlbWVudHMgY291bGQgcmVkdWNlIGl0 IGZ1cnRoZXIuICBBbHNvLCBpdCdzIG5vIGxvbmdlciBuZWNlc3NhcnkgdG8gZG8gb2ZmZXIvYW5z d2VyIGZvciBhZGRpbmcgdHJhY2tzLiAgSXQncyBvbmx5IHRoZSBpbnRpYWwgUGVlckNvbm5lY3Rp b24gc2V0dXAgdGhhdCBuZWVkcyB0byBkbyBPZmZlci9BbnN3ZXIuICBTbywgaXQgZG9lc24ndCBp bmhlcml0IGFsbCB0aGUgcHJvYmxlbXMgcXVpdGUgYXMgbXVjaCBhcyB5b3UgZGVzY3JpYmVkLiAg SXQgbWF5IGJlIHNsaWdodGx5IGFib21pbmFibGUsIGJ1dCBJIGNlcnRhaW5seSBjb25zaWRlciBp dCBsZXNzIGFib21pbmFibGUgdGhhbiB0aGUgU0RQIGVkaXRpbmcgbmVjZXNzYXJ5IHdpdGhvdXQg aXQuDQoNCk9uIE1vbiwgSnVuIDE3LCAyMDEzIGF0IDExOjU3IEFNLCBNYXJ0aW4gVGhvbXNvbiA8 bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+ PiB3cm90ZToNCk1heWJlIHlvdSdkIGV4cGVjdCBtZSB0byBiZSBtb3JlIHN1cHBvcnRpdmUgb2Yg c29tZXRoaW5nIHRoYXQgbG9va2VkDQpzbyBtdWNoIGxpa2UgQ1UtUlRDLVdlYi4gIEl0IGluaGVy aXRzIGFsbCB0aGUgd29yc3QgcHJvcGVydGllcyBvZiBKU0VQDQooT2ZmZXIvQW5zd2VyLCBTRFAg ZWRpdGluZykgd2l0aCBhIHBhcnRpYWwgaW1wbGVtZW50YXRpb24gb2YgYSBjbGVhbg0KQVBJLg0K DQpJdCdzIGNvbW1lbnQgMjItbGl0ZS4gIEl0J3MgYW4gYWJvbWluYXRpb24uICBJZiB5b3UgYXJl IGdvaW5nIHRvIGRvDQp0aGlzLCBkbyBpdCBwcm9wZXJseS4NCg0KT24gMTcgSnVuZSAyMDEzIDA1 OjU3LCBQZXRlciBUaGF0Y2hlciA8cHRoYXRjaGVyQGdvb2dsZS5jb208bWFpbHRvOnB0aGF0Y2hl ckBnb29nbGUuY29tPj4gd3JvdGU6DQo+IEdvb2dsZSBpcyBpbiBmdWxsIHN1cHBvcnQgb2YgIlBs YW4gQiIgZm9yIGVuY29kaW5nIG11bHRpcGxlIG1lZGlhIHNvdXJjZXMgaW4NCj4gU0RQLCBhbmQg d291bGQgbGlrZSB0byBzZWUgdGhlIFBsYW4gQSB2cy4gUGxhbiBCIGRlY2lzaW9uIHJlc29sdmVk IHNvb24uDQo+IFJlY2VudGx5LCB0aG91Z2gsIGEgdGhpcmQgb3B0aW9uLCBjYWxsZWQgIk5vUGxh biIgaGFzIGJlZW4gcHJvcG9zZWQsIGJ1dCBpdA0KPiBsYWNrZWQgdGhlIGRldGFpbHMgb2Ygd2hh dCBhIEpTIEFQSSB3b3VsZCBsb29rIGxpa2UgZm9yIE5vUGxhbi4gIEN1bGxlbg0KPiBhc2tlZCB0 byBzZWUgc3VjaCBhbiBBUEkgcHJvcG9zYWwsIGFuZCBzbyBJIGhhdmUgd29ya2VkIHdpdGggRW1p bCB0byBtYWtlDQo+IG9uZS4gIEhlIHdpbGwgYmUgYWRkaW5nIGl0IHRvIHRoZSBOb1BsYW4gZHJh ZnQsIGJ1dCBJIHdpbGwgYWxzbyBpbmNsdWRlIGl0DQo+IGluIHRoaXMgZW1haWwuDQo+DQo+IEFn YWluLCBHb29nbGUgaXMgaW4gZnVsbCBzdXBwb3J0IG9mICJQbGFuIEIiLiAgQnV0IGlmIFBsYW4g QSB2cy4gUGxhbiBCDQo+IGNhbm5vdCBiZSBkZWNpZGVkLCB0aGVuIHdlIHN1cHBvcnQgTm9QbGFu IHdpdGggdGhlIGZvbGxvd2luZyBhZGRpdGlvbnMgdG8NCj4gdGhlIFdlYlJUQyBKUyBBUEkgYXMg YW4gb3B0aW9uIHRoYXQgYWxsb3dzIGltcGxlbWVudGluZyBlaXRoZXIgUGxhbiBBIG9yDQo+IFBs YW4gQiAgaW4gSmF2YXNjcmlwdC4gIEFuZCBldmVuIGlmIFBsYW4gQSB2cy4gUGxhbiBCIGlzIHJl c29sdmVkLCB0aGVzZSBBUEkNCj4gYWRkaXRpb25zIHdvdWxkIHN0aWxsIGJlIGEgYmlnIGltcHJv dmVtZW50IGZvciB0aG9zZSBXZWJSVEMgYXBwbGljYXRpb25zDQo+IHRoYXQgZG9uJ3QgdXNlIFNE UCBmb3Igc2lnbmFsbGluZy4NCj4NCj4gSXQgaXMgYSBiaXQgbG9uZyBiZWNhdXNlIEkgaGF2ZSBh ZGRlZCBtYW55IGNvbW1lbnRzIGFuZCBleGFtcGxlcywgYnV0IHRoZQ0KPiBhY3R1YWxseSBhZGRp dGlvbnMgb25seSBpbmNsdWRlIHR3byBuZXcgbWV0aG9kcyBvbiBQZWVyQ29ubmVjdGlvbiBhbmQg YSBmZXcNCj4gbmV3IGRpY3Rpb25hcmllcy4gIFNvIGRvbid0IGJlIG92ZXJ3aGVsbWVkIDopLg0K Pg0KPg0KPg0KPiBJbnRybzogVGhpcyBmb2xsb3dzIHRoZSBtb2RlbCBvZiBjcmVhdGVEYXRhQ2hh bm5lbCwgd2hpY2ggaGFzIGEgSlMgbWV0aG9kIG9uDQo+IFBlZXJDb25uZWN0aW9uIHRoYXQgbWFr ZXMgaXQgcG9zc2libGUgdG8gYWRkIGRhdGEgY2hhbm5lbHMgd2l0aG91dCBnb2luZw0KPiB0aHJv dWdoIFNEUC4gIEZ1cnRoZXJtb3JlLCBqdXN0IGxpa2UgY3JlYXRlRGF0YUNoYW5uZWwgYWxsb3dz IDIgd2F5cyB0bw0KPiBoYW5kbGUgbmVvZ2l0YXRpb24gKHRoZSAiSSBrbm93IHdoYXQgSSdtIGRv aW5nOyAgSGVyZSdzIHdoYXQgSSB3YW50IHRvIHNlbmQ7DQo+IExldCBtZSBzaWduYWwgZXZlcnl0 aGluZyIgbW9kZSBhbmQgdGhlICJwbGVhc2UgdGFrZSBjYXJlIG9mIGl0IGZvciBtZTsgIHNlbmQN Cj4gYW4gT1BFTiBtZXNzYWdlIiBtb2RlKSwgdGhpcyBhbHNvIGhhcyAyIHdheXMgdG8gaGFuZGxl IG5lZ290aWF0aW9uICh0aGUgIkkNCj4ga25vdyB3aGF0IEknbSBkb2luZzsgSGVyZSdzIHdoYXQg SSB3YW50IHRvIHNlbmQ7IExldCBtZSBzaWduYWwgZXZlcnl0aGluZyINCj4gbW9kZSBhbmQgdGhl ICJwbGVhc2UgdGFrZSBjYXJlIG9mIGl0IGZvciBtZTsgIHNlbmQgU0RQIGJhY2sgYW5kIGZvcnRo Ig0KPiBtb2RlKS4NCj4NCj4gRm9sbG93aW5nIHRoZSBzdWNjZXNzIG9mIGNyZWF0ZURhdGFDaGFu bmVsLCB0aGlzIGFsbG93cyBzaW1wbGUgYXBwbGljYXRpb25zDQo+IHRvIEp1c3QgV29yayBhbmQg bW9yZSBhZHZhbmNlZCBhcHBsaWNhdGlvbnMgdG8gZWFzaWx5IGNvbnRyb2wgd2hhdCB0aGV5IG5l ZWQNCj4gdG8uICBJbiBwYXJ0aWN1bGFyLCBpdCdzIHBvc3NpYmxlIHRvIHVzZSB0aGlzIEFQSSB0 byBpbXBsZW1lbnQgZWl0aGVyIFBsYW4gQQ0KPiBvciBQbGFuIEIuDQo+DQo+IC8vIFRoZSBmb2xs b3dpbmcgdHdvIG1ldGhvZCBhcmUgYWRkZWQgdG8gUlRDUGVlckNvbm5lY3Rpb24NCj4gcGFydGlh bCBpbnRlcmZhY2UgUlRDUGVlckNvbm5lY3Rpb24gew0KPiAgLy8gQ3JlYXRlIGEgc3RyZWFtIHRo YXQgaXMgdXNlZCB0byBzZW5kIGEgc291cmNlIHN0cmVhbS4NCj4gIC8vIFRoZSBNZWRpYVNlbmRT dHJlYW0uZGVzY3JpcHRpb24gY2FuIGJlIHVzZWQgZm9yIHNpZ25hbGxpbmcuDQo+ICAvLyBObyBt ZWRpYSBpcyBzZW50IHVudGlsIGFkZFN0cmVhbShNZWRpYVNlbmRTdHJlYW0pIGlzIGNhbGxlZC4N Cj4gIExvY2FsTWVkaWFTdHJlYW0gY3JlYXRlTG9jYWxTdHJlYW0oTWVkaWFTdHJlYW0gc291cmNl U3RyZWFtKTsNCj4NCj4gIC8vIENyZWF0ZSBhIHN0cmVhbSB0aGF0IGlzIHVzZWQgdG8gcmVjZWl2 ZSBtZWRpYSBmcm9tIHRoZSByZW1vdGUgc2lkZSwNCj4gIC8vIGdpdmVuIHRoZSBwYXJhbWV0ZXJz IHNpZ25hbGxlZCBmcm9tIE1lZGFpU2VuZFN0cmVhbS5kZXNjcmlwdGlvbi4NCj4gIE1lZGlhU3Ry ZWFtIGNyZWF0ZVJlbW90ZVN0cmVhbShNZWRpYVN0cmVhbURlc2NyaXB0aW9uIGRlc2NyaXB0aW9u KTsNCj4gfQ0KPg0KPg0KPiBpbnRlcmZhY2UgTG9jYWxNZWRpYVN0cmVhbSBpbXBsZW1lbnRzIE1l ZGlhU3RyZWFtIHsNCj4gICAvLyBUaGlzIGNhbiBiZSBjaGFuZ2VkIGF0IGFueSB0aW1lLCBidXQg ZXNwZWNpYWxseSBiZWZvcmUgY2FsbGluZw0KPiAgIC8vIFBlZXJDb25uZWN0aW9uLmFkZFN0cmVh bQ0KPiAgIGF0dHJpYnV0ZSBNZWRpYVN0cmVhbURlc2NyaXB0aW9uIGRlc2NyaXB0aW9uOw0KPiB9 DQo+DQo+DQo+IC8vIFJlcHJlc2VudHMgdGhlIHBhcmFtZXRlcnMgdXNlZCB0byBlaXRoZXIgc2Vu ZCBvciByZWNlaXZlIGEgc3RyZWFtDQo+IC8vIG92ZXIgYSBQZWVyQ29ubmVjdGlvbi4NCj4gZGlj dGlvbmFyeSBNZWRpYVN0cmVhbURlc2NyaXB0aW9uIHsNCj4gICBNZWRpYVN0cmVhbVRyYWNrRGVz Y3JpcHRpb25bXSB0cmFja3M7DQo+IH0NCj4NCj4NCj4gLy8gUmVwcmVzZW50cyB0aGUgcGFyYW1l dGVycyB1c2VkIHRvIGVpdGhlciBzZW5kIG9yIHJlY2VpdmUgYSB0cmFjayBvdmVyIC8vDQo+IGEg UGVlckNvbm5lY3Rpb24uICBBIHRyYWNrIGhhcyBtYW55ICJmbG93cyIsIHdoaWNoIGNhbiBiZSBn cm91cGVkDQo+IC8vIHRvZ2V0aGVyLg0KPiBkaWN0aW9uYXJ5IE1lZGlhU3RyZWFtVHJhY2tEZXNj cmlwdGlvbiB7DQo+ICAgLy8gU2FtZSBhcyB0aGUgTWVkaWFTdHJlYW1UcmFjay5pZA0KPiAgIERP TVN0cmluZyBpZDsNCj4NCj4gICAvLyBTYW1lIGFzIHRoZSBNZWRpYVN0cmVhbVRyYWNrLmtpbmQN Cj4gICBET01TdHJpbmcga2luZDsNCj4NCj4gICAvLyBBIHRyYWNrIGNhbiBoYXZlIG1hbnkgImZs b3dzIiwgc3VjaCBhcyBmb3IgU2ltdWxjYXN0LCBGRUMsIGV0Yy4NCj4gICAvLyBBbmQgdGhleSBj YW4gYmUgZ3JvdXBlZCBpbiBhcmJpdHJhcnkgd2F5cy4NCj4gICBNZWRpYUZsb3dEZXNjcmlwdGlv bltdIGZsb3dzOw0KPiAgIE1lZGlhRmxvd0dyb3VwW10gZmxvd0dyb3VwczsNCj4gfQ0KPg0KPiAv LyBSZXByZXNlbnRzIHRoZSBwYXJhbWV0ZXJzIHVzZWQgdG8gZWl0aGVyIHNlbmQgb3IgcmVjZWl2 ZSBhICJmbG93Ig0KPiAvLyBvdmVyIGEgUGVlckNvbm5lY3Rpb24uICBBICJmbG93IiBpcyBhIG1l ZGlhIHRoYXQgYXJyaXZlcyB3aXRoIGENCj4gLy8gc2luZ2xlLCB1bmlxdWUgU1NSQy4gIE9uZSB0 byBtYW55IGZsb3dzIHRvZ2V0aGVyIG1ha2UgdXAgdGhlIG1lZGlhDQo+IC8vIGZvciBhIHRyYWNr LiAgRm9yIGV4YW1wbGUsIHRoZXJlIG1heSBiZSBTaW11bGNhc3QsIEZFQywgYW5kIFJUWA0KPiAv LyBmbG93cy4NCj4gZGljdGlvbmF5IE1lZGlhRmxvd0Rlc2NyaXB0aW9uIHsNCj4gICAvLyBUaGUg ImZsb3cgaWQiIG11c3QgYmUgdW5pcXVlIHRvIHRoZSB0cmFjaywgYnV0IG5lZWQgbm90IGJlIHVu aXF1ZQ0KPiAgIC8vIG91dHNpZGUgb2YgdGhlIHRyYWNrICh0d28gdHJhY2tzIGNvdWxkIGJvdGgg aGF2ZSBhIGZsb3cgd2l0aCB0aGUNCj4gICAvLyBzYW1lIGZsb3cgSUQpLg0KPiAgIERPTVN0cmlu ZyBpZDsNCj4NCj4gICAvLyBFYWNoIGZsb3cgY2FuIGdvIG92ZXIgaXRzIG93biB0cmFuc3BvcnQu ICBJZiB0aGUgSlMgc2V0cyB0aGlzIHRvIGENCj4gICAvLyB0cmFuc3BvcnRJZCB0aGF0IGRvZXNu J3QgaGF2ZSBhIHRyYW5zcG9ydCBzZXR1cCBhbHJlYWR5LCB0aGUNCj4gICAvLyBicm93c2VyIHdp bGwgdXNlIFNEUCBuZWdvdGlhdGlvbiB0byBzZXR1cCBhIHRyYW5zcG9ydCB0byBiYWNrIHRoYXQN Cj4gICAvLyB0cmFuc3BvcnRJZC4gIElmIFRoaXMgaXMgc2V0IHRvIGFuIE1JRCBpbiB0aGUgU0RQ LCB0aGVuIHRoYXQgTUlEJ3MNCj4gICAvLyB0cmFuc3BvcnQgaXMgdXNlZC4NCj4gICBET01TdHJp bmcgdHJhbnNwb3J0SWQ7DQo+DQo+ICAgLy8gVGhlIFNTUkMgdXNlZCB0byBzZW5kIHRoZSBmbG93 Lg0KPiAgIHVuc2lnbmVkIGludCBzc3JjOw0KPg0KPiAgIC8vIFdoZW4gdXNlZCBhcyByZWNlaXZl IHBhcmFtZXRlcnMsIHRoaXMgaW5kaWNhdGVzIHRoZSBwb3NzaWJsZSBsaXN0DQo+ICAgLy8gb2Yg Y29kZWNzIHRoYXQgbWlnaHQgY29tZSBpbiBmb3IgdGhpcyBmbG93LiAgRm9yIGV4bWFtcGxlLCBh IGdpdmVuDQo+ICAgLy8gcmVjZWl2ZSBmbG93IGNvdWxkIGJlIHNldHVwIHRvIHJlY2VpdmUgYW55 IG9mIE9QVVMsIElTQUMsIG9yIFBDTVUuDQo+ICAgLy8gV2hlbiB1c2VkIGFzIHNlbmQgcGFyYW1l dGVycywgdGhpcyBpbmRpY2F0ZXMgdGhhdCB0aGUgZmlyc3QgY29kZWMNCj4gICAvLyBzaG91bGQg YmUgdXNlZCwgYnV0IHRoZSBicm93c2VyIGNhbiB1c2Ugc2VuZCBvdGhlciBjb2RlY3MgaWYgaXQN Cj4gICAvLyBuZWVkcyB0byBiZWNhdXNlIG9mIGVpdGhlciBiYW5kd2lkdGggb3IgQ1BVIGNvbnN0 cmFpbnRzLg0KPiAgIE1lZGlhQ29kZWNEZXNjcmlwdGlvbltdIGNvZGVjczsNCj4gfQ0KPg0KPg0K PiBkaWN0aW9uYXJ5IE1lZGlhRmxvd0dyb3VwIHsNCj4gICBET01TdHJpbmcgdHlwZTsgIC8vICJT SU0iIGZvciBTaW11bGNhc3QsICJGRUMiIGZvciBGRUMsIGV0Yw0KPiAgIERPTVN0cmluZ1tdIGZs b3dpZHM7DQo+IH0NCj4NCj4gZGljdGlvbmFyeSBNZWRpYUNvZGVjRGVzY3JpcHRpb24gew0KPiAg IHVuc2lnbmVkIGJ5dGUgcGF5bG9hZFR5cGU7DQo+ICAgRE9NU3RyaW5nIG5hbWU7DQo+ICAgdW5z aWduZWQgaW50PyBjbG9ja1JhdGU7DQo+ICAgdW5zaWduZWQgaW50PyBiaXRSYXRlOw0KPiAgIC8v IEEgZ3JhYiBiYWcgb2Ygb3RoZXIgZm10cCB0aGF0IHdpbGwgbmVlZCB0byBiZSBmdXJ0aGVyIGRl ZmluZWQuDQo+ICAgTWVkaWFDb2RlY1BhcmFtW10gcGFyYW1zOw0KPiB9DQo+DQo+IGRpY3Rpb25h cnkgTWVkaWFDb2RlY1BhcmFtIHsNCj4gICBET01TdHJpbmcga2V5Ow0KPiAgIERPTVN0cmluZyB2 YWx1ZTsNCj4gfQ0KPg0KPg0KPiBOb3RlczoNCj4NCj4gLSBXaGVuIExvY2FsTWVkaWFTdHJlYW1z IGFyZSBhZGRlZCB1c2luZyBhZGRTdHJlYW0sIG9ubmVnb3RpYXRlZG5lZWRlZCBpcw0KPiBub3Qg Y2FsbGVkLCBhbmQgdGhvc2Ugc3RyZWFtcyBhcmUgbmV2ZXIgcmVmbGVjdGVkIGluIGZ1dHVyZSBT RFAgZXhjaGFuZ2VzLg0KPiBJbmRlZWQsIGl0IHdvdWxkIGJlIGltcG9zc2libGUgdG8gcHV0IHRo ZW0gaW4gdGhlIFNEUCB3aXRob3V0IGZpcnN0DQo+IHJlc29sdmluZyBpZiB0aGF0IHdvdWxkIGJl IFBsYW4gQSBTRFAgb3IgUGxhbiBCIFNEUC4NCj4NCj4gLSBKdXN0IGxpa2UgcGlsZXMgb2YgYXR0 cmlidXRlcyB3b3VsZCBuZWVkIHRvIGJlIGRlZmluZWQgZm9yIFBsYW4gQSBhbmQgZm9yDQo+IFBs YW4gQiwgc2ltaWxhciBhdHRyaWJ1dGVzIHdvdWxkIG5lZWQgdG8gYmUgZGVmaW5lZCBoZXJlIChM dWNraWx5LCAgbXVjaA0KPiB3b3JrIGhhcyBhbHJlYWR5IGJlZW4gZG9uZSBmaWd1cmluZyBvdXQg d2hhdCB0aG9zZSBwYXJhbWV0ZXJzIGFyZSA6KS4NCj4NCj4NCj4gUHJvczoNCj4NCj4gLSBFaXRo ZXIgUGxhbiBBIG9yIFBsYW4gQiBvciBjb3VsZCBiZSBpbXBsZW1lbnRlZCBpbiBKYXZhc2NyaXB0 IHVzaW5nIHRoaXMNCj4gQVBJDQo+IC0gSXQgZXhwb3NlcyBhbGwgdGhlIHNhbWUgZnVuY3Rpb25h bGl0eSB0byB0aGUgSmF2YXNjcmlwdCBhcyBTRFAsIGJ1dCBpbiBhDQo+IG11Y2ggbmljZXIgZm9y bWF0IHRoYXQgaXMgbXVjaCBlYXNpZXIgdG8gd29yayB3aXRoLg0KPiAtIEFueSBvdGhlciBzaWdu YWxsaW5nIG1lY2hhbmlzbSwgc3VjaCBhcyBKaW5nbGUgb3IgQ0xVRSBjb3VsZCBiZQ0KPiBpbXBs ZW1lbnRlZCB1c2luZyB0aGlzIEFQSS4NCj4gLSBUaGVyZSBpcyBhbG1vc3Qgbm8gcmlzayBvZiBz aWduYWxsaW5nIGdsYXJlLg0KPiAtIERlYnVnZ2luZyBlcnJvcnMgd2l0aCBtaXNjb25maWd1cmVk IGRlc2NyaXB0aW9ucyBzaG91bGQgYmUgbXVjaCBlYXNpZXINCj4gd2l0aCB0aGlzIHRoYW4gd2l0 aCBsYXJnZSBTRFAgYmxvYnMuDQo+DQo+DQo+IENvbnM6DQo+DQo+IC0gTm93IHRoZXJlIGFyZSB0 d28gc2xpZ2h0bHkgZGlmZmVyZW50IHdheXMgdG8gYWRkIHN0cmVhbXM6IGJ5IGNyZWF0aW5nIGEN Cj4gTG9jYWxNZWRpYVN0cmVhbSBmaXJzdCwgYW5kIG5vdC4gIFRoaXMgaXMsIGhvd2V2ZXIsIGFu YWxvZ291cyB0byBzZXR0aW5nDQo+ICJuZWdvdGlhdGVkOiB0cnVlIiBpbiBjcmVhdGVEYXRhQ2hh bm5lbC4gIE9uIHdheSBpcyAiSnVzdCBXb3JrIiwgYW5kIHRoZQ0KPiBvdGhlciBpcyBtb3JlIGFk dmFuY2VkIGNvbnRyb2wuDQo+DQo+IC0gQWxsIHRoZSBvcHRpb25zIGluIE1lZGlhQ29kZWNEZXNj cmlwdGlvbiBhcmUgYSBiaXQgY29tcGxpY2F0ZWQuICBSZWFsbHksDQo+IHRoaXMgaXMgb25seSBu ZWNlc3NhcnkgYmVjYXVzZSBQbGFuIEEgcmVxdWlyZXMgYmVpbmcgYWJsZSB0byBzcGVjaWZ5IGNv ZGVjDQo+IHBhcmFtZXRlcnMgcGVyIFNTUkMsIGFuZCBzZXQgZWFjaCBmbG93IG9uIGRpZmZlcmVu dCB0cmFuc3BvcnRzLiAgSWYgd2UgZGlkDQo+IG5vdCBoYXZlIHRoaXMgcmVxdWlyZW1lbnQsIHdl IGNvdWxkIHNpbXBsaWZ5Lg0KPg0KPg0KPiBFeGFtcGxlIFVzYWdlOg0KPg0KPiAvLyBJbWFnaW5l IEkgaGF2ZSBNeUFwcCwgaGFuZGxlcyBjcmVhdGluZyBhIFBlZXJDb25uZWN0aW9uLA0KPiAvLyBz aWduYWxsaW5nLCBhbmQgcmVuZGVyaW5nIHN0cmVhbXMuICBUaGlzIGlzIGhvdyB0aGUgbmV3IEFQ SSBjb3VsZCBiZQ0KPiAvLyB1c2VkLg0KPiB2YXIgcGVlckNvbm5lY3Rpb24gPSBNeUFwcC5jcmVh dGVQZWVyQ29ubmVjdGlvbigpOw0KPg0KPiAvLyBPbiBzZW5kZXIgc2lkZToNCj4gdmFyIHN0cmVh bSA9IE15QXBwLmdldE1lZGlhU3RyZWFtKCk7DQo+IHZhciBsb2NhbFN0cmVhbSA9IHBlZXJDb25u ZWN0aW9uLmNyZWF0ZVNlbmRTdHJlYW0oc3RyZWFtKTsNCj4gc2VuZFN0cmVhbS5kZXNjcmlwdGlv biA9IE15QXBwLm1vZGlmeVN0cmVhbShsb2NhbFN0cmVhbS5kZXNjcmlwdGlvbikNCj4gTXlBcHAu c2lnbmFsQWRkU3RyZWFtKGxvY2FsU3RyZWFtLmRlc2NyaXB0aW9uLCBmdW5jdGlvbihyZXNwb25z ZSkpIHsNCj4gICBpZiAoIXJlc3BvbnNlLnJlamVjdGVkKSB7DQo+ICAgICAvLyBNZWRpYSB3aWxs IG5vdCBiZSBzZW50Lg0KPiAgICAgcGVlckNvbm5lY3Rpb24uYWRkU3RyZWFtKGxvY2FsU3RyZWFt KTsNCj4gICB9DQo+IH0NCj4NCj4gLy8gT24gcmVjZWl2ZXIgc2lkZToNCj4gTXlBcHAub25BZGRT dHJlYW1TaWduYWxsZWQgPSBmdW5jdGlvbihzdHJlYW1EZXNjcmlwdGlvbikgew0KPiAgIHZhciBz dHJlYW0gPSBwZWVyQ29ubmVjdGlvbi5jcmVhdGVSZWNlaXZlU3RyZWFtKHN0cmVhbURlc2NyaXB0 aW9uKTsNCj4gICBNeUFwcC5yZW5kZXJTdHJlYW0oc3RyZWFtKTsNCj4gfQ0KPg0KPg0KPiAvLyBJ biB0aGlzIGV4Y2hhbmdlLCB0aGUgTWVkaWFTdHJlYW1EZXNjcmlwdGlvbiBzaWduYWxsZWQgZnJv bSB0aGUNCj4gLy8gc2VuZGVyIHRvIHRoZSByZWNlaXZlciBtYXkgaGF2ZSBsb29rZWQgc29tZXRo aW5nIGxpa2UgdGhpczoNCj4NCj4gew0KPiAgIHRyYWNrczogWw0KPiAgIHsNCj4gICAgIGlkOiAi YXVkaW8xIiwNCj4gICAgIGtpbmQ6ICJhdWRpbyIsDQo+ICAgICBmbG93czogWw0KPiAgICAgew0K PiAgICAgICBpZDogIm1haW4iLA0KPiAgICAgICB0cmFuc3BvcnRJZDogInRyYW5zcG9ydDEiLA0K PiAgICAgICBzc3JjOiAxMTExLA0KPiAgICAgICBjb2RlY3M6IFsNCj4gICAgICAgew0KPiAgICAg ICAgIHBheWxvYWRUeXBlOiAxMTEsDQo+ICAgICAgICAgbmFtZTogIm9wdXMiLA0KPiAgICAgICAg IC8vIC4uLiBtb3JlIGNvZGVjIGRldGFpbHMNCj4gICAgICAgfSwNCj4gICAgICAgew0KPiAgICAg ICAgIHBheWxvYWRUeXBlOiAxMTIsDQo+ICAgICAgICAgbmFtZTogInBjbXUiLA0KPiAgICAgICAg IC8vIC4uLiBtb3JlIGNvZGVjIGRldGFpbHMNCj4gICAgICAgfV0NCj4gICAgfV0NCj4gIH0sDQo+ ICB7DQo+ICAgICBpZDogInZpZGVvMSIsDQo+ICAgICBraW5kOiAidmlkZW8iLA0KPiAgICAgZmxv d3M6IFsNCj4gICAgIHsNCj4gICAgICAgaWQ6ICJzaW0wIiwNCj4gICAgICAgdHJhbnNwb3J0SWQ6 ICJ0cmFuc3BvcnQyIiwNCj4gICAgICAgc3NyYzogMjIyMiwNCj4gICAgICAgY29kZWNzOiBbDQo+ ICAgICAgIHsNCj4gICAgICAgICBwYXlsb2FkVHlwZTogMTIyLA0KPiAgICAgICAgIG5hbWU6ICJ2 cDgiDQo+ICAgICAgICAgLy8gLi4uIG1vcmUgY29kZWMgZGV0YWlscw0KPiAgICAgICB9XQ0KPiAg ICB9LA0KPiAgICB7DQo+ICAgICAgaWQ6ICJzaW0xIiwNCj4gICAgICB0cmFuc3BvcnRJZDogInRy YW5zcG9ydDIiLA0KPiAgICAgIHNzcmM6IDIyMjMsDQo+ICAgICAgY29kZWNzOiBbDQo+ICAgICAg ew0KPiAgICAgICAgcGF5bG9hZFR5cGU6IDEyMiwNCj4gICAgICAgIG5hbWU6ICJ2cDgiLA0KPiAg ICAgICAgLy8gLi4uIG1vcmUgY29kZWMgZGV0YWlscw0KPiAgICAgIH1dDQo+ICAgIH0sDQo+ICAg IHsNCj4gICAgICBpZDogInNpbTIiLA0KPiAgICAgIHRyYW5zcG9ydElkOiAidHJhbnNwb3J0MiIs DQo+ICAgICAgc3NyYzogMjIyNCwNCj4gICAgICBjb2RlY3M6IFsNCj4gICAgICB7DQo+ICAgICAg ICBwYXlsb2FkVHlwZTogMTIyLA0KPiAgICAgICAgbmFtZTogInZwOCIsDQo+ICAgICAgICAvLyAu Li4gbW9yZSBjb2RlYyBkZXRhaWxzDQo+ICAgICAgfV0NCj4gICAgfSwNCj4NCj4gICAgew0KPiAg ICAgIGlkOiAic2ltMGZlYyIsDQo+ICAgICAgdHJhbnNwb3J0SWQ6ICJ0cmFuc3BvcnQyIiwNCj4g ICAgICBzc3JjOiAyMjI1LA0KPiAgICAgIGNvZGVjczogWw0KPiAgICAgIHsNCj4gICAgICAgIHBh eWxvYWRUeXBlOiAxMjIsDQo+ICAgICAgICBuYW1lOiAidnA4IiwNCj4gICAgICAgIC8vIC4uLg0K PiAgICAgIH1dDQo+ICAgIH1dLA0KPiAgICBmbG93R3JvdXBzOiBbDQo+ICAgIHsNCj4gICAgICBz ZW1hbnRpY3M6ICJTSU0iLA0KPiAgICAgIHNzcmNzOiBbMjIyMiwgMjIyMywgMjIyNF0NCj4gICAg fSwNCj4gICAgew0KPiAgICAgIHNlbWFudGljczogIkZFQyIsDQo+ICAgICAgc3NyY3M6IFsyMjIy LCAyMjI1XQ0KPiAgICB9XQ0KPiAgfV0NCj4gfQ0KPg0KPg0KPiBDb25zdHJ1Y3RpdmUgZmVlZGJh Y2sgaXMgd2VsY29tZSA6KS4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmc8 bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGN3ZWINCj4NCg0K --_000_57A15FAF9E58F841B2B1651FFE16D28104FB3EGENSJZMBX01msgint_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAy IDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFy Z2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTU0NDgzMjY2 MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTE2NjI5 MDcxOCA0NzQ5NjcyMiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLXN0YXJ0LWF0OjE2Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMi41cHQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QZXRlciw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRl bnQ6NC41cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Zb3Ug c2F5IHRoYXQgb25seSBpbml0aWFsIFBlZXJDb25uZWN0aW9uIHNldCB1cCByZXF1aXJlcyBvZmZl ciBhbnN3ZXIuICZuYnNwOyZuYnNwO1doZXJlIGlzIHRoYXQgaW4geW91ciBleGFtcGxlPyZuYnNw OyBJbiB0aGUgZXhhbXBsZSwgYWxsIHdlIHNlZQ0KIG9uIHRoZSByZWNlaXZpbmcgc2lkZSBpcyB0 aGF0IGl0IGNhbGxzIGNyZWF0ZVJlY2VpdmVTdHJlYW0uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjQuNXB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMi41 cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmltDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBldGVyIFRoYXRjaGVyPGJyPg0KPGI+U2VudDo8L2I+ IE1vbmRheSwgSnVuZSAxNywgMjAxMyAzOjI2IFBNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gVGhv bXNvbjxicj4NCjxiPkNjOjwvYj4gJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFByb3Bvc2FsIGZvciBhIEpTIEFQSSBmb3IgTm9QbGFuIChh ZGRpbmcgbXVsdGlwbGUgc291cmNlcyB3aXRob3V0IGVuY29kaW5nIHRoZW0gaW4gU0RQKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBJIHdhcyBleHBl Y3RpbmcgeW91IHRvIGJlIG1vcmUgc3VwcG9ydGl2ZS4gJm5ic3A7SSdtIHN1cnByaXNlZCBvdXQg aG93IHlvdXIgd2FudCAmcXVvdDthbGwgb3Igbm90aGluZyZxdW90Oy4gJm5ic3A7SSdtIGFmcmFp ZCBpZiBvdXIgb3B0aW9ucyBmb3IgYSBjbGVhbiBBUEkgYXJlIGFsbCBvciBub3RoaW5nLCB3ZSds bCBqdXN0IGVuZCB1cCB3aXRoIG5vdGhpbmcuICZuYnNwO0knZCBwcmVmZXIgdG8gdHJ5IGluY3Jl bWVudGFsIGltcHJvdmVtZW50cw0KIHRvIHdvcmQgdG93YXJkIChldmVudHVhbGx5KSBhIGNsZWFu IEFQSS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkRvIHlvdSB0aGluayBpdCBpcyBpbXBvc3NpYmxlIHRvIHdvcmsgdG93YXJkIGEgY2xlYW4gQVBJ IGluIGFuIGluY3JlbWVudGFsIGFwcHJvYWNoPyAmbmJzcDtJZiB5b3UgdGhpbmsgaXQncyBwb3Nz aWJsZSwgSSdkIGxpa2UgdG8gaGVhciB5b3VyIHRob3VnaHRzIG9uIGhvdy4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnkgdGhlIHdheSwgdGhl c2UgQVBJIGFkZGl0aW9ucyB3b3VsZCBncmVhdGx5IG1pbmltaXplIHRoZSBhbW91bnQgb2YgU0RQ IGVkaXRpbmcgbmVjZXNzYXJ5IGZvciBKUyBjbGllbnRzIHRoYXQgZG9uJ3QgdXNlIFNEUCBmb3Ig c2lnbmFsbGluZy4gJm5ic3A7QW5kIGxhdGVyIGluY3JlbWVudGFsIGltcHJvdmVtZW50cyBjb3Vs ZCByZWR1Y2UgaXQgZnVydGhlci4gJm5ic3A7QWxzbywgaXQncyBubyBsb25nZXIgbmVjZXNzYXJ5 IHRvDQogZG8gb2ZmZXIvYW5zd2VyIGZvciBhZGRpbmcgdHJhY2tzLiAmbmJzcDtJdCdzIG9ubHkg dGhlIGludGlhbCBQZWVyQ29ubmVjdGlvbiBzZXR1cCB0aGF0IG5lZWRzIHRvIGRvIE9mZmVyL0Fu c3dlci4gJm5ic3A7U28sIGl0IGRvZXNuJ3QgaW5oZXJpdCBhbGwgdGhlIHByb2JsZW1zIHF1aXRl IGFzIG11Y2ggYXMgeW91IGRlc2NyaWJlZC4gJm5ic3A7SXQgbWF5IGJlIHNsaWdodGx5IGFib21p bmFibGUsIGJ1dCBJIGNlcnRhaW5seSBjb25zaWRlciBpdCBsZXNzIGFib21pbmFibGUNCiB0aGFu IHRoZSBTRFAgZWRpdGluZyBuZWNlc3Nhcnkgd2l0aG91dCBpdC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBNb24sIEp1biAxNywgMjAxMyBhdCAxMTo1NyBBTSwgTWFydGluIFRob21zb24g Jmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1heWJlIHlvdSdkIGV4cGVjdCBtZSB0byBiZSBtb3Jl IHN1cHBvcnRpdmUgb2Ygc29tZXRoaW5nIHRoYXQgbG9va2VkPGJyPg0Kc28gbXVjaCBsaWtlIENV LVJUQy1XZWIuICZuYnNwO0l0IGluaGVyaXRzIGFsbCB0aGUgd29yc3QgcHJvcGVydGllcyBvZiBK U0VQPGJyPg0KKE9mZmVyL0Fuc3dlciwgU0RQIGVkaXRpbmcpIHdpdGggYSBwYXJ0aWFsIGltcGxl bWVudGF0aW9uIG9mIGEgY2xlYW48YnI+DQpBUEkuPGJyPg0KPGJyPg0KSXQncyBjb21tZW50IDIy LWxpdGUuICZuYnNwO0l0J3MgYW4gYWJvbWluYXRpb24uICZuYnNwO0lmIHlvdSBhcmUgZ29pbmcg dG8gZG88YnI+DQp0aGlzLCBkbyBpdCBwcm9wZXJseS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KT24gMTcgSnVuZSAyMDEzIDA1OjU3LCBQ ZXRlciBUaGF0Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tIiB0 YXJnZXQ9Il9ibGFuayI+cHRoYXRjaGVyQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQom Z3Q7IEdvb2dsZSBpcyBpbiBmdWxsIHN1cHBvcnQgb2YgJnF1b3Q7UGxhbiBCJnF1b3Q7IGZvciBl bmNvZGluZyBtdWx0aXBsZSBtZWRpYSBzb3VyY2VzIGluPGJyPg0KJmd0OyBTRFAsIGFuZCB3b3Vs ZCBsaWtlIHRvIHNlZSB0aGUgUGxhbiBBIHZzLiBQbGFuIEIgZGVjaXNpb24gcmVzb2x2ZWQgc29v bi48YnI+DQomZ3Q7IFJlY2VudGx5LCB0aG91Z2gsIGEgdGhpcmQgb3B0aW9uLCBjYWxsZWQgJnF1 b3Q7Tm9QbGFuJnF1b3Q7IGhhcyBiZWVuIHByb3Bvc2VkLCBidXQgaXQ8YnI+DQomZ3Q7IGxhY2tl ZCB0aGUgZGV0YWlscyBvZiB3aGF0IGEgSlMgQVBJIHdvdWxkIGxvb2sgbGlrZSBmb3IgTm9QbGFu LiAmbmJzcDtDdWxsZW48YnI+DQomZ3Q7IGFza2VkIHRvIHNlZSBzdWNoIGFuIEFQSSBwcm9wb3Nh bCwgYW5kIHNvIEkgaGF2ZSB3b3JrZWQgd2l0aCBFbWlsIHRvIG1ha2U8YnI+DQomZ3Q7IG9uZS4g Jm5ic3A7SGUgd2lsbCBiZSBhZGRpbmcgaXQgdG8gdGhlIE5vUGxhbiBkcmFmdCwgYnV0IEkgd2ls bCBhbHNvIGluY2x1ZGUgaXQ8YnI+DQomZ3Q7IGluIHRoaXMgZW1haWwuPGJyPg0KJmd0Ozxicj4N CiZndDsgQWdhaW4sIEdvb2dsZSBpcyBpbiBmdWxsIHN1cHBvcnQgb2YgJnF1b3Q7UGxhbiBCJnF1 b3Q7LiAmbmJzcDtCdXQgaWYgUGxhbiBBIHZzLiBQbGFuIEI8YnI+DQomZ3Q7IGNhbm5vdCBiZSBk ZWNpZGVkLCB0aGVuIHdlIHN1cHBvcnQgTm9QbGFuIHdpdGggdGhlIGZvbGxvd2luZyBhZGRpdGlv bnMgdG88YnI+DQomZ3Q7IHRoZSBXZWJSVEMgSlMgQVBJIGFzIGFuIG9wdGlvbiB0aGF0IGFsbG93 cyBpbXBsZW1lbnRpbmcgZWl0aGVyIFBsYW4gQSBvcjxicj4NCiZndDsgUGxhbiBCICZuYnNwO2lu IEphdmFzY3JpcHQuICZuYnNwO0FuZCBldmVuIGlmIFBsYW4gQSB2cy4gUGxhbiBCIGlzIHJlc29s dmVkLCB0aGVzZSBBUEk8YnI+DQomZ3Q7IGFkZGl0aW9ucyB3b3VsZCBzdGlsbCBiZSBhIGJpZyBp bXByb3ZlbWVudCBmb3IgdGhvc2UgV2ViUlRDIGFwcGxpY2F0aW9uczxicj4NCiZndDsgdGhhdCBk b24ndCB1c2UgU0RQIGZvciBzaWduYWxsaW5nLjxicj4NCiZndDs8YnI+DQomZ3Q7IEl0IGlzIGEg Yml0IGxvbmcgYmVjYXVzZSBJIGhhdmUgYWRkZWQgbWFueSBjb21tZW50cyBhbmQgZXhhbXBsZXMs IGJ1dCB0aGU8YnI+DQomZ3Q7IGFjdHVhbGx5IGFkZGl0aW9ucyBvbmx5IGluY2x1ZGUgdHdvIG5l dyBtZXRob2RzIG9uIFBlZXJDb25uZWN0aW9uIGFuZCBhIGZldzxicj4NCiZndDsgbmV3IGRpY3Rp b25hcmllcy4gJm5ic3A7U28gZG9uJ3QgYmUgb3ZlcndoZWxtZWQgOikuPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbnRybzogVGhpcyBmb2xsb3dzIHRoZSBtb2RlbCBv ZiBjcmVhdGVEYXRhQ2hhbm5lbCwgd2hpY2ggaGFzIGEgSlMgbWV0aG9kIG9uPGJyPg0KJmd0OyBQ ZWVyQ29ubmVjdGlvbiB0aGF0IG1ha2VzIGl0IHBvc3NpYmxlIHRvIGFkZCBkYXRhIGNoYW5uZWxz IHdpdGhvdXQgZ29pbmc8YnI+DQomZ3Q7IHRocm91Z2ggU0RQLiAmbmJzcDtGdXJ0aGVybW9yZSwg anVzdCBsaWtlIGNyZWF0ZURhdGFDaGFubmVsIGFsbG93cyAyIHdheXMgdG88YnI+DQomZ3Q7IGhh bmRsZSBuZW9naXRhdGlvbiAodGhlICZxdW90O0kga25vdyB3aGF0IEknbSBkb2luZzsgJm5ic3A7 SGVyZSdzIHdoYXQgSSB3YW50IHRvIHNlbmQ7PGJyPg0KJmd0OyBMZXQgbWUgc2lnbmFsIGV2ZXJ5 dGhpbmcmcXVvdDsgbW9kZSBhbmQgdGhlICZxdW90O3BsZWFzZSB0YWtlIGNhcmUgb2YgaXQgZm9y IG1lOyAmbmJzcDtzZW5kPGJyPg0KJmd0OyBhbiBPUEVOIG1lc3NhZ2UmcXVvdDsgbW9kZSksIHRo aXMgYWxzbyBoYXMgMiB3YXlzIHRvIGhhbmRsZSBuZWdvdGlhdGlvbiAodGhlICZxdW90O0k8YnI+ DQomZ3Q7IGtub3cgd2hhdCBJJ20gZG9pbmc7IEhlcmUncyB3aGF0IEkgd2FudCB0byBzZW5kOyBM ZXQgbWUgc2lnbmFsIGV2ZXJ5dGhpbmcmcXVvdDs8YnI+DQomZ3Q7IG1vZGUgYW5kIHRoZSAmcXVv dDtwbGVhc2UgdGFrZSBjYXJlIG9mIGl0IGZvciBtZTsgJm5ic3A7c2VuZCBTRFAgYmFjayBhbmQg Zm9ydGgmcXVvdDs8YnI+DQomZ3Q7IG1vZGUpLjxicj4NCiZndDs8YnI+DQomZ3Q7IEZvbGxvd2lu ZyB0aGUgc3VjY2VzcyBvZiBjcmVhdGVEYXRhQ2hhbm5lbCwgdGhpcyBhbGxvd3Mgc2ltcGxlIGFw cGxpY2F0aW9uczxicj4NCiZndDsgdG8gSnVzdCBXb3JrIGFuZCBtb3JlIGFkdmFuY2VkIGFwcGxp Y2F0aW9ucyB0byBlYXNpbHkgY29udHJvbCB3aGF0IHRoZXkgbmVlZDxicj4NCiZndDsgdG8uICZu YnNwO0luIHBhcnRpY3VsYXIsIGl0J3MgcG9zc2libGUgdG8gdXNlIHRoaXMgQVBJIHRvIGltcGxl bWVudCBlaXRoZXIgUGxhbiBBPGJyPg0KJmd0OyBvciBQbGFuIEIuPGJyPg0KJmd0Ozxicj4NCiZn dDsgLy8gVGhlIGZvbGxvd2luZyB0d28gbWV0aG9kIGFyZSBhZGRlZCB0byBSVENQZWVyQ29ubmVj dGlvbjxicj4NCiZndDsgcGFydGlhbCBpbnRlcmZhY2UgUlRDUGVlckNvbm5lY3Rpb24gezxicj4N CiZndDsgJm5ic3A7Ly8gQ3JlYXRlIGEgc3RyZWFtIHRoYXQgaXMgdXNlZCB0byBzZW5kIGEgc291 cmNlIHN0cmVhbS48YnI+DQomZ3Q7ICZuYnNwOy8vIFRoZSBNZWRpYVNlbmRTdHJlYW0uZGVzY3Jp cHRpb24gY2FuIGJlIHVzZWQgZm9yIHNpZ25hbGxpbmcuPGJyPg0KJmd0OyAmbmJzcDsvLyBObyBt ZWRpYSBpcyBzZW50IHVudGlsIGFkZFN0cmVhbShNZWRpYVNlbmRTdHJlYW0pIGlzIGNhbGxlZC48 YnI+DQomZ3Q7ICZuYnNwO0xvY2FsTWVkaWFTdHJlYW0gY3JlYXRlTG9jYWxTdHJlYW0oTWVkaWFT dHJlYW0gc291cmNlU3RyZWFtKTs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsvLyBDcmVhdGUg YSBzdHJlYW0gdGhhdCBpcyB1c2VkIHRvIHJlY2VpdmUgbWVkaWEgZnJvbSB0aGUgcmVtb3RlIHNp ZGUsPGJyPg0KJmd0OyAmbmJzcDsvLyBnaXZlbiB0aGUgcGFyYW1ldGVycyBzaWduYWxsZWQgZnJv bSBNZWRhaVNlbmRTdHJlYW0uZGVzY3JpcHRpb24uPGJyPg0KJmd0OyAmbmJzcDtNZWRpYVN0cmVh bSBjcmVhdGVSZW1vdGVTdHJlYW0oTWVkaWFTdHJlYW1EZXNjcmlwdGlvbiBkZXNjcmlwdGlvbik7 PGJyPg0KJmd0OyB9PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IGludGVyZmFjZSBMb2Nh bE1lZGlhU3RyZWFtIGltcGxlbWVudHMgTWVkaWFTdHJlYW0gezxicj4NCiZndDsgJm5ic3A7IC8v IFRoaXMgY2FuIGJlIGNoYW5nZWQgYXQgYW55IHRpbWUsIGJ1dCBlc3BlY2lhbGx5IGJlZm9yZSBj YWxsaW5nPGJyPg0KJmd0OyAmbmJzcDsgLy8gUGVlckNvbm5lY3Rpb24uYWRkU3RyZWFtPGJyPg0K Jmd0OyAmbmJzcDsgYXR0cmlidXRlIE1lZGlhU3RyZWFtRGVzY3JpcHRpb24gZGVzY3JpcHRpb247 PGJyPg0KJmd0OyB9PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IC8vIFJlcHJlc2VudHMg dGhlIHBhcmFtZXRlcnMgdXNlZCB0byBlaXRoZXIgc2VuZCBvciByZWNlaXZlIGEgc3RyZWFtPGJy Pg0KJmd0OyAvLyBvdmVyIGEgUGVlckNvbm5lY3Rpb24uPGJyPg0KJmd0OyBkaWN0aW9uYXJ5IE1l ZGlhU3RyZWFtRGVzY3JpcHRpb24gezxicj4NCiZndDsgJm5ic3A7IE1lZGlhU3RyZWFtVHJhY2tE ZXNjcmlwdGlvbltdIHRyYWNrczs8YnI+DQomZ3Q7IH08YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgLy8gUmVwcmVzZW50cyB0aGUgcGFyYW1ldGVycyB1c2VkIHRvIGVpdGhlciBzZW5kIG9y IHJlY2VpdmUgYSB0cmFjayBvdmVyIC8vPGJyPg0KJmd0OyBhIFBlZXJDb25uZWN0aW9uLiAmbmJz cDtBIHRyYWNrIGhhcyBtYW55ICZxdW90O2Zsb3dzJnF1b3Q7LCB3aGljaCBjYW4gYmUgZ3JvdXBl ZDxicj4NCiZndDsgLy8gdG9nZXRoZXIuPGJyPg0KJmd0OyBkaWN0aW9uYXJ5IE1lZGlhU3RyZWFt VHJhY2tEZXNjcmlwdGlvbiB7PGJyPg0KJmd0OyAmbmJzcDsgLy8gU2FtZSBhcyB0aGUgTWVkaWFT dHJlYW1UcmFjay5pZDxicj4NCiZndDsgJm5ic3A7IERPTVN0cmluZyBpZDs8YnI+DQomZ3Q7PGJy Pg0KJmd0OyAmbmJzcDsgLy8gU2FtZSBhcyB0aGUgTWVkaWFTdHJlYW1UcmFjay5raW5kPGJyPg0K Jmd0OyAmbmJzcDsgRE9NU3RyaW5nIGtpbmQ7PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7IC8v IEEgdHJhY2sgY2FuIGhhdmUgbWFueSAmcXVvdDtmbG93cyZxdW90Oywgc3VjaCBhcyBmb3IgU2lt dWxjYXN0LCBGRUMsIGV0Yy48YnI+DQomZ3Q7ICZuYnNwOyAvLyBBbmQgdGhleSBjYW4gYmUgZ3Jv dXBlZCBpbiBhcmJpdHJhcnkgd2F5cy48YnI+DQomZ3Q7ICZuYnNwOyBNZWRpYUZsb3dEZXNjcmlw dGlvbltdIGZsb3dzOzxicj4NCiZndDsgJm5ic3A7IE1lZGlhRmxvd0dyb3VwW10gZmxvd0dyb3Vw czs8YnI+DQomZ3Q7IH08YnI+DQomZ3Q7PGJyPg0KJmd0OyAvLyBSZXByZXNlbnRzIHRoZSBwYXJh bWV0ZXJzIHVzZWQgdG8gZWl0aGVyIHNlbmQgb3IgcmVjZWl2ZSBhICZxdW90O2Zsb3cmcXVvdDs8 YnI+DQomZ3Q7IC8vIG92ZXIgYSBQZWVyQ29ubmVjdGlvbi4gJm5ic3A7QSAmcXVvdDtmbG93JnF1 b3Q7IGlzIGEgbWVkaWEgdGhhdCBhcnJpdmVzIHdpdGggYTxicj4NCiZndDsgLy8gc2luZ2xlLCB1 bmlxdWUgU1NSQy4gJm5ic3A7T25lIHRvIG1hbnkgZmxvd3MgdG9nZXRoZXIgbWFrZSB1cCB0aGUg bWVkaWE8YnI+DQomZ3Q7IC8vIGZvciBhIHRyYWNrLiAmbmJzcDtGb3IgZXhhbXBsZSwgdGhlcmUg bWF5IGJlIFNpbXVsY2FzdCwgRkVDLCBhbmQgUlRYPGJyPg0KJmd0OyAvLyBmbG93cy48YnI+DQom Z3Q7IGRpY3Rpb25heSBNZWRpYUZsb3dEZXNjcmlwdGlvbiB7PGJyPg0KJmd0OyAmbmJzcDsgLy8g VGhlICZxdW90O2Zsb3cgaWQmcXVvdDsgbXVzdCBiZSB1bmlxdWUgdG8gdGhlIHRyYWNrLCBidXQg bmVlZCBub3QgYmUgdW5pcXVlPGJyPg0KJmd0OyAmbmJzcDsgLy8gb3V0c2lkZSBvZiB0aGUgdHJh Y2sgKHR3byB0cmFja3MgY291bGQgYm90aCBoYXZlIGEgZmxvdyB3aXRoIHRoZTxicj4NCiZndDsg Jm5ic3A7IC8vIHNhbWUgZmxvdyBJRCkuPGJyPg0KJmd0OyAmbmJzcDsgRE9NU3RyaW5nIGlkOzxi cj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAvLyBFYWNoIGZsb3cgY2FuIGdvIG92ZXIgaXRzIG93 biB0cmFuc3BvcnQuICZuYnNwO0lmIHRoZSBKUyBzZXRzIHRoaXMgdG8gYTxicj4NCiZndDsgJm5i c3A7IC8vIHRyYW5zcG9ydElkIHRoYXQgZG9lc24ndCBoYXZlIGEgdHJhbnNwb3J0IHNldHVwIGFs cmVhZHksIHRoZTxicj4NCiZndDsgJm5ic3A7IC8vIGJyb3dzZXIgd2lsbCB1c2UgU0RQIG5lZ290 aWF0aW9uIHRvIHNldHVwIGEgdHJhbnNwb3J0IHRvIGJhY2sgdGhhdDxicj4NCiZndDsgJm5ic3A7 IC8vIHRyYW5zcG9ydElkLiAmbmJzcDtJZiBUaGlzIGlzIHNldCB0byBhbiBNSUQgaW4gdGhlIFNE UCwgdGhlbiB0aGF0IE1JRCdzPGJyPg0KJmd0OyAmbmJzcDsgLy8gdHJhbnNwb3J0IGlzIHVzZWQu PGJyPg0KJmd0OyAmbmJzcDsgRE9NU3RyaW5nIHRyYW5zcG9ydElkOzxicj4NCiZndDs8YnI+DQom Z3Q7ICZuYnNwOyAvLyBUaGUgU1NSQyB1c2VkIHRvIHNlbmQgdGhlIGZsb3cuPGJyPg0KJmd0OyAm bmJzcDsgdW5zaWduZWQgaW50IHNzcmM7PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7IC8vIFdo ZW4gdXNlZCBhcyByZWNlaXZlIHBhcmFtZXRlcnMsIHRoaXMgaW5kaWNhdGVzIHRoZSBwb3NzaWJs ZSBsaXN0PGJyPg0KJmd0OyAmbmJzcDsgLy8gb2YgY29kZWNzIHRoYXQgbWlnaHQgY29tZSBpbiBm b3IgdGhpcyBmbG93LiAmbmJzcDtGb3IgZXhtYW1wbGUsIGEgZ2l2ZW48YnI+DQomZ3Q7ICZuYnNw OyAvLyByZWNlaXZlIGZsb3cgY291bGQgYmUgc2V0dXAgdG8gcmVjZWl2ZSBhbnkgb2YgT1BVUywg SVNBQywgb3IgUENNVS48YnI+DQomZ3Q7ICZuYnNwOyAvLyBXaGVuIHVzZWQgYXMgc2VuZCBwYXJh bWV0ZXJzLCB0aGlzIGluZGljYXRlcyB0aGF0IHRoZSBmaXJzdCBjb2RlYzxicj4NCiZndDsgJm5i c3A7IC8vIHNob3VsZCBiZSB1c2VkLCBidXQgdGhlIGJyb3dzZXIgY2FuIHVzZSBzZW5kIG90aGVy IGNvZGVjcyBpZiBpdDxicj4NCiZndDsgJm5ic3A7IC8vIG5lZWRzIHRvIGJlY2F1c2Ugb2YgZWl0 aGVyIGJhbmR3aWR0aCBvciBDUFUgY29uc3RyYWludHMuPGJyPg0KJmd0OyAmbmJzcDsgTWVkaWFD b2RlY0Rlc2NyaXB0aW9uW10gY29kZWNzOzxicj4NCiZndDsgfTxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBkaWN0aW9uYXJ5IE1lZGlhRmxvd0dyb3VwIHs8YnI+DQomZ3Q7ICZuYnNwOyBE T01TdHJpbmcgdHlwZTsgJm5ic3A7Ly8gJnF1b3Q7U0lNJnF1b3Q7IGZvciBTaW11bGNhc3QsICZx dW90O0ZFQyZxdW90OyBmb3IgRkVDLCBldGM8YnI+DQomZ3Q7ICZuYnNwOyBET01TdHJpbmdbXSBm bG93aWRzOzxicj4NCiZndDsgfTxicj4NCiZndDs8YnI+DQomZ3Q7IGRpY3Rpb25hcnkgTWVkaWFD b2RlY0Rlc2NyaXB0aW9uIHs8YnI+DQomZ3Q7ICZuYnNwOyB1bnNpZ25lZCBieXRlIHBheWxvYWRU eXBlOzxicj4NCiZndDsgJm5ic3A7IERPTVN0cmluZyBuYW1lOzxicj4NCiZndDsgJm5ic3A7IHVu c2lnbmVkIGludD8gY2xvY2tSYXRlOzxicj4NCiZndDsgJm5ic3A7IHVuc2lnbmVkIGludD8gYml0 UmF0ZTs8YnI+DQomZ3Q7ICZuYnNwOyAvLyBBIGdyYWIgYmFnIG9mIG90aGVyIGZtdHAgdGhhdCB3 aWxsIG5lZWQgdG8gYmUgZnVydGhlciBkZWZpbmVkLjxicj4NCiZndDsgJm5ic3A7IE1lZGlhQ29k ZWNQYXJhbVtdIHBhcmFtczs8YnI+DQomZ3Q7IH08YnI+DQomZ3Q7PGJyPg0KJmd0OyBkaWN0aW9u YXJ5IE1lZGlhQ29kZWNQYXJhbSB7PGJyPg0KJmd0OyAmbmJzcDsgRE9NU3RyaW5nIGtleTs8YnI+ DQomZ3Q7ICZuYnNwOyBET01TdHJpbmcgdmFsdWU7PGJyPg0KJmd0OyB9PGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IE5vdGVzOjxicj4NCiZndDs8YnI+DQomZ3Q7IC0gV2hlbiBMb2NhbE1l ZGlhU3RyZWFtcyBhcmUgYWRkZWQgdXNpbmcgYWRkU3RyZWFtLCBvbm5lZ290aWF0ZWRuZWVkZWQg aXM8YnI+DQomZ3Q7IG5vdCBjYWxsZWQsIGFuZCB0aG9zZSBzdHJlYW1zIGFyZSBuZXZlciByZWZs ZWN0ZWQgaW4gZnV0dXJlIFNEUCBleGNoYW5nZXMuPGJyPg0KJmd0OyBJbmRlZWQsIGl0IHdvdWxk IGJlIGltcG9zc2libGUgdG8gcHV0IHRoZW0gaW4gdGhlIFNEUCB3aXRob3V0IGZpcnN0PGJyPg0K Jmd0OyByZXNvbHZpbmcgaWYgdGhhdCB3b3VsZCBiZSBQbGFuIEEgU0RQIG9yIFBsYW4gQiBTRFAu PGJyPg0KJmd0Ozxicj4NCiZndDsgLSBKdXN0IGxpa2UgcGlsZXMgb2YgYXR0cmlidXRlcyB3b3Vs ZCBuZWVkIHRvIGJlIGRlZmluZWQgZm9yIFBsYW4gQSBhbmQgZm9yPGJyPg0KJmd0OyBQbGFuIEIs IHNpbWlsYXIgYXR0cmlidXRlcyB3b3VsZCBuZWVkIHRvIGJlIGRlZmluZWQgaGVyZSAoTHVja2ls eSwgJm5ic3A7bXVjaDxicj4NCiZndDsgd29yayBoYXMgYWxyZWFkeSBiZWVuIGRvbmUgZmlndXJp bmcgb3V0IHdoYXQgdGhvc2UgcGFyYW1ldGVycyBhcmUgOikuPGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IFByb3M6PGJyPg0KJmd0Ozxicj4NCiZndDsgLSBFaXRoZXIgUGxhbiBBIG9yIFBs YW4gQiBvciBjb3VsZCBiZSBpbXBsZW1lbnRlZCBpbiBKYXZhc2NyaXB0IHVzaW5nIHRoaXM8YnI+ DQomZ3Q7IEFQSTxicj4NCiZndDsgLSBJdCBleHBvc2VzIGFsbCB0aGUgc2FtZSBmdW5jdGlvbmFs aXR5IHRvIHRoZSBKYXZhc2NyaXB0IGFzIFNEUCwgYnV0IGluIGE8YnI+DQomZ3Q7IG11Y2ggbmlj ZXIgZm9ybWF0IHRoYXQgaXMgbXVjaCBlYXNpZXIgdG8gd29yayB3aXRoLjxicj4NCiZndDsgLSBB bnkgb3RoZXIgc2lnbmFsbGluZyBtZWNoYW5pc20sIHN1Y2ggYXMgSmluZ2xlIG9yIENMVUUgY291 bGQgYmU8YnI+DQomZ3Q7IGltcGxlbWVudGVkIHVzaW5nIHRoaXMgQVBJLjxicj4NCiZndDsgLSBU aGVyZSBpcyBhbG1vc3Qgbm8gcmlzayBvZiBzaWduYWxsaW5nIGdsYXJlLjxicj4NCiZndDsgLSBE ZWJ1Z2dpbmcgZXJyb3JzIHdpdGggbWlzY29uZmlndXJlZCBkZXNjcmlwdGlvbnMgc2hvdWxkIGJl IG11Y2ggZWFzaWVyPGJyPg0KJmd0OyB3aXRoIHRoaXMgdGhhbiB3aXRoIGxhcmdlIFNEUCBibG9i cy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQ29uczo8YnI+DQomZ3Q7PGJyPg0KJmd0 OyAtIE5vdyB0aGVyZSBhcmUgdHdvIHNsaWdodGx5IGRpZmZlcmVudCB3YXlzIHRvIGFkZCBzdHJl YW1zOiBieSBjcmVhdGluZyBhPGJyPg0KJmd0OyBMb2NhbE1lZGlhU3RyZWFtIGZpcnN0LCBhbmQg bm90LiAmbmJzcDtUaGlzIGlzLCBob3dldmVyLCBhbmFsb2dvdXMgdG8gc2V0dGluZzxicj4NCiZn dDsgJnF1b3Q7bmVnb3RpYXRlZDogdHJ1ZSZxdW90OyBpbiBjcmVhdGVEYXRhQ2hhbm5lbC4gJm5i c3A7T24gd2F5IGlzICZxdW90O0p1c3QgV29yayZxdW90OywgYW5kIHRoZTxicj4NCiZndDsgb3Ro ZXIgaXMgbW9yZSBhZHZhbmNlZCBjb250cm9sLjxicj4NCiZndDs8YnI+DQomZ3Q7IC0gQWxsIHRo ZSBvcHRpb25zIGluIE1lZGlhQ29kZWNEZXNjcmlwdGlvbiBhcmUgYSBiaXQgY29tcGxpY2F0ZWQu ICZuYnNwO1JlYWxseSw8YnI+DQomZ3Q7IHRoaXMgaXMgb25seSBuZWNlc3NhcnkgYmVjYXVzZSBQ bGFuIEEgcmVxdWlyZXMgYmVpbmcgYWJsZSB0byBzcGVjaWZ5IGNvZGVjPGJyPg0KJmd0OyBwYXJh bWV0ZXJzIHBlciBTU1JDLCBhbmQgc2V0IGVhY2ggZmxvdyBvbiBkaWZmZXJlbnQgdHJhbnNwb3J0 cy4gJm5ic3A7SWYgd2UgZGlkPGJyPg0KJmd0OyBub3QgaGF2ZSB0aGlzIHJlcXVpcmVtZW50LCB3 ZSBjb3VsZCBzaW1wbGlmeS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgRXhhbXBsZSBV c2FnZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAvLyBJbWFnaW5lIEkgaGF2ZSBNeUFwcCwgaGFuZGxl cyBjcmVhdGluZyBhIFBlZXJDb25uZWN0aW9uLDxicj4NCiZndDsgLy8gc2lnbmFsbGluZywgYW5k IHJlbmRlcmluZyBzdHJlYW1zLiAmbmJzcDtUaGlzIGlzIGhvdyB0aGUgbmV3IEFQSSBjb3VsZCBi ZTxicj4NCiZndDsgLy8gdXNlZC48YnI+DQomZ3Q7IHZhciBwZWVyQ29ubmVjdGlvbiA9IE15QXBw LmNyZWF0ZVBlZXJDb25uZWN0aW9uKCk7PGJyPg0KJmd0Ozxicj4NCiZndDsgLy8gT24gc2VuZGVy IHNpZGU6PGJyPg0KJmd0OyB2YXIgc3RyZWFtID0gTXlBcHAuZ2V0TWVkaWFTdHJlYW0oKTs8YnI+ DQomZ3Q7IHZhciBsb2NhbFN0cmVhbSA9IHBlZXJDb25uZWN0aW9uLmNyZWF0ZVNlbmRTdHJlYW0o c3RyZWFtKTs8YnI+DQomZ3Q7IHNlbmRTdHJlYW0uZGVzY3JpcHRpb24gPSBNeUFwcC5tb2RpZnlT dHJlYW0obG9jYWxTdHJlYW0uZGVzY3JpcHRpb24pPGJyPg0KJmd0OyBNeUFwcC5zaWduYWxBZGRT dHJlYW0obG9jYWxTdHJlYW0uZGVzY3JpcHRpb24sIGZ1bmN0aW9uKHJlc3BvbnNlKSkgezxicj4N CiZndDsgJm5ic3A7IGlmICghcmVzcG9uc2UucmVqZWN0ZWQpIHs8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgLy8gTWVkaWEgd2lsbCBub3QgYmUgc2VudC48YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg cGVlckNvbm5lY3Rpb24uYWRkU3RyZWFtKGxvY2FsU3RyZWFtKTs8YnI+DQomZ3Q7ICZuYnNwOyB9 PGJyPg0KJmd0OyB9PGJyPg0KJmd0Ozxicj4NCiZndDsgLy8gT24gcmVjZWl2ZXIgc2lkZTo8YnI+ DQomZ3Q7IE15QXBwLm9uQWRkU3RyZWFtU2lnbmFsbGVkID0gZnVuY3Rpb24oc3RyZWFtRGVzY3Jp cHRpb24pIHs8YnI+DQomZ3Q7ICZuYnNwOyB2YXIgc3RyZWFtID0gcGVlckNvbm5lY3Rpb24uY3Jl YXRlUmVjZWl2ZVN0cmVhbShzdHJlYW1EZXNjcmlwdGlvbik7PGJyPg0KJmd0OyAmbmJzcDsgTXlB cHAucmVuZGVyU3RyZWFtKHN0cmVhbSk7PGJyPg0KJmd0OyB9PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IC8vIEluIHRoaXMgZXhjaGFuZ2UsIHRoZSBNZWRpYVN0cmVhbURlc2NyaXB0aW9u IHNpZ25hbGxlZCBmcm9tIHRoZTxicj4NCiZndDsgLy8gc2VuZGVyIHRvIHRoZSByZWNlaXZlciBt YXkgaGF2ZSBsb29rZWQgc29tZXRoaW5nIGxpa2UgdGhpczo8YnI+DQomZ3Q7PGJyPg0KJmd0OyB7 PGJyPg0KJmd0OyAmbmJzcDsgdHJhY2tzOiBbPGJyPg0KJmd0OyAmbmJzcDsgezxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyBpZDogJnF1b3Q7YXVkaW8xJnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyBraW5kOiAmcXVvdDthdWRpbyZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgZmxv d3M6IFs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgezxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgaWQ6ICZxdW90O21haW4mcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB0cmFuc3BvcnRJZDogJnF1b3Q7dHJhbnNwb3J0MSZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHNzcmM6IDExMTEsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBj b2RlY3M6IFs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHs8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwYXlsb2FkVHlwZTogMTExLDxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG5hbWU6ICZxdW90O29wdXMmcXVvdDssPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLy8gLi4uIG1vcmUgY29kZWMgZGV0YWlsczxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfSw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwYXlsb2FkVHlwZTog MTEyLDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG5hbWU6ICZxdW90O3Bj bXUmcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLy8gLi4uIG1v cmUgY29kZWMgZGV0YWlsczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfV08YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDt9XTxicj4NCiZndDsgJm5ic3A7fSw8YnI+DQomZ3Q7ICZuYnNwO3s8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgaWQ6ICZxdW90O3ZpZGVvMSZxdW90Oyw8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsga2luZDogJnF1b3Q7dmlkZW8mcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7IGZsb3dzOiBbPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHs8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IGlkOiAmcXVvdDtzaW0wJnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgdHJhbnNwb3J0SWQ6ICZxdW90O3RyYW5zcG9ydDImcXVvdDssPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzc3JjOiAyMjIyLDxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgY29kZWNzOiBbPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB7PGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcGF5bG9hZFR5cGU6IDEyMiw8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBuYW1lOiAmcXVvdDt2cDgmcXVvdDs8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvLyAuLi4gbW9yZSBjb2RlYyBkZXRh aWxzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB9XTxicj4NCiZndDsgJm5ic3A7ICZu YnNwO30sPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ezxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtpZDogJnF1b3Q7c2ltMSZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 dHJhbnNwb3J0SWQ6ICZxdW90O3RyYW5zcG9ydDImcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwO3NzcmM6IDIyMjMsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvZGVj czogWzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt7PGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtwYXlsb2FkVHlwZTogMTIyLDxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7bmFtZTogJnF1b3Q7dnA4JnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Ly8gLi4uIG1vcmUgY29kZWMgZGV0YWlsczxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt9XTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO30sPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7ezxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpZDogJnF1b3Q7c2lt MiZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHJhbnNwb3J0SWQ6ICZxdW90 O3RyYW5zcG9ydDImcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NzcmM6IDIy MjQsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvZGVjczogWzxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtw YXlsb2FkVHlwZTogMTIyLDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bmFt ZTogJnF1b3Q7dnA4JnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Ly8gLi4uIG1vcmUgY29kZWMgZGV0YWlsczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9 XTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO30sPGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZu YnNwO3s8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aWQ6ICZxdW90O3NpbTBmZWMmcXVv dDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RyYW5zcG9ydElkOiAmcXVvdDt0cmFu c3BvcnQyJnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzc3JjOiAyMjI1LDxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb2RlY3M6IFs8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ezxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGF5bG9h ZFR5cGU6IDEyMiw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO25hbWU6ICZx dW90O3ZwOCZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy8vIC4u Ljxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9XTxicj4NCiZndDsgJm5ic3A7ICZuYnNw O31dLDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2Zsb3dHcm91cHM6IFs8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDt7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NlbWFudGljczogJnF1b3Q7 U0lNJnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzc3JjczogWzIyMjIsIDIy MjMsIDIyMjRdPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7fSw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDt7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NlbWFudGljczogJnF1b3Q7RkVDJnF1 b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzc3JjczogWzIyMjIsIDIyMjVdPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7fV08YnI+DQomZ3Q7ICZuYnNwO31dPGJyPg0KJmd0OyB9PGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IENvbnN0cnVjdGl2ZSBmZWVkYmFjayBpcyB3ZWxj b21lIDopLjxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5y dGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxicj4NCiZndDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_57A15FAF9E58F841B2B1651FFE16D28104FB3EGENSJZMBX01msgint_-- From martin.thomson@gmail.com Mon Jun 17 14:23:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BB021F9CEB for ; Mon, 17 Jun 2013 14:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0SBXoRjp-bz for ; Mon, 17 Jun 2013 14:23:39 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id EAC6521F9CE9 for ; Mon, 17 Jun 2013 14:23:38 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so2789913wgh.3 for ; Mon, 17 Jun 2013 14:23: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=ATKHU88KUiyWvqwkCHhh5LyLtLJEHqnWXR0lZw40oA0=; b=WQTPE1JjDBQly3WcRXshmlFutm+D+JzgLIpYuJVvapEIjQ6TPqAT+xuaceuGKLmNWT K8LMwpYftg9JZ56zeVIIZXgIQ1wnmZG9fB3QzYnrFy8mI2sdoZojjHGORVATW9zpTYlH GWt7F4U3myqMH3gY6cpq4wtcs7Ub9GB/1GxBsJg/yqkW9qSTakP3UGfDLkScEInRi7D1 GW2dc5EXNGZ0Zi2FasZ3XBUQkljEngNj9eowSBkPufsxpO+hsv4yWw7yufwTDSw3ZtUh Ui8LqVbgRBOAVa1YYa/x2lAmhxAPvDRVXPcJxQ6YDigsii9t4jS0NQFDqt/Su5kMspN8 N+fQ== MIME-Version: 1.0 X-Received: by 10.194.216.41 with SMTP id on9mr5010457wjc.3.1371504218093; Mon, 17 Jun 2013 14:23:38 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 17 Jun 2013 14:23:38 -0700 (PDT) In-Reply-To: <51BF5F00.90705@jitsi.org> References: <51BF5F00.90705@jitsi.org> Date: Mon, 17 Jun 2013 14:23:38 -0700 Message-ID: From: Martin Thomson To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 21:23:39 -0000 On 17 June 2013 12:09, Emil Ivov wrote: > So here's your chance: could you please share your view of how this would > look if done properly? Actually, it would look very similar to this. For everything. No SDP anywhere. It's comment 22. It's in the archives of the webrtc list: http://lists.w3.org/Archives/Public/public-webrtc/2012Oct/att-0076/realtime-media.html From martin.thomson@gmail.com Mon Jun 17 14:56:20 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5A021F9CD0 for ; Mon, 17 Jun 2013 14:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FoLANV21TFP for ; Mon, 17 Jun 2013 14:56:19 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 488A521F9CCF for ; Mon, 17 Jun 2013 14:56:19 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so2810481wgh.18 for ; Mon, 17 Jun 2013 14:56: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=q5xvj9jtFVmnm/yltEEkbfWzuyIUfCHOFuXIoEMyzU4=; b=oqw9L3VGLOrOSnQ/dTIo0I8Sq3KrqK8/EvZ17J2ics15L924IAmu2Pvj24x+C3271b 4CNp+vDuRB3KLaun1L4B9HY40DUUK3UpdLr4tM+Y/GCcXGd5ca1DRcx/ArVpGTR7MpEM PsEL9AGcGw0ldBuLbJousZHsu2kbchEwM39VseLp3plXPeZx9gz/1rauGBSVfmlelK0x fdTk8N/V0023G0AWaI5p5PrJSNx0Zg8KaJQBIMUxym2XqBe6670pBP45lXB6doKU4aoV CF7kS8BnyZaBTGZB3QVTlpDrqhlcyzJFX9Rr8sgsE8vgNv4htD18m1Ynkgmd8zHyEP7t rFuw== MIME-Version: 1.0 X-Received: by 10.180.20.46 with SMTP id k14mr6003913wie.14.1371506178439; Mon, 17 Jun 2013 14:56:18 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 17 Jun 2013 14:56:18 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Jun 2013 14:56:18 -0700 Message-ID: From: Martin Thomson To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 21:56:20 -0000 On 17 June 2013 12:26, Peter Thatcher wrote: > Yes, I was expecting you to be more supportive. I'm surprised out how your > want "all or nothing". I'm afraid if our options for a clean API are all or > nothing, we'll just end up with nothing. I'd prefer to try incremental > improvements to word toward (eventually) a clean API. Yes, I apologize if the language seemed strong, but I stand by those words. The problem that I see with this, and it is a problem with any incremental approach, is that it produces two very different interaction models for things that are approximately the same fundamental operation. That is, when I add the first video track to a session I perform one set of actions. Then, when I add subsequent tracks, it's different. This also has all the purported drawbacks of comment 22 with respect to usability, whatever they are. There must have been some because I got a lot of heat about that when we discussed it. > Do you think it is impossible to work toward a clean API in an incremental > approach? If you think it's possible, I'd like to hear your thoughts on > how. The fundamental problem in WebRTC is the Offer/Answer semantics in the API. That's hard to remove now. I can't see an incremental change that would remove that, and that's every bit as much of a problem as having to deal with SDP. That's how we got to comment 22. I know that you wanted to do some sort of object representation of SDP. That can be done incrementally by adding to RTCSessionDescription, or by replacing it entirely, but it doesn't really go to the core of the problem. If you were willing to tolerate the fact that there would be two code paths, two control surfaces that effectively did the same things. > By the way, these API additions would greatly minimize the amount of SDP > editing necessary for JS clients that don't use SDP for signalling. And > later incremental improvements could reduce it further. Also, it's no > longer necessary to do offer/answer for adding tracks. It's only the intial > PeerConnection setup that needs to do Offer/Answer. So, it doesn't inherit > all the problems quite as much as you described. It may be slightly > abominable, but I certainly consider it less abominable than the SDP editing > necessary without it. If I am forced to do SDP, I'd rather not have something else as well unless that something else is getting me something concrete. What you are proposing does too little to advance a cleaner API model to justify the extra overhead that it introduces. It doesn't tackle the hard problems. I appreciate the philosophy behind no-plan, which is not a non-plan in any sense. It addresses a concern that we (unfortunately) didn't really touch on in the MMUSIC call this morning. However, the requirements of the-not-no-plan could be far more elegantly addressed within the constraints of the current API without adding all those extra description bits. --Martin From ibc@aliax.net Mon Jun 17 14:56:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3B321F9DFC for ; Mon, 17 Jun 2013 14:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ncrmSX0Sjsf for ; Mon, 17 Jun 2013 14:56:25 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7FF21F9CDA for ; Mon, 17 Jun 2013 14:56:25 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id w7so2014005qeb.4 for ; Mon, 17 Jun 2013 14:56:24 -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=xWCJeMYP44fPUFjdnU24f731IbGMi1xVYU6zUNQhtR8=; b=BX4VzOcxFZwK/TK0J/r0OMv/Ve1jrrArn9X8QKcrNU1q3/+Ffz0+EP1bYfWJOwm8aM pXGNv2RdssKuIfcPjUzkaKHNGgnD+8CcCNUHwDo0almSMchqer94tacdx5adpayZAvWE mebrV3r2xnN3waDuMM9OUiz2HR6e2lygxOZfuH+zF+k3uqWtDcyCQx0WPhpCYbEpEFvK //GdDOQW4OIxdG4O3+KT3UFxX+EsFFpgNsS6c9FktSS5m/gwXc+Ifr/zdai3yxGgeblB nfAHZqiQWMM5FvYxvTSudbiMC0uvq8bP0HRL8IWSC4KB89zbCWR5z3xLDo+uzatjKKdZ Ecfw== X-Received: by 10.229.147.71 with SMTP id k7mr7318526qcv.129.1371506184509; Mon, 17 Jun 2013 14:56:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Mon, 17 Jun 2013 14:56:04 -0700 (PDT) In-Reply-To: References: <51BF5F00.90705@jitsi.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 17 Jun 2013 23:56:04 +0200 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnqz9q1Pwdw4S4hsEKvEwNgRQ/K2CPfUqGWNk5xa75EoPUk+JRUyE/4dAJc4U+fZ/9DRQHh Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 21:56:30 -0000 2013/6/17 Martin Thomson : > On 17 June 2013 12:09, Emil Ivov wrote: >> So here's your chance: could you please share your view of how this woul= d >> look if done properly? > > Actually, it would look very similar to this. For everything. No SDP > anywhere. It's comment 22. > > It's in the archives of the webrtc list: > http://lists.w3.org/Archives/Public/public-webrtc/2012Oct/att-0076/realti= me-media.html +1 What is the aim of NoPlan? The draft says "This document does not question the use of SDP and the Offer/Answer model". Why? It should question it since it treats SDP as if it was a silly and unmanageable binary blob. It is like "we must live with SDP because it is mandatory, but let's try to ignore it as much as possible". If so, why don't ignore SDP entirely? However NoPlan is the best we have if, finally, SDP is mandated in WebRTC. I think it is time to write two lists: 1) Advantages of using SDP in WebRTC. 2) Dissadvantages of using SPD in WebRTC. -- I=C3=B1aki Baz Castillo From roman@telurix.com Mon Jun 17 15:03:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6AF21F9D5C for ; Mon, 17 Jun 2013 15:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.527 X-Spam-Level: X-Spam-Status: No, score=-1.527 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZYrdyGD5C81 for ; Mon, 17 Jun 2013 15:03:51 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1C84D21F9D8B for ; Mon, 17 Jun 2013 15:03:49 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z11so4048938wgg.1 for ; Mon, 17 Jun 2013 15:03:49 -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=zekPQlmhU0N5dVisGbSev1hZ9WIlsOzdPc59XE7atMs=; b=SNPFGWd7CwZJ64kWL2Sjb2y5Ffo4L6fuTG0MEbiUGA1R/abHpRjzT6/gsJd0iTnpJ/ YdKW18hQqcroCCBLZhqwp34lgDx+I8xlKV0GDpb1BP2j4TerwK7PdMi92rlha/54FrUD cebRyPbUnFf7Vz5I0P6RuQ19RzoiyT80ltBxt7wBEBZZw9JndrRJkKw9kDwm1pbIluqq mP3YoniIwrYcPBTZStFNVUvYAf0D1a+4hnJM+8e2dsprGqw1XNllCmwXNZv0iwyskF9e MHiHbx3OpnXaRrdsJEwNjsfofUsSj7sxWL1d1genkqmH0atvx1CCuOe3OruuE7MARG1/ q7Xg== X-Received: by 10.180.81.8 with SMTP id v8mr5982198wix.15.1371506629253; Mon, 17 Jun 2013 15:03:49 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [2a00:1450:400c:c00::22e]) by mx.google.com with ESMTPSA id ay7sm25072764wib.9.2013.06.17.15.03.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Jun 2013 15:03:48 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id c11so2815776wgh.13 for ; Mon, 17 Jun 2013 15:03:47 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.88.161 with SMTP id bh1mr5934534wib.8.1371506627767; Mon, 17 Jun 2013 15:03:47 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Mon, 17 Jun 2013 15:03:47 -0700 (PDT) In-Reply-To: References: <51BF5F00.90705@jitsi.org> Date: Mon, 17 Jun 2013 18:03:47 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=f46d04426c0a5af7de04df60c5d3 X-Gm-Message-State: ALoCoQmqfAL+4uuEf5tbGqvoSSOV7nTAaerKSjnLu01P3gaHJMyJzizjsTiySbRebrnEFpkYHiRD Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 22:03:51 -0000 --f46d04426c0a5af7de04df60c5d3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jun 17, 2013 at 5:56 PM, I=F1aki Baz Castillo wrote= : > > What is the aim of NoPlan? The draft says "This document does not > question the use of SDP and the Offer/Answer model". Why? It should > question it since it treats SDP as if it was a silly and unmanageable > binary blob. It is like "we must live with SDP because it is > mandatory, but let's try to ignore it as much as possible". If so, why > don't ignore SDP entirely? > > However NoPlan is the best we have if, finally, SDP is mandated in WebRTC= . > > I think it is time to write two lists: > > 1) Advantages of using SDP in WebRTC. Somebody wrote a bunch of code based on JSEP. > 2) Dissadvantages of using SPD in WebRTC. An unmanageable monster was created which currently stays in the way of developing new functionality (bundle), building applications (does not provide obvious ways to implement obvious tasks, like adding an extra stream without re-negotiating all the existing ones) and even interop with existing SIP endpoints (which was the original but now is complicated since it would require a non trivial set of constraints and subsequent SDP manipulation). _____________ Roman Shpount --f46d04426c0a5af7de04df60c5d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Mon, Jun 17, 2013 at 5:56 PM, I=F1aki Baz Castillo <ibc@aliax.net&= gt; wrote:
     --0015174989ee81d1ce04df84a0b3-- From ibc@aliax.net Wed Jun 19 09:54:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4071521F9D88 for ; Wed, 19 Jun 2013 09:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qytM+P-lGxMB for ; Wed, 19 Jun 2013 09:54:49 -0700 (PDT) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 902EC21F9DAC for ; Wed, 19 Jun 2013 09:54:30 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id s14so3445989qeb.29 for ; Wed, 19 Jun 2013 09:54:30 -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=98OoeDStPBtLcfUoXQtKkAPlzF/GWl7aj3sK7Ya8EhE=; b=Pk3H9BnqAbfAEFspkkIt5VjMhQ+w7IGdxW/65jSs8jgysYlmFUFO9/d2DdLQrS62a9 dwffv68UcSgWz705S6yEb9ZlpyyWq12LCm2R5zP3fVub0Uut1ItIiYFx22u1W2YJTBKo Mhg1t6eBeB8Ztnfuuo5LmfwoPRS2wZ2DSFTGcKZFCPaWybpZKAPHOFpLcigd5hrtoLR6 ND0i6y8knVsZ1NCCp41iuS1NURg/JwDrGxNafIwAGJj+Ik4u3sh04/8k0Hx/k57Oqkyb iyy2gcy4D7LWsThpZUOi4xRvkXjF9tiuH6gKdDxU2EgMS8jypz1o+kTV/nCbd3CFS/GO G2OA== X-Received: by 10.229.147.71 with SMTP id k7mr1437965qcv.129.1371660869967; Wed, 19 Jun 2013 09:54:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 09:54:09 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 19 Jun 2013 18:54:09 +0200 Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkqbQc95vZIMMa1YkzEJIPrR1UhKh1AJaovYhBHhpaHXEHy4Dgnra31zIS94Zd7uGVrRGrP Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 16:54:55 -0000 2013/6/19 Peter Thatcher >> >> The summary of what I want/believe: >> 1) I want as close to raw access to RTP/ICE streams, media, sources, out= puts, codecs as viable. Obviously doing the actual transmission, encoding/d= ecoding from JS is not feasible (yet), nor is secure [ICE must occur for mu= tual agreement to exchange data between peers], but having controls for how= these components are wired together is extremely feasible from JS and woul= d allow immensely powerful apps to be produced from JS. > > > What would you like to do that you can't do via SDP right now? You said = this isn't just about working through SDP. But I don't see anything concre= te you can't do right now with sufficient SDP parsing/building/munging/hack= ery. If the "solution" with the current API/model is "SDP parsing/building/munging/hackery" then let me strongly say that: *** I don't want SDP *** :) > > The WG may dislike and reject your proposal With all due respect, And which proposal will the WG accept then? It's frustrating IMHO that we still have no pro-SDP arguments in this long thread and still must accept that the SDP model would be the chosen one. Does the silence strategy mean "SDP usage was already voted two years ago, ignore current complains"? That could be a good argument if during the last TWO years we had *something* really good and usable based on the SDP model, but we don't have that. Instead we have tons of drafts and alternatives to make SDP fulfil WebRTC requirements, and none of them is good. IMHO current complains are based on the *experience* of the people trying to make the SDP model work in WebRTC, including people that were in favour of SDP two years ago and now have changed their mind (like me). >> Anyone who argues that they need/want that simple SDP media negotiation = API must understand that a lower level API would allow a wrapper API to pro= duce the same WebRTC API the have today but be built entirely from JavaScri= pt > > > That depends on how low-level you go. If you go too low-level, it become= s infeasible to do things correctly and performantly in JavaScript. There are tons of bug in current WebRTC implementations. Yes, there will be also bugs in future JS libraries dealing with WebRTC internals (those we propose), but they can be potentially fixed without requiring upgrading the browser, and without waiting for all the browser vendors to fix/implement them. And with all due respect, I don't agree at all with the "JavaScript performance issue" that worries you, but I think that it is not up to me to prove that a problem does not exist ;) Best regards. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Jun 19 09:58:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EE621F9DCD for ; Wed, 19 Jun 2013 09:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOCZyt+eMk9F for ; Wed, 19 Jun 2013 09:58:51 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id D8F9121F9DCA for ; Wed, 19 Jun 2013 09:58:50 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id cm16so542285qab.7 for ; Wed, 19 Jun 2013 09:58: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=P6Fsl1dp+tDgU/xrkO4MTBnxEkBtqsp19C7qViBTD0c=; b=ZndljDG+hNr1YA+8tcrm1J+FWL2HCq0WK9iCI2RlV/JSv/9ogGNjuNUceCa4QZwVPC 3B8BCnHzwKOlEXVpnVB8axkQcMP9n4cl1O76wS2IaBfr41RZNaSsK5BrDtVTjXg7uAOm 7Ze7WBM3X9q0WID0CIUqM2gLZGXQt7dj2bmgu0Q4M55dond4WcZ2uVKgZ38WdreNBaze lIxSl9leEwNnzjjDaN8lL9ernz5hj7gbDjiz0t93OzNhIVtF1Gfm8Y6Kqq+NZfsw99Bv H0P76FnnQd2FVhfsqBmeksvXWdVWdyySudjAlNugPhRGZ2RQNzwaUIRE0hv3afnbALcK /q5g== X-Received: by 10.224.187.129 with SMTP id cw1mr4777731qab.68.1371661129907; Wed, 19 Jun 2013 09:58:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 09:58:29 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 19 Jun 2013 18:58:29 +0200 Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlUwnusq43wFeucvLA/Sf/fpbcu913nCl4km+1oJ7je6MB0id9y8m39i0/5XF0gguYzfKt6 Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 16:58:51 -0000 2013/6/19 Peter Thatcher : > But generally, anything beyond the most basic uses of the API requires at > least some SDP hackery, and advanced uses require a lot. Hi Peter, most of the solutions in your mail are basically based on "blob SDP parsing/mangling/hackery". Can we agree that the current API is a pain?:) -- I=C3=B1aki Baz Castillo From pthatcher@google.com Wed Jun 19 10:02:03 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCB621F9DDC for ; Wed, 19 Jun 2013 10:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lraW5rcBtSgH for ; Wed, 19 Jun 2013 10:01:52 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7AED521F9DD4 for ; Wed, 19 Jun 2013 10:01:50 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa11so5375870pad.19 for ; Wed, 19 Jun 2013 10:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KsvFWiJoCCn6nHYA6v/8xWTPEXjK7x626hlra/ULlYk=; b=BVcBkQ+3gSaJnRMX4bsl/SyzxL3OT5uVokgRsswI9ur4/l54+pkX6VfNwagwMSa4Tn UwLfyOYRBlRiwAeejZZAHpQqoIAlFHvjlQr8Q1NKCY5oqDCnycqDOpUpDGxySQqyS1P8 +KcF/Cwlx+/0Ai6/tETKIhdf+Ae92DDOJKzQ6f8TuhwTMEjGHxc34DzoOiZoxfW8PAtX DxzMtww8nD8OVT9Oygt2LoJP1d/iUdoa6VUayWi9ZIE7SmwDYoRvqLE/LOMn9mJpUsPd jqrOEqNcwh1iPdkcIR5Oy80fDGQEVsq8hYy1hZTpaIFD7+0roP3pMPxvwWmJsAGGLpjJ fIog== 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=KsvFWiJoCCn6nHYA6v/8xWTPEXjK7x626hlra/ULlYk=; b=Xem1Ajqg3Rk6ymbgezoYwz4eosa/2iuOf1W7+2lyCgGyZ3US38NOfEQb6NFqhk1oIa Ph005/QCQNlH96/3LuW85dDLZuBB420ScZOS9mZLOegvXd6pxCqAOx3nefY0D5qaQ8AO 7GS+CsPAguQlsxAI+YTtsk0nAytOi3D+JVcHOzO+Lb3jimYx8lq/MFnD7IHBzgUhbwlq /lbAGd5EDM4IMwrv2bRVwCpDPqxEcm/2yvVqUvRZh5zTkSdbvRQtop4p5QGygyPfnuov lyUz98WvOkef6BssjL9toajusetdZaSnHMjWl3imioOaB+hZf9BOgNCOL7XwFfdvbSZS QmfQ== X-Received: by 10.66.240.70 with SMTP id vy6mr7785093pac.70.1371661309716; Wed, 19 Jun 2013 10:01:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 10:01:08 -0700 (PDT) In-Reply-To: <51C1D55D.6040905@hookflash.com> References: <51C1D55D.6040905@hookflash.com> From: Peter Thatcher Date: Wed, 19 Jun 2013 10:01:08 -0700 Message-ID: To: Robin Raymond Content-Type: multipart/related; boundary=047d7b15aba91e48a804df84c93d X-Gm-Message-State: ALoCoQk8tC+fbf0PPxQzsV7UChXT0/l0Jy2ooT++WYxFaHCKZv2Ko0Dj1M7DzWsudHopBgw1aY+50IhSXTvbbnvixly9ONbCNdzorROy2Kt431PwdmbbRxgJzxeVdp+ShV6jBg60Gkc90q1tUrm9ZHlPh9pbsJJZ+kKNBzdBM/GbXbqHa6fnA88IykX121/kZzGSgCqYoFsI Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 17:02:03 -0000 --047d7b15aba91e48a804df84c93d Content-Type: multipart/alternative; boundary=047d7b15aba91e48a604df84c93c --047d7b15aba91e48a604df84c93c Content-Type: text/plain; charset=UTF-8 On Wed, Jun 19, 2013 at 8:59 AM, Robin Raymond wrote: > > Then why not move to a lower level API and do it as a shim (i.e. reverse > polyfill)? > > > If provided a lower level API that works without SDP where the individual > network/media component wiring/attributes can be controlled, we could > create the same WebRTC API that exists today for people who think "SDP out > to be enough for anybody" layered on top of it; They lose absolutely > nothing (in fact they gain a lot since now they can tweak the logic to be > even more compatible with their networks and dynamically update it as > needed instead of waiting for the next browser "patch" to be deployed > everywhere on all platforms). The only different is that it's an JavaScript > implementation rather than written in C++. They get what they want but we > get what we need. > There are two separate things here: 1. adding to the current API to allow JS to avoid SDP. 2. removing what is there that uses SDP. You're saying you want to add new things and remove olds things. But I think really you just want to add what you want, and it would matter if what you didn't want to use were still there. So I think it's better to talk about what we can add to the API to make it easier to work with rather than talk about starting from scratch. Removing the existing pieces would not be nearly as easy as you make it sound. That's the difference, they *want* this API as it "works/good enough for > them", whereas many of *need* a lower level API to do anything > sophisticated at all. > You don't need a lower level API. SDP munging can get you what you need. But what you want is to not have to do SDP munging. My proposal is to add two methods to PeerConnection that, if optionally used by JS, will give you what you want for media streams: the ability to control what is sent and received without SDP munging. It does not, however, relieve you from SDP munging on the transport side. But as I've pointed out, that's limited to about 10 lines of SDP, so at least it's much less SDP munging. Later, once could consider more simple additions that reduce the need for SDP munging further. > As it stands, it makes many use cases for us who whom don't want to do > basic SIP/SDP signaling extremely challenging, complex, ugly, brittle, if > not outright impossible. I've explained many times why using SDP with > offer/answer is horribly bad idea (and I can re-share those links if > needed). > > I think your dislike of SDP is sufficiently clear. > -Robin > > > Peter Thatcher > 19 June, 2013 11:15 AM > > > > I hope so as well. Unfortunately, Microsoft's input seems to be "our way > or the highway" and the input of others seems to be "SDP ought to be > enough for anybody". My thinking is that we can make incremental > improvements toward a cleaner API without being so extreme at either end. > And I hope I can find others that think similarly. > > > --047d7b15aba91e48a604df84c93c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Wed, Jun 19, 2013 at 8:59 AM, Robin Raymond &l= t;robin@hookflash.= com> wrote:

    Then why not move to a lower level API and do it as a shim (i.e. reverse polyfill)?
    =C2=A0

    If provided a lower level API that works without SDP where the=20 individual network/media component wiring/attributes can be controlled,=20 we could create the same WebRTC API that exists today for people who=20 think "SDP out to be enough for anybody" layered on top of it; Th= ey lose absolutely nothing (in fact they gain a lot since now they can tweak=20 the logic to be even more compatible with their networks and dynamically update it as needed instead of waiting for the next browser "patch&qu= ot; to=20 be deployed everywhere on all platforms). The only different is that=20 it's an JavaScript implementation rather than written in C++. They get= =20 what they want but we get what we need.

    There are two separate things here: 1. =C2=A0adding to the current A= PI to allow JS to avoid SDP. =C2=A02. =C2=A0removing what is there that use= s SDP. =C2=A0

    You're saying you want to add new things and remove= olds things. =C2=A0But I think really you just want to add what you want, = and it would matter if what you didn't want to use were still there. = =C2=A0So I think it's better to talk about what we can add to the API t= o make it easier to work with rather than talk about starting from scratch.= =C2=A0Removing the existing pieces would not be nearly as easy as you make= it sound.

    That's the difference, they *want* this API as it "works/good enou= gh for them", whereas many of *need* a lower level API to do anything=20 sophisticated at all.

    You don't = need a lower level API. =C2=A0SDP munging can get you what you need. =C2=A0= But what you want is to not have to do SDP munging.

    My proposal is to add two methods to PeerConnection that, if optionally u= sed by JS, will give you what you want for media streams: the ability to co= ntrol what is sent and received without SDP munging. =C2=A0It does not, how= ever, relieve you from SDP munging on the transport side. =C2=A0But as I= 9;ve pointed out, that's limited to about 10 lines of SDP, so at least = it's much less SDP munging. =C2=A0Later, once could consider more simpl= e additions that reduce the need for SDP munging further.
    =C2=A0
    As it stands, it makes many use cases for us who=20 whom don't want to do basic SIP/SDP signaling extremely challenging,=20 complex, ugly, brittle, if not outright impossible. I've explained many= =20 times why using SDP with offer/answer is horribly bad idea (and I can=20 re-share those links if needed).


    I think your dislike of SDP is s= ufficiently clear.
    =C2=A0
    -Robin


    <= div style=3D"display:table-cell;white-space:nowrap;vertical-align:middle;wi= dth:100%"> Peter Thatcher
    =20 19 June, 2013=20 11:15 AM
    =



    I hope so as well. =C2=A0Unfortunately,=20 Microsoft's input seems to be "our way or the highway" and th= e input of=20 others seems to be "SDP=C2=A0ought to be enough=20 for anybody". =C2=A0My thinking is that we can make incremental= =20 improvements toward a cleaner API without being so extreme at either=20 end. =C2=A0And I hope I can find others that think similarly.



    --047d7b15aba91e48a604df84c93c-- --047d7b15aba91e48a804df84c93d Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 668ceceb21d7da7d_0.1.1 /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQECAQEB AQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAARCAAZABkDAREA AhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUKBwAAAAAAAAACAQME BQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAAAAAAAAAAAAADAAEEAv/E ACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oADAMBAAIRAxEAPwDuEt+gW/UL et6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJVIl7eXLCaZIGwBl3TY8epPx2+jy2 ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJ Ew/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx+a69/JSf9alIlste0VzaNpeFrcT9KKymotyi aZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mRUfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRD nu5azS8miKqjOTVkKqS/psG37fo1Fbabeg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GA cpOwBeN+U8/IkGbsiS8b7ryogmbzhbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH 4hPOI0DkjZtaJtFxuVEbIUUiyeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJ nYn9dnAQWl722p4ot37yzqnlfp6FrqbwawG8/9k= --047d7b15aba91e48a804df84c93d-- From pthatcher@google.com Wed Jun 19 10:13:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C986521F9ABD for ; Wed, 19 Jun 2013 10:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.587 X-Spam-Level: X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqjnV0hlsUdc for ; Wed, 19 Jun 2013 10:13:33 -0700 (PDT) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id A7C5021F9C69 for ; Wed, 19 Jun 2013 10:13:29 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so5324465pdj.28 for ; Wed, 19 Jun 2013 10:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VUynfzAyR1+VOBzSABOlbzBz7rMQ6syKCXv+9ejJxTI=; b=Eg43nO/iPPsEh2sudZ0aTCIZb16Ch3KFQunM76HVKcgScZvDJlmHOjegGVmvh3RWf2 pUeASztJ5QOTkMrXH0nLhT1VwIbAFez+0k5cgiPMvNlLU5dTi6xSiSu28v0Jdxu7PCmJ qnsiGJvLHWENnv5Y8kFpbsDIu2NJ4k3BxESvY1aDu1wqOUY06FH8KEnikVM0wRE/9ysG p7CthUMDy+zoXfU6Xr2eP1o5kyOUKc+Ov5rT1da9+9RctXyiGJUvCDn1jPgcS99z+ux/ BzY9sSe9sVNVfNLmVaW+FYmDOnOFXd8anBbv3y4tMo2cgSIVTIBtWFW/KaoX40Y74ZS8 zemQ== 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=VUynfzAyR1+VOBzSABOlbzBz7rMQ6syKCXv+9ejJxTI=; b=EBF7n8itVgXl5VMfyud3VFhaDRE90kDWUMXIZpM75xsZdnb6WaxPCUvjr3cxEQKJ1c vfw5B3DwrQ8gnRoVQcUIJUfegTYLaoBT1EFvVYXjIqDgX+uJTZwtr1W7MxXMRyWSYe1m bLQRtihNJFubDT2grb6q0bknUyOfU/JV2470y3rQVj88e1Wo2Ve6BnEvmzv6awqj5Aq0 6CL8+Z6aHOwDMZbeaSRFaS5s/EpvZ6vGOIzT/WE1qogJjknTLlwRrIBP4g6MTThYRo87 YtAPCPdtF6Lklgi9KWoyXwvgXT9iAnFWtj5qq1Z1CuYzgb1TVQBfBehPS1Tl+59OPcnQ CIAg== X-Received: by 10.68.163.165 with SMTP id yj5mr3746160pbb.141.1371662009320; Wed, 19 Jun 2013 10:13:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 10:12:49 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Wed, 19 Jun 2013 10:12:49 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b86d556d164cd04df84f299 X-Gm-Message-State: ALoCoQnakXwqtTMdAlhwHVG38bHho2m0QKOi6tJet/BLh2Oft9tPT8WvzLffPJQcf44B7YangjrwZ20UkHGoKJSLqG12u6ZUQAnWWXtseVlXpcVF6FX5+0y1nM/2KngFEI/DRaH+knkcmj9XU9qdUTDOP3EVre6AbABPRZBLrmHjLK4A+lKVYrgN2j+BDar51vk1o8rikImK Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 17:13:38 -0000 --047d7b86d556d164cd04df84f299 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 19, 2013 at 9:58 AM, I=C3=B1aki Baz Castillo wr= ote: > 2013/6/19 Peter Thatcher : > > But generally, anything beyond the most basic uses of the API requires = at > > least some SDP hackery, and advanced uses require a lot. > > Hi Peter, most of the solutions in your mail are basically based on > "blob SDP parsing/mangling/hackery". Can we agree that the current API > is a pain?:) > > > Of course. That's why I made a proposal that attempts to lessen the pain (the NoPlan JS API). I'm trying to help you :). > -- > I=C3=B1aki Baz Castillo > > --047d7b86d556d164cd04df84f299 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Wed, Jun 19, 2013 at 9:58 AM, I=C3=B1aki Baz Castillo <ibc@aliax.n= et> wrote:
    2013/6/19 Peter Thatcher <pthatcher@google.com>:
    > But generally, anything beyond the most basic uses of the API req= uires at
    > least some SDP hackery, and advanced uses require a lot.

    Hi Peter, most of the solutions in your mail are basically based on "blob SDP parsing/mangling/hackery". Can we agree that the curren= t API
    is a pain?:)



    Of course. =C2=A0That'= s why I made a proposal that attempts to lessen the pain (the NoPlan JS API= ). =C2=A0I'm trying to help you :).
    =C2=A0
    --
    I=C3=B1aki Baz Castillo
    <ibc@aliax.net>= ;

    --047d7b86d556d164cd04df84f299-- From roman@telurix.com Wed Jun 19 10:17:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D0921F9DC5 for ; Wed, 19 Jun 2013 10:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yArIWP0SRB8m for ; Wed, 19 Jun 2013 10:17:52 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4E18321F9DDF for ; Wed, 19 Jun 2013 10:17:48 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so4806761wgh.12 for ; Wed, 19 Jun 2013 10:17: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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=9IVMGXwK94Ke5asHGwLilj13ofCpm/DyWIw19MbmeHk=; b=DQ31dTTb/SvbUjXMZtdoCqaeFz4ubsQW8YLUnG9O6IWQ+oaWv3MNWIra8UgZjNTwiE 8IEly7w6itFzhbHtZkpA+x6uzN01wLLhpAQMFQVSraEL9lX4RNXHhX9W2r6D2vLAjFMB maKHz1k0AgRWiOI83wdJAGO9U05NAi9QFGOEklHl1+hsZTDj3dchjzR69zr0yGa5DLtR U3KLimlbJNoSRqgbyCAcYzvM+lQqegqqaGyk6pcDuEPqm5bkyTaUnHKY5kmwGWhUj1ZV cxqwNdA4hUt3RPKfQXle29PsgdeJKKyFvcCEqM44MqWGVKbbzbgMydy7omn01Ctr36DX OIeg== X-Received: by 10.194.103.73 with SMTP id fu9mr2954173wjb.70.1371662267414; Wed, 19 Jun 2013 10:17:47 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [2a00:1450:400c:c05::22b]) by mx.google.com with ESMTPSA id ay7sm10570247wib.9.2013.06.19.10.17.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 10:17:46 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hj3so952454wib.10 for ; Wed, 19 Jun 2013 10:17:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.119.228 with SMTP id kx4mr2931593wjb.33.1371662265682; Wed, 19 Jun 2013 10:17:45 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Wed, 19 Jun 2013 10:17:45 -0700 (PDT) In-Reply-To: References: <51C1D55D.6040905@hookflash.com> Date: Wed, 19 Jun 2013 13:17:45 -0400 Message-ID: From: Roman Shpount To: Peter Thatcher Content-Type: multipart/alternative; boundary=089e012292e21916b504df8502e8 X-Gm-Message-State: ALoCoQnRGUIG0/4BX7y93CgxpUyEHFkdItac7C+8AH0M8yqwmKzbFnzx9aBBeu/ALuxe4T4TYfwB Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 17:17:53 -0000 --089e012292e21916b504df8502e8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 19, 2013 at 1:01 PM, Peter Thatcher wrote: > There are two separate things here: 1. adding to the current API to allow > JS to avoid SDP. 2. removing what is there that uses SDP. > > You're saying you want to add new things and remove olds things. But I > think really you just want to add what you want, and it would matter if > what you didn't want to use were still there. So I think it's better to > talk about what we can add to the API to make it easier to work with rather > than talk about starting from scratch. Removing the existing pieces would > not be nearly as easy as you make it sound. > > Let me approach this from a different angle: Do you think it is possible to create an interoperable, re-implementable API based on SDP? Currently, SDP format changes with each release in a way that breaks both SDP mungling code and external connected end-points. What I want is an API that does not rely on a string blog to encapsulate every new feature. New features should be implemented via new methods. I need something standard enough that I can have a stable application implementation. As it stands right now WebRTC will not pass the W3C standard process, so we need either spend a lot more time tying down SDP or create the API that avoids it. I think you underestimate the amount of effort needed to finalize SDP. At the current rate I see this process taking another 2-3 years. It also creates a dependency on MMUSIC, which has its own priorities. So, if you want a realistic API standard, you need to look for a way around SDP. Also, using SDP just for transport is wasteful. All you need are 3 string parameters which can be passed individually without parsing/creating a string blog which carries another 5 things that carry no meaning for transport (version, origin, etc). _____________ Roman Shpount --089e012292e21916b504df8502e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Wed, Jun 19, 2013 at 1:01 PM, = Peter Thatcher <pthatcher@google.com> wrote:
    There are two separate things here: 1. =A0adding to the cu= rrent API to allow JS to avoid SDP. =A02. =A0removing what is there that us= es SDP. =A0

    You're saying you want to add new things and remove= olds things. =A0But I think really you just want to add what you want, and= it would matter if what you didn't want to use were still there. =A0So= I think it's better to talk about what we can add to the API to make i= t easier to work with rather than talk about starting from scratch. =A0Remo= ving the existing pieces would not be nearly as easy as you make it sound.<= /div>


    Let= me approach this from a different angle: Do you think it is possible to cr= eate an interoperable, re-implementable API based on SDP? Currently, SDP fo= rmat changes with each release in a way that breaks both SDP mungling code = and external connected end-points. What I want is an API that does not rely= on a string blog to encapsulate every new feature. New features should be = implemented via new methods. I need something standard enough that I can ha= ve a stable application implementation. As it stands right now WebRTC will = not pass the W3C standard process, so we need either spend a lot more time = tying down SDP or create the API that avoids it. I think you =A0underestima= te the amount of effort needed to finalize SDP. At the current rate I see t= his =A0process taking another 2-3 years. It also creates a dependency on MM= USIC, which has its own priorities. So, if you want a realistic API standar= d, you need to look for a way around SDP.

    Also, using SDP just for transport is wasteful. All you= need are 3 string parameters which can be passed individually without pars= ing/creating a string blog which carries another 5 things that carry no mea= ning for transport (version, origin, etc).
    _____________
    Roman Shpount
    =A0
    --089e012292e21916b504df8502e8-- From ibc@aliax.net Wed Jun 19 10:21:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343F321F9BA5 for ; Wed, 19 Jun 2013 10:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.656 X-Spam-Level: X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d27et-TOGGUo for ; Wed, 19 Jun 2013 10:21:18 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 80F3A21F9B86 for ; Wed, 19 Jun 2013 10:21:17 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id n20so557542qaj.6 for ; Wed, 19 Jun 2013 10:21:17 -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=skJrqhVWT2lubPaDdyH02KLo+8cEooCSccyQZv9wyBc=; b=AdmO1pLiToe0OwV2VynlPHkQcTaqBbAihn4mSmI5pNScDYQ3buuKVdnz44FD3NkLSn wr2g4KOxbwp5J+Ia/yKDQnBjUPZFFGqlY7iBcvGFP7SkbGohr1zpfTqDPOiVP/ZRw9s5 aRQ3rpl3EKiK5dHcAerET5PbsygMTjtVFxy/eZTJM+bpLPNQtsNLPNsEOtiRGink2lVQ xsDINRf3KED7xsJmu8tmheIc3+/l+A/BWsGpach0dsO6gHqXQkJ/f+zopGPLJPXR5y6q fFjNGY0tw8dgdVwOS5LHuKYQw04QJGy14sZk6Bi+3kyh3vQnpwcxGLZ1iDB4b5cMGBbu i5TA== X-Received: by 10.229.149.198 with SMTP id u6mr1559920qcv.20.1371662477409; Wed, 19 Jun 2013 10:21:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 10:20:57 -0700 (PDT) In-Reply-To: References: <51C1D55D.6040905@hookflash.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 19 Jun 2013 19:20:57 +0200 Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnFB8jIzbgzIdnnWvZvB2RuuFwGTFOTiHGLffAq37orNNLEWRyO9QMSLsF5MpSVnKJl89QN Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 17:21:19 -0000 2013/6/19 Peter Thatcher > You don't need a lower level API. SDP munging can get you what you need.= But what you want is to not have to do SDP munging. > > My proposal is to add two methods to PeerConnection that, if optionally u= sed by JS, will give you what you want for media streams: the ability to co= ntrol what is sent and received without SDP munging. It does not, however,= relieve you from SDP munging on the transport side. But as I've pointed o= ut, that's limited to about 10 lines of SDP, so at least it's much less SDP= munging. Later, once could consider more simple additions that reduce the= need for SDP munging further. You base your proposal on the fact that SDP is here forever and must be used in WebRTC, and then propose some new API methods along with *lot* of SDP JS parsing/mangling/hackery to mitigate the API limitations. While it could be the best we have for now, IMHO it is still a hack or workaround to just circumvent the real problem and the real limitation. Things can be done much better if we remove SDP from the equation. Best regards. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Jun 19 10:24:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB70D21F9E2D for ; Wed, 19 Jun 2013 10:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOlevOj6xwGX for ; Wed, 19 Jun 2013 10:24:01 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7F77421F9E61 for ; Wed, 19 Jun 2013 10:24:01 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id ne12so3369915qeb.41 for ; Wed, 19 Jun 2013 10:24:00 -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=VjKDuooVaM5GjpaIK9zz41vSPRUpYWeUaMtOfaE1Gv0=; b=hotab9G+kMwzk22MAmeeMP9WwLDRZMi8PwmPgpTEEUdfeN9zasCIgM+Ld3DOjKVTdt RG2tRJYuQRlOrjl9AUXU/Qc/J0yQhkExKHRAvJ4kzXPN79wxBuDAf7fujukLiEySWdni Gm34auep4Ppx7Mn84zBq6vkAQkYsHx9JaKPcBoU8DPUJSGWO26XZySSyS2lT+m8gvJoS Di1A2/ut4yNYACG7HZYnrznnES54BLddjG8xz2AIdmbBTQjuLfqHvCLO2AoMEMQpNN8B uexkRLUFLeWizliTDgO85CPXFawIv/LMlW7ClmG8TvKlB+WtMy6RufxbJLz+VI5pOpoD Yoqg== X-Received: by 10.229.149.198 with SMTP id u6mr1564097qcv.20.1371662640638; Wed, 19 Jun 2013 10:24:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 10:23:40 -0700 (PDT) In-Reply-To: References: <51C1D55D.6040905@hookflash.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 19 Jun 2013 19:23:40 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnSitze34O629tpMZCoO5/Fo9NhXWS8TqXLAcWbxxgvizKARDBB1D/ev0HYdjqTo7bEKM/K Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 17:24:07 -0000 2013/6/19 Roman Shpount : > Also, using SDP just for transport is wasteful. All you need are 3 string > parameters which can be passed individually without parsing/creating a > string blog > which carries another 5 things that carry no meaning for > transport (version, origin, etc). Identical ICE candidates for each m=3D line when the fact is that we use a single transport, the "backward compatibility" c=3Dline, etc etc -- I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Jun 19 10:27:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B6B21F9E0C for ; Wed, 19 Jun 2013 10:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hm-ykp4lKoBb for ; Wed, 19 Jun 2013 10:27:40 -0700 (PDT) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5491F21F9E18 for ; Wed, 19 Jun 2013 10:27:38 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id q19so3378718qeb.2 for ; Wed, 19 Jun 2013 10:27:38 -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=9eD5SnahKLeXmaTUcAPi0sWkRiIPQIPG3IAf0PdQ+5U=; b=cezkaMwvuo7OsSgfh6BBq0oGgeA+n9L8oNvGRx8U9qFLdpQh37Mn7vP7IgM0QAiMWq 4nrYUuvdA31lRiePb9RYG7Ck+WUkRZf0UxHF/uGHfXEo+rj/OlcsStbhvJWcxLA5n3cr 2Yvve0tVrkzpL6AL6yBpIgmgCP3uBptBD8lXR8p85WlenbF5QmAbaFBlzV4YC4eM/I4N LGOONxF+pxhQrnx4slOhN0r0UBz/uPO/UE2lFWPNVmFJyEw4VMBQlv99L5KdFysGL0jm vRzQWB6Zvf5wNzR/elYrO9YeeNZ35vfcmg/YqrFm/e4Bycwim5PwxCAoo+N/rbx1pkc/ 4sJA== X-Received: by 10.224.164.205 with SMTP id f13mr4921371qay.16.1371662858454; Wed, 19 Jun 2013 10:27:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 10:27:17 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 19 Jun 2013 19:27:17 +0200 Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnf4BugxAnDLyx2G9slNoG5ZzPJDxBJePypU58Oe5qC2tsan/TRA7tT+vVbeJNFuxWZ8vT0 Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 17:27:45 -0000 2013/6/19 Peter Thatcher : > Of course. That's why I made a proposal that attempts to lessen the pain > (the NoPlan JS API). I'm trying to help you :). And don't you agree that the pain is even less if we entirely remove SDP? And don't you agree that after two years we don't have yet a valid SDP model for WebRTC so it makes no sense to keep it since it helps nothing? :) -- I=C3=B1aki Baz Castillo From pthatcher@google.com Wed Jun 19 10:30:12 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5677521F9E2C for ; Wed, 19 Jun 2013 10:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.741 X-Spam-Level: X-Spam-Status: No, score=-1.741 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRGB6BLnuY2I for ; Wed, 19 Jun 2013 10:30:11 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 180D621F9E33 for ; Wed, 19 Jun 2013 10:30:07 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id ld11so5411374pab.36 for ; Wed, 19 Jun 2013 10:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TcfpJcw9leA9sPWv4ux6ZnDqC7V+4ch8GIOyLW+0a40=; b=Uyz7XCS5WbPnJgsyMQOCw8dEldm6FGHQpHX4dehUQKUToKXEkuIg3XceScKZolPR9x dpY5XYgmat9KTtek7Q1WmSVy7eUef/4i390CLr0rCQPeO3gxir73UDR1ejEvqd1hmEEY K6Ch6Cq1fwWcegZmlJTfb52csYoC1f4MxQCPboYfBS3lvmQchvmvHBTJ6JZPKHaR88PA vL2RqzqhfQOTBVtd0h8U2eaS4SzjYHSNll3nuIdKVKWY5EROBFWkjYpQtqEk+JANBxiU QOU5MqMd9iv+v7xUjECirLXQnTvgnA8VeUGsVd0q2qnxDoO1GA24ZaVKyuk5veeErDvQ GOfg== 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=TcfpJcw9leA9sPWv4ux6ZnDqC7V+4ch8GIOyLW+0a40=; b=aMYDBbtw9NQqbGgR9+58JW42nse14hVfnxEnZZZ3FOLMr6o/czM23ni8ooqrQorAI4 mTmbNkyixmdJlWmcfIqT8ZRDiJu3SFFiOq6kCVyG8NdKpo4OU2XarUi29sWqJw/B9r2F ZmMwrWNDkoFIitEMbpuaQCs7bsrBuWvZjbMSfTSfjUoYPs5xfXlGxKC55++ZwZhXyQbT IsoUKAE0RmoGjwjP40cVTuu6UdU1lDnV/uMro1PDMSCgXFZa06j1eXMUI+TKcWbwlw2n VdQAJuZ8z6g4PJ774AIYrOXBuFMhh+3U6U2dmxPqx1FBHInRzeN40WAQaQT5BHK4I7mE YOoA== X-Received: by 10.68.213.231 with SMTP id nv7mr3890458pbc.70.1371663007723; Wed, 19 Jun 2013 10:30:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 10:29:26 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> From: Peter Thatcher Date: Wed, 19 Jun 2013 10:29:26 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=e89a8f923c7a53d25b04df852ee0 X-Gm-Message-State: ALoCoQlYT5FJanOcEdOuUbxMA8/M5xv0zT+AFIBZMX6K2wqj9PUnCbjq8d4JVUgIMLoOvZ/LokuYugnR8j62FCEJUNjTb4Jo/t/CMNLysaHNoSVrdysuSO0qAwdrGRTbyxzHxWButnhfMUkz+aQLFp6n+B1snJ12u67bdhnr9LGumvcqH97E2CQfrYk8TG1RxBAQ6kp9mJiT Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 17:30:12 -0000 --e89a8f923c7a53d25b04df852ee0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 19, 2013 at 9:54 AM, I=C3=B1aki Baz Castillo wr= ote: > 2013/6/19 Peter Thatcher > > >> > >> The summary of what I want/believe: > >> 1) I want as close to raw access to RTP/ICE streams, media, sources, > outputs, codecs as viable. Obviously doing the actual transmission, > encoding/decoding from JS is not feasible (yet), nor is secure [ICE must > occur for mutual agreement to exchange data between peers], but having > controls for how these components are wired together is extremely feasibl= e > from JS and would allow immensely powerful apps to be produced from JS. > > > > > > What would you like to do that you can't do via SDP right now? You sai= d > this isn't just about working through SDP. But I don't see anything > concrete you can't do right now with sufficient SDP > parsing/building/munging/hackery. > > > If the "solution" with the current API/model is "SDP > parsing/building/munging/hackery" then let me strongly say that: > > *** I don't want SDP *** > > :) > It may be helpful to respond to your original request to the WG chairs with something a little more clear, specific, concise, and actionable then your original email. I know many people reading this thread will just think "what's this? Oh, just more SDP ranting" and it will fall on deaf ears. Also, explaining your use case and specific pain points may be helpful. > > > > > > > > The WG may dislike and reject your proposal > > > With all due respect, > > And which proposal will the WG accept then? I don't know. Perhaps none of them. It's possible we'll be stuck with SDP munging forever. But I think you'll maximize your chances of success by being clear with what you need, propose digestible solutions, avoid being ranty, and not try to blow it all up and start from scratch. But I could be wrong. Maybe there's a better way. > It's frustrating IMHO that > we still have no pro-SDP arguments in this long thread and still must > accept that the SDP model would be the chosen one. Does the silence > strategy mean "SDP usage was already voted two years ago, ignore > current complains"? That could be a good argument if during the last > TWO years we had *something* really good and usable based on the SDP > model, but we don't have that. Instead we have tons of drafts and > alternatives to make SDP fulfil WebRTC requirements, and none of them > is good. > IMHO current complains are based on the *experience* of the people > trying to make the SDP model work in WebRTC, including people that > were in favour of SDP two years ago and now have changed their mind > (like me). > It may help you to understand this from the other side's perspective. Many people in the WG like SDP and want to use SDP for everything and don't want to change SDP much, if at all. And when someone comes through ranting about SDP, they don't find that persuasive. If there's new information gained in the last two years that might be persuasive, present that. But try to do it in clear, concise, way that says "here's what I'm trying to do", "here's my experience", "here's my pain", "here's how I think we can fix it". That might be a lot more persuasive. Then again, it might now; who knows? :) >> Anyone who argues that they need/want that simple SDP media negotiation API must understand that a lower level API would allow a wrapper API to produce the same WebRTC API the have today but be built entirely from JavaScript > > > That depends on how low-level you go. If you go too low-level, it becomes infeasible to do things correctly and performantly in JavaScript. There are tons of bug in current WebRTC implementations. Yes, there will be also bugs in future JS libraries dealing with WebRTC internals (those we propose), but they can be potentially fixed without requiring upgrading the browser, and without waiting for all the browser vendors to fix/implement them. And with all due respect, I don't agree at all with the "JavaScript performance issue" that worries you, but I think that it is not up to me to prove that a problem does not exist ;) Best regards. -- I=C3=B1aki Baz Castillo --e89a8f923c7a53d25b04df852ee0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Wed, Jun 19, 2013 at 9:54 AM, I=C3=B1aki Baz Castillo <ibc@aliax.n= et> wrote:
    2013/6/19 Peter Thatcher <pthatcher@google.com>

    >>
    >> The summary of what I want/believe:
    >> 1) I want as close to raw access to RTP/ICE streams, media, source= s, outputs, codecs as viable. Obviously doing the actual transmission, enco= ding/decoding from JS is not feasible (yet), nor is secure [ICE must occur = for mutual agreement to exchange data between peers], but having controls f= or how these components are wired together is extremely feasible from JS an= d would allow immensely powerful apps to be produced from JS.
    >
    >
    > What would you like to do that you can't do via SDP right now? =C2= =A0You said this isn't just about working through SDP. =C2=A0But I don&= #39;t see anything concrete you can't do right now with sufficient SDP = parsing/building/munging/hackery.


    If the "solution" with the current API/model is "SDP parsing/building/munging/hackery" then let me strongly say that:

    *** I don't want SDP ***

    :)

    It may be helpful to respond to your= original request to the WG chairs with something a little more clear, spec= ific, concise, and actionable then your original email. =C2=A0I know many p= eople reading this thread will just think "what's this? =C2=A0Oh, = just more SDP ranting" and it will fall on deaf ears.

    Also, explaining your use case and specific pain points= may be helpful.
    =C2=A0




    >
    > The WG may dislike and reject your proposal


    With all due respect,

    And which proposal will the WG accept then?

    I don't know. =C2=A0Perhaps none of them. =C2=A0It's possible we&= #39;ll be stuck with SDP munging forever.

    But I th= ink you'll maximize your chances of success by being clear with what yo= u need, propose digestible solutions, avoid being ranty, and not try to blo= w it all up and start from scratch. =C2=A0But I could be wrong. =C2=A0Maybe= there's a better way.
    =C2=A0
    =C2=A0
    It's frustrating I= MHO that
    we still have no pro-SDP arguments in this long thread and still must
    accept that the SDP model would be the chosen one. Does the silence
    strategy mean "SDP usage was already voted two years ago, ignore
    current complains"? That could be a good argument if during the last TWO years we had *something* really good and usable based on the SDP
    model, but we don't have that. Instead we have tons of drafts and
    alternatives to make SDP fulfil WebRTC requirements, and none of them
    is good.

    IMHO current complains are based on the *experience* of the people
    trying to make the SDP model work in WebRTC, including people that
    were in favour of SDP two years ago and now have changed their mind
    (like me).

    It may help you to understan= d this from the other side's perspective. =C2=A0Many people in the WG l= ike SDP and want to use SDP for everything and don't want to change SDP= much, if at all. =C2=A0 And when someone comes through ranting about SDP, = they don't find that persuasive. =C2=A0

    If there's new information gained in the last two y= ears that might be persuasive, present that. =C2=A0But try to do it in clea= r, concise, way that says "here's what I'm trying to do",= "here's my experience", "here's my pain", &quo= t;here's how I think we can fix it". =C2=A0That might be a lot mor= e persuasive. =C2=A0Then again, it might now; =C2=A0who knows? :)



    >> Anyone who argues that they need/want that simple SDP media negoti= ation API must understand that a lower level API would allow a wrapper API = to produce the same WebRTC API the have today but be built entirely from Ja= vaScript
    >
    >
    > That depends on how low-level you go. =C2=A0If you go too low-level, i= t becomes infeasible to do things correctly and performantly in JavaScript.=

    There are tons of bug in current WebRTC implementations. Yes, there will be also bugs in future JS libraries dealing with WebRTC internals
    (those we propose), but they can be potentially fixed without
    requiring upgrading the browser, and without waiting for all the
    browser vendors to fix/implement them.

    And with all due respect, I don't agree at all with the "JavaScrip= t
    performance issue" that worries you, but I think that it is not up to<= br> me to prove that a problem does not exist ;)



    Best regards.


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

    --e89a8f923c7a53d25b04df852ee0-- From ibc@aliax.net Wed Jun 19 10:32:20 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1084721F9E3B for ; Wed, 19 Jun 2013 10:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.656 X-Spam-Level: X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QlDnzfsnRTH for ; Wed, 19 Jun 2013 10:32:19 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 40F6E21F9E2F for ; Wed, 19 Jun 2013 10:32:18 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id z10so3149718qcx.7 for ; Wed, 19 Jun 2013 10:32:17 -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=EnXmAGivngRjMtqM60jPELKlN6RgQ4knq8eh4UPD1BQ=; b=P+eBjYY/OMLpTUFSZnB0eyIgHdwxfUpYjNkswo84CQ56iN4rKLRI5H57AjXGj6u8UY JuBP+zXtH5t5DPz+3JtBXgXfExPFWRMmU7b8I7DlcfdZ4v8NgB4hrXXLtPHnigs81af9 z/DYsvxUYggdCWhdm+Hd7RkPxvsbQzAhloyWhJO4VvIYyWuQk/bOOul1aPU/ffHWzizV mfktk0Gofo63XTFfb0qX2rqvOlp+vuOPeNeP6+/cBU6iM17yRSMF27bXb3w/KRzqqS1H jszoDICs9kW4zR+bFEDREGxnK/nI/G88xgfS/l5sRDaeCWYMRC1EAK49Uc6hpA3+flre EYvg== X-Received: by 10.229.25.5 with SMTP id x5mr1492231qcb.35.1371663137547; Wed, 19 Jun 2013 10:32:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 10:31:57 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 19 Jun 2013 19:31:57 +0200 Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQncEcXdvv1Cb3JV31oYMWngJ20kwq6qkxO+roNG7nDmPu301LcFrP0//Dc2cDgDruX82hGy Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 17:32:20 -0000 Agreed with all you said, and thanks ;) 2013/6/19 Peter Thatcher : > > > > On Wed, Jun 19, 2013 at 9:54 AM, I=C3=B1aki Baz Castillo = wrote: >> >> 2013/6/19 Peter Thatcher >> >> >> >> >> The summary of what I want/believe: >> >> 1) I want as close to raw access to RTP/ICE streams, media, sources, >> >> outputs, codecs as viable. Obviously doing the actual transmission, >> >> encoding/decoding from JS is not feasible (yet), nor is secure [ICE m= ust >> >> occur for mutual agreement to exchange data between peers], but havin= g >> >> controls for how these components are wired together is extremely fea= sible >> >> from JS and would allow immensely powerful apps to be produced from J= S. >> > >> > >> > What would you like to do that you can't do via SDP right now? You sa= id >> > this isn't just about working through SDP. But I don't see anything >> > concrete you can't do right now with sufficient SDP >> > parsing/building/munging/hackery. >> >> >> If the "solution" with the current API/model is "SDP >> parsing/building/munging/hackery" then let me strongly say that: >> >> *** I don't want SDP *** >> >> :) > > > It may be helpful to respond to your original request to the WG chairs wi= th > something a little more clear, specific, concise, and actionable then you= r > original email. I know many people reading this thread will just think > "what's this? Oh, just more SDP ranting" and it will fall on deaf ears. > > Also, explaining your use case and specific pain points may be helpful. > >> >> >> >> >> >> > >> > The WG may dislike and reject your proposal >> >> >> With all due respect, >> >> And which proposal will the WG accept then? > > > I don't know. Perhaps none of them. It's possible we'll be stuck with S= DP > munging forever. > > But I think you'll maximize your chances of success by being clear with w= hat > you need, propose digestible solutions, avoid being ranty, and not try to > blow it all up and start from scratch. But I could be wrong. Maybe ther= e's > a better way. > > >> >> It's frustrating IMHO that >> we still have no pro-SDP arguments in this long thread and still must >> accept that the SDP model would be the chosen one. Does the silence >> strategy mean "SDP usage was already voted two years ago, ignore >> current complains"? That could be a good argument if during the last >> TWO years we had *something* really good and usable based on the SDP >> model, but we don't have that. Instead we have tons of drafts and >> alternatives to make SDP fulfil WebRTC requirements, and none of them >> is good. >> >> >> IMHO current complains are based on the *experience* of the people >> trying to make the SDP model work in WebRTC, including people that >> were in favour of SDP two years ago and now have changed their mind >> (like me). > > > It may help you to understand this from the other side's perspective. Ma= ny > people in the WG like SDP and want to use SDP for everything and don't wa= nt > to change SDP much, if at all. And when someone comes through ranting > about SDP, they don't find that persuasive. > > If there's new information gained in the last two years that might be > persuasive, present that. But try to do it in clear, concise, way that s= ays > "here's what I'm trying to do", "here's my experience", "here's my pain", > "here's how I think we can fix it". That might be a lot more persuasive. > Then again, it might now; who knows? :) > > > > >>> Anyone who argues that they need/want that simple SDP media negotiation >>> API must understand that a lower level API would allow a wrapper API to >>> produce the same WebRTC API the have today but be built entirely from >>> JavaScript >> >> >> That depends on how low-level you go. If you go too low-level, it becom= es >> infeasible to do things correctly and performantly in JavaScript. > > There are tons of bug in current WebRTC implementations. Yes, there > will be also bugs in future JS libraries dealing with WebRTC internals > (those we propose), but they can be potentially fixed without > requiring upgrading the browser, and without waiting for all the > browser vendors to fix/implement them. > > And with all due respect, I don't agree at all with the "JavaScript > performance issue" that worries you, but I think that it is not up to > me to prove that a problem does not exist ;) > > > > Best regards. > > > -- > I=C3=B1aki Baz Castillo > > --=20 I=C3=B1aki Baz Castillo From pthatcher@google.com Wed Jun 19 10:36:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A28321F91CE for ; Wed, 19 Jun 2013 10:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHKJjs29gfxH for ; Wed, 19 Jun 2013 10:36:11 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DB20721F90CC for ; Wed, 19 Jun 2013 10:36:11 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz11so5423513pad.30 for ; Wed, 19 Jun 2013 10:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=m+j8/zqnzUsWYWRueK+MKDii1cyOkoWl/u2fsrZCBsM=; b=VbNqSMwlBXC56XavOBjp0NEosaBRpZ8omuR2pZkpLBAyNV9UpzdjP8HoZxj+N5WFnY +tkKOHdpGYw2YPUaWrqb1uyOw0pLBaAtclzx3E7759f7wBP/pN+iWkVvEkqF9cbzW4mC nh+MHfHOkmzMQeNBsCPg7PxleTQuDCth2uVEfMNH6uB6dld12Dukacf3jtg/nYsFmsOf tBlxn2nVUJ7YK4kDrOh0UlRxZX9Ih6Xvk+AFfTVi/7NJbjl/5S8zh7qBjVXYRgYUf/az ZYfqtZS8yntBjTIrHzTpD0ICv2vfkgoU0vr3fLz8YFPQp7vf9TX0vLoBO5tiHGRkOh0N tHog== 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=m+j8/zqnzUsWYWRueK+MKDii1cyOkoWl/u2fsrZCBsM=; b=G064H2gDzecZNOB3BOzNUYOFSgMcTPbOz2cTZjMeT/6QkmlyVfv0EkC9NLOx5I4tTs eYyqkDc4sdAGoaHwx5ycQhqBAAlDbm8ZSgHX0Re6f7uMYsCTDvRj8nDoCDZ/O+QHyxcS cYIfkWy9r5DdgVgSL6+AdwoE0Selu1rkbNxvUPTtiNkZEs1FDQn+XC9cEbgMcdlfvQFq R6ct2A+n9h8/Qds114a1jQIGi82R0+bm8cm1JpsD8lugn/PaViSEVJH1x0nx2NX8taId 7zCSkYS+bpRkhHqrxLnYx3wPi1XbxPQdDcKWQP4TW0dPLhT60Jlpebj9Z8V24lkTrtSq wEhA== X-Received: by 10.66.240.70 with SMTP id vy6mr7912345pac.70.1371663371542; Wed, 19 Jun 2013 10:36:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 10:35:31 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Wed, 19 Jun 2013 10:35:31 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b15aba9033ec904df8544ee X-Gm-Message-State: ALoCoQl3HgPXt8CqY+UCe7B7pO8C9+KvJWD1WbnfdkY0rz0CJtSopW4Zqc/fPyDUjEl+ufm9eckd6EC+4eqKwONtU+2CxiOmnoNqDreYT0knn2ThyyyqQuXXVpGUoA8pwdVvT69/bBEGiRbEx+Wo5Xxh6VR62zF2SQ7Sm8GDc8rXJ20kljQ6IIz9g1ZEuWMyU+mgFFyWZFc8 Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 17:36:16 -0000 --047d7b15aba9033ec904df8544ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 19, 2013 at 10:27 AM, I=C3=B1aki Baz Castillo w= rote: > 2013/6/19 Peter Thatcher : > > Of course. That's why I made a proposal that attempts to lessen the pa= in > > (the NoPlan JS API). I'm trying to help you :). > > And don't you agree that the pain is even less if we entirely remove SDP? > > I don't think it's removal of SDP that you want. I think what you want is a way to use the API without using SDP. If the SDP is still there, but you don't have to use it, you're still happy, right? And don't you agree that after two years we don't have yet a valid SDP > model for WebRTC so it makes no sense to keep it since it helps > nothing? > My thinking is "choose your battles". Fight for what you really need rather than fighting everything at once. If you want a way to bypass SDP, fight for that. If you fight to remove SDP altogether, you'll increase your likelihood of being rejected. > :) > > > -- > I=C3=B1aki Baz Castillo > > --047d7b15aba9033ec904df8544ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Wed, Jun 19, 2013 at 10:27 AM, I=C3=B1aki Baz Castillo <ibc@aliax.n= et> wrote:
    2013/6/19 Peter Thatcher <pthatcher@google.com>:
    > Of course. =C2=A0That's why I made a proposal that attempts t= o lessen the pain
    > (the NoPlan JS API). =C2=A0I'm trying to help you :).

    And don't you agree that the pain is even less if we entirely rem= ove SDP?


    I don't think it's removal of = SDP that you want. =C2=A0I think what you want is a way to use the API with= out using SDP. =C2=A0If the SDP is still there, but you don't have to u= se it, you're still happy, right?

    And don't you agree that after two years we don't have yet a valid = SDP
    model for WebRTC so it makes no sense to keep it since it helps
    nothing?

    My thinking is "choose yo= ur battles". =C2=A0Fight for what you really need rather than fighting= everything at once. =C2=A0If you want a way to bypass SDP, fight for that.= =C2=A0If you fight to remove SDP altogether, you'll increase your like= lihood of being rejected.


    :)


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

    --047d7b15aba9033ec904df8544ee-- From ibc@aliax.net Wed Jun 19 10:45:46 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7C421F9DDB for ; Wed, 19 Jun 2013 10:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.657 X-Spam-Level: X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFUzdL7Enonf for ; Wed, 19 Jun 2013 10:45:45 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8772121F9DD8 for ; Wed, 19 Jun 2013 10:45:44 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id n1so3246748qcw.30 for ; Wed, 19 Jun 2013 10:45: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=O7UKS8R4c2tjtzaKIe5aSULODLjhYxiAnxuWNxCHLt8=; b=I0kLtJVyetMMrY3KooIxw9P/6VF/nRDIfpjn+k9KtEcNxDSf7duLxpNrq5yDvRrT71 Omma7cazB72mlYbIovhVWqYnRkbsmvGA//2NUuj1QoDZsVOeSnSHXU37DDNJ116ru1u4 iMwMulg8lpQSW0J+sqJhIsntOzNUUx6+GQa88AAyyWdHqA7KwU+9jJs7M3QylFG6CAzS uBQAqaiAzEQ2OWicpzv2+PxuZIyBLhMljoo74fh+FI65i43jHLNTSBBWpJbkChRfS2Fl uJU4EojV6Hmn2o2LEI8NDMSrved7ZCMWnUyK+hZVi5PyH3f2reTFbSdC+/OH9Xa0wI0E m3XA== X-Received: by 10.229.147.71 with SMTP id k7mr1518966qcv.129.1371663943775; Wed, 19 Jun 2013 10:45:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 10:45:23 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 19 Jun 2013 19:45:23 +0200 Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl9pu8tqK476lGWiaavEhhXd5Pch3IFG1rCC/o6YDb+F0P5WRLD8gd0ObmDnbIxu62zqraP Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 17:45:46 -0000 2013/6/19 Peter Thatcher : > I don't think it's removal of SDP that you want. I think what you want i= s a > way to use the API without using SDP. If the SDP is still there, but you > don't have to use it, you're still happy, right? AFAIK no API in the world provides two ways to do the same, or at least, no API provide them with the same "quality" and "affection". Duplicating the work does not seem a long-term solution IMHO. But I may be wrong :) -- I=C3=B1aki Baz Castillo From matthew@matthew.at Wed Jun 19 10:46:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA0B21F92B7 for ; Wed, 19 Jun 2013 10:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si9XeC6blKTg for ; Wed, 19 Jun 2013 10:46:37 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACF321F90EF for ; Wed, 19 Jun 2013 10:46:16 -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 722B0250041 for ; Wed, 19 Jun 2013 10:46:10 -0700 (PDT) Message-ID: <51C1EE64.1010109@matthew.at> Date: Wed, 19 Jun 2013 10:46:12 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050102040309010306010602" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 17:46:42 -0000 This is a multi-part message in MIME format. --------------050102040309010306010602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 6/19/2013 10:35 AM, Peter Thatcher wrote: > > > > On Wed, Jun 19, 2013 at 10:27 AM, Iñaki Baz Castillo > wrote: > > 2013/6/19 Peter Thatcher >: > > Of course. That's why I made a proposal that attempts to lessen > the pain > > (the NoPlan JS API). I'm trying to help you :). > > And don't you agree that the pain is even less if we entirely > remove SDP? > > > I don't think it's removal of SDP that you want. I think what you > want is a way to use the API without using SDP. If the SDP is still > there, but you don't have to use it, you're still happy, right? I want the offer/answer state machine to go away. I don't like an API that requires me to fight with it to get it to do what I want, no matter what kinds of things I put in (SDP, JSON, wahtever). Why should I need to have the browser make an "offer" that I can then manipulate to turn into an "answer" just to get it to listen to some RTP and render it? Matthew Kaufman --------------050102040309010306010602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    On 6/19/2013 10:35 AM, Peter Thatcher wrote:



    On Wed, Jun 19, 2013 at 10:27 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
    2013/6/19 Peter Thatcher <pthatcher@google.com>:
    > Of course.  That's why I made a proposal that attempts to lessen the pain
    > (the NoPlan JS API).  I'm trying to help you :).

    And don't you agree that the pain is even less if we entirely remove SDP?


    I don't think it's removal of SDP that you want.  I think what you want is a way to use the API without using SDP.  If the SDP is still there, but you don't have to use it, you're still happy, right?

    I want the offer/answer state machine to go away. I don't like an API that requires me to fight with it to get it to do what I want, no matter what kinds of things I put in (SDP, JSON, wahtever).

    Why should I need to have the browser make an "offer" that I can then manipulate to turn into an "answer" just to get it to listen to some RTP and render it?

    Matthew Kaufman
    --------------050102040309010306010602-- From martin.thomson@gmail.com Wed Jun 19 10:46:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95EA21F9A97 for ; Wed, 19 Jun 2013 10:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqmXyMHX4atY for ; Wed, 19 Jun 2013 10:46:59 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D629B21F9B3E for ; Wed, 19 Jun 2013 10:46:56 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q58so4690295wes.19 for ; Wed, 19 Jun 2013 10:46:56 -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=ujNzrIHd/ZfLR1BbA0pjFg0a4vyTuZNECzeWZXSPcd8=; b=EBZDXYSmEm+dylCbPx6zHX8XI00OCoF5CZrjaB054xHu9EVzf+qomGFCqVQE/JQuZg FLJJB5PFG2A+4sVywFBtZijvwpG28btXbHsgKJzv+DdHrztjqkpsHNvzqazmG3N+YgGW YRUnjrAEWsD1xwDpia4004S6wGX+Bxaur5V0IYWYxYlnaVij0DoRkwMN3N4B8vI9FxVW bK9Wji+T5C/F2r07c6A2WFrWGoDsN+pOpw7ks8IUQ5m0cQyS3yE+CH3Ext5P8XNXf20T 67CwhNIARsaJw/1ywmN0L7rm39IIr3iHWzN9XLUPnqZJ7pRn1UkN609vsUBSb3iJMQon bWwQ== MIME-Version: 1.0 X-Received: by 10.180.20.46 with SMTP id k14mr2930378wie.14.1371664016023; Wed, 19 Jun 2013 10:46:56 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 19 Jun 2013 10:46:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Jun 2013 10:46:55 -0700 Message-ID: From: Martin Thomson To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 17:46:59 -0000 On 19 June 2013 08:15, Peter Thatcher wrote: > Unfortunately, Microsoft's input seems to be "our way or the highway" The good thing about this forum is that correcting gross misrepresentation is as easy as it is to propagate it. Microsoft's input is that Offer/Answer is difficult to remove without also removing a reliance on SDP at the same time. CU-RTC-Web is a demonstration of one solution to that problem that we believe is workable. That proposal was input, not ultimatum. We'd be happy to consider other alternatives, but we don't believe that any attempt that retains both O/A and SDP to be a worthwhile step. The proposals I've seen for incremental refinement don't successfully avoid the SDPNG trap. Most increase the API surface area, often dramatically, which burdens both browser implementations and API users. I personally don't believe it to be possible to avoid this problem without tackling the core problem, which unfortunately requires a little bit of courage. From matthew.kaufman@skype.net Wed Jun 19 11:02:05 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5371D21F9BD4 for ; Wed, 19 Jun 2013 11:02: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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2B7cHtiRMhM for ; Wed, 19 Jun 2013 11:01:59 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id D612221F9AE7 for ; Wed, 19 Jun 2013 11:01:57 -0700 (PDT) Received: from BN1AFFO11FD018.protection.gbl (10.58.52.200) by BN1AFFO11HUB026.protection.gbl (10.58.52.136) with Microsoft SMTP Server (TLS) id 15.0.707.0; Wed, 19 Jun 2013 18:01:50 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD018.mail.protection.outlook.com (10.58.52.78) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Wed, 19 Jun 2013 18:01:50 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.171]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0136.001; Wed, 19 Jun 2013 18:01:35 +0000 From: "Matthew Kaufman (SKYPE)" To: Peter Thatcher Thread-Topic: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Thread-Index: AQHObEI8XC7enqULikaWynaBYkCsupk76I4AgAACKQCAAB+igIAAApYAgAB4ZYCAABBRgIAABAmAgAB39oCAACnpgIAAAi8AgAADxACAABQNqg== Date: Wed, 19 Jun 2013 18:01:34 +0000 Message-ID: References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_AFC6D2DF3C384E2090A7A8A10E667471skypenet_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(13464003)(51444003)(52034003)(24454002)(377454003)(46102001)(16406001)(74502001)(56776001)(53806001)(47446002)(51856001)(16236675002)(81342001)(54356001)(81542001)(50986001)(74366001)(76786001)(76796001)(6806003)(512954002)(79102001)(76482001)(4396001)(47976001)(56816003)(47736001)(31966008)(74662001)(54316002)(49866001)(77096001)(69226001)(561944002)(80022001)(20776003)(65816001)(71186001)(74876001)(63696002)(36756003)(33656001)(74706001)(59766001)(15202345003)(77982001)(30436002)(16601075003)(16297215004); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB026; H:TK5EX14HUBC104.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:3; MX:3; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 08828D20BC Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 18:02:05 -0000 --_000_AFC6D2DF3C384E2090A7A8A10E667471skypenet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fighting the offer/answer machinery in the browser is always possible, but = never easier. I want an API that let's me tell the browser what to do, not engage in an a= rgument with it until it is beaten into submission. I think an API that let= 's me tell the browser what to do will then also be much easier to extend t= o give me *more* control. As an example, putting A and V over the same transport... Could be one more= JS API, instead of a discussion at MMUSIC about how to encode that in our = must-use SDP, followed by JS code I need to write to argue with the browser= when it offers that but I want to turn it off, or vice versa. Matthew Kaufman (Sent from my iPhone) On Jun 19, 2013, at 9:50 AM, "Peter Thatcher" > wrote: I asked "is there something that can't be done without sufficient SDP mungi= ng"? You answered "I have something that can be done with sufficient SDP m= unging". OK. But do you have something that *can't* be done with SDP mun= ging? If there's nothing that can't be done with SDP munging, then this whole thr= ead boils down to "give us an API that has the same amount of control as th= e current one, but without requiring SDP munging to do advanced things". A= nd if that's is what is desired, then at least it can be clear and concise. On Wed, Jun 19, 2013 at 9:36 AM, Matthew Kaufman > wrote: I provided a use case that, unless one wants to write a bunch of SDP-mungin= g JS state machine cannot be done. The problem is that such use cases are either 1) ignored or 2) dismissed be= cause of course if one writes said JS, they are possible with the current A= PI Matthew Kaufman (Sent from my iPhone) On Jun 19, 2013, at 9:28 AM, Peter Thatcher > wrote: I might be wrong, but I tried reading and understanding your whole email, a= nd it seems to come down to "I don't want to use SDP or a different (JSON) = form of SDP". That's a fine thing to request, but why don't you just say t= hat? It would save everyone a lot of reading and confusion to be more conc= ise. Or, if you have specific things you'd like to do but can't, what are they? = I think that would help me, and others, understand more easily. Use cases= would be helpful. On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond > wrote: The trouble is not that we can choose to send whatever we want over the wir= e. I know we can. If the WebRTC API is left with SDP as it stands, I'll dis= sect the SDP from the browser, reinterpret and reconstruct on the SDP on th= e remote side. That is NOT the issue. The summary of what I want/believe: 1) I want as close to raw access to RTP/ICE streams, media, sources, output= s, codecs as viable. Obviously doing the actual transmission, encoding/deco= ding from JS is not feasible (yet), nor is secure [ICE must occur for mutua= l agreement to exchange data between peers], but having controls for how th= ese components are wired together is extremely feasible from JS and would a= llow immensely powerful apps to be produced from JS. What would you like to do that you can't do via SDP right now? You said th= is isn't just about working through SDP. But I don't see anything concrete= you can't do right now with sufficient SDP parsing/building/munging/hacker= y. 2) I don't want my primary interface to control media/RTP engines to be via= obtaining or providing SDPs to the browser (or any alternative serialized = format); especially given that SDP requires a round trip offer/answer to th= e remote party to affect change (e.g. it's entirely possible to do that sta= teless and one-sided). The SPD interface API is a monolithic do-everything = serialized format to control an engine but extremely badly/poorly/short sig= hted (regardless if it is SDP or whatever instead), and it's wholly unneede= d. Short summary: "I don't want to use SDP". Right? 3) I don't want a replacement for SDP with another more "pretty" format lik= e JSON. Short summary: "I don't want to use SDP or a different syntax for SDP". Ri= ght? 4) I want no specified requirement from the browser to have any particular = form of media negotiation API requirement what-so-ever (regardless if I can= opt to substitute with my own format on the wire or not) Short summary: "I don't want to use SDP or a different syntax for SDP". Ri= ght? 5) Using SDP with offer/answer build into the browser binary is a horribly = BAD technical choice (even for SIP folks) and must be stopped, see: http://= www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html Short summary: "I don't want to use SDP". Right? I too want to understand the rational for keeping something as bad as SDP w= ith offer/answer as the primary mechanism for controlling the media compone= nts and interaction to those component and more importantly, I'd too would = like to open debate to agreeing or not to provide a lower layer API rather = than a media negotiation API as a complete substitute alternative to SDP wi= th offer/answer. If we can agree that it's far superior to have a lower level media/RTC comp= onent API rather than a media negotiation API, then we can propose what tha= t API could look like (and there are people who have already have starting = proposals). I'd throw my hat in the ring to propose such and API if necessa= ry as I've written such engines from scratch before. But I don't want to wa= ste time proposing ore reviewing such an API which will be summarily dismis= sed because people are so stuck on requiring a media negotiation API built = into the browser binary, and specifically SDP with offer/answer in this cas= e. The WG may dislike and reject your proposal, but there's a bit of truth to = the old mathematically incorrect sports adage "you miss 100% of the shots y= ou don't take". Anyone who argues that they need/want that simple SDP media negotiation API= must understand that a lower level API would allow a wrapper API to produc= e the same WebRTC API the have today but be built entirely from JavaScript That depends on how low-level you go. If you go too low-level, it becomes = infeasible to do things correctly and performantly in JavaScript. upon a lower level API. Thus they can have their "just add-milk" baking API= . But those of us who need control of the raw ingredients beyond the "just = add milk" can still innovate. -Robin Peter Thatcher 19 June, 2013 2:49 AM Correct my if I'm wrong, but the API already leaves what goes over the wire= completely up to the JS app. So we couldn't re-open a debate of "SDP or n= ot SDP" for the wire format, because there's nothing to debate. We already= decided it would be left to the JS to decide. The only thing left to deba= te is the API. Or am I wrong? _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb Christer Holmberg 19 June, 2013 2:34 AM Hi, We need to be very clear what we talk about, or some people are always goin= g to be confused :) So, AFAIK, the discussion is about SDP O/A usage in the API, only in the AP= I, and nowhere but the API. Whatever people us on the wire is outside the scope. Right? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Peter Thatcher [pthatcher@google.com] To: Martin Thomson [martin.thomson@gmail.com] CC: rtcweb@ietf.org [rtcweb@ietf.org] Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Martin, you're right; that was overly harsh of me. Adam, I apologize. I'l= l be civil in the future. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb Peter Thatcher 19 June, 2013 1:36 AM Martin, you're right; that was overly harsh of me. Adam, I apologize. I'l= l be civil in the future. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb Martin Thomson 18 June, 2013 6:25 PM I agree with Peter, except for this bit: Adam is much harder to confuse than you think, or than he professes. Speaking of burning it all down and starting over. If you want a house-related analogy, that's not quite correct. It's refusing to build an extension because the old house, while legally fit for habitation, is falling down around your ears. Since you only need foundations, it's not that big a job (though I'll grant you that it's bigger than many people realize, even with that smaller scope). _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb Peter Thatcher 18 June, 2013 6:16 PM Adam, I think you're confused. As Ted pointed out, there are two different= uses of SDP: 1. as a control surface, 2. as a message format for signalli= ng. SDPNG was trying to replace SDP for #2. While I believe this thread w= as started entirely focused on #1. So you're talking about different thing= s. So far the only time spent on trying to replace or avoid SDP for #1 has bee= n "comment 22", and to a lesser extent the proposal I just made for adding = 2 methods to PeerConnection (createLocalStream and createRemoteStream). I= think it's incorrect to conclude that we should never try to improve #1 ju= st because other in the past failed to replace #2. They're very different. I also don't think we should burn down WebRTC and start over, but despite w= hat some seem to think, we don't have to choose between "burn it down" and = "never improve it". There are many options other than the two extremes. By the way, a gentle reminder: SDP is not the only way to do #2. I work on= a rather large system almost entirely build around Jingle, without a hint = of SDP, and it works just fine. Much better than SDP would have, I think. = Just because SDPNG didn't work out doesn't mean there will never be any wa= y other to do signalling than SDP. _______________________________________________ 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 --_000_AFC6D2DF3C384E2090A7A8A10E667471skypenet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Fighting the offer/answer machinery in the browser is always possible,= but never easier.

    I want an API that let's me tell the browser what to do, not engage in= an argument with it until it is beaten into submission. I think an API tha= t let's me tell the browser what to do will then also be much easier to ext= end to give me *more* control.

    As an example, putting A and V over the same transport... Could be one= more JS API, instead of a discussion at MMUSIC about how to encode that in= our must-use SDP, followed by JS code I need to write to argue with the br= owser when it offers that but I want to turn it off, or vice versa.

    Matthew Kaufman

    (Sent from my iPhone)

    On Jun 19, 2013, at 9:50 AM, "Peter Thatcher" <pthatcher@google.com> wrote:

    I asked "is there something that can't be done withou= t sufficient SDP munging"?  You answered "I have something t= hat can be done with sufficient SDP munging".   OK.  But do = you have something that *can't* be done with SDP munging?

    If there's nothing that can't be done with SDP munging, then this whol= e thread boils down to "give us an API that has the same amount of con= trol as the current one, but without requiring SDP munging to do advanced t= hings".  And if that's is what is desired, then at least it can be clear and concise.




    On Wed, Jun 19, 2013 at 9:36 AM, Matthew Kaufman= <matthew@matthew= .at> wrote:
    I provided a use case that, unless one wants to write a bunch of SDP-m= unging JS state machine cannot be done.

    The problem is that such use cases are either 1) ignored or 2) dismiss= ed because of course if one writes said JS, they are possible with the curr= ent API

    Matthew Kaufman

    (Sent from my iPhone)

    On Jun 19, 2013, at 9:28 AM, Peter Thatcher <pthatcher@google.com> wrote:

    I might be wrong, but I tried reading and understanding your whole ema= il, and it seems to come down to "I don't want to use SDP or a differe= nt (JSON) form of SDP".  That's a fine thing to request, but why = don't you just say that?  It would save everyone a lot of reading and confusion to be more concise.  

    Or, if you have specific things you'd like to do but can't, what are t= hey?  I think that would help me, and others, understand more easily. =  Use cases would be helpful.

    On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond <<= a href=3D"mailto:robin@hookflash.com" target=3D"_blank">robin@hookflash.com= > wrote:

    The trouble is not that we can choose to send whatever we want over the wir= e. I know we can. If the WebRTC API is left with SDP as it stands, I'll dis= sect the SDP from the browser, reinterpret and reconstruct on the SDP on th= e remote side. That is NOT the issue.

    The summary of what I want/believe:
    1) I want as close to raw access to RTP/ICE streams, media, sources, output= s, codecs as viable. Obviously doing the actual transmission, encoding/deco= ding from JS is not feasible (yet), nor is secure [ICE must occur for mutual agreement to e= xchange data between peers], but having controls for how these components a= re wired together is extremely feasible from JS and would allow immensely p= owerful apps to be produced from JS.

    What would you like to do that you can't do via SDP right now?  Y= ou said this isn't just about working through SDP.  But I don't see an= ything concrete you can't do right now with sufficient SDP parsing/building= /munging/hackery.

     
    2) I don't want my primary interf= ace to control media/RTP engines to be via obtaining or providing SDPs to t= he browser (or any alternative serialized format); especially given that SD= P requires a round trip offer/answer to the remote party to affect change (e.g. it's entirely possible to do th= at stateless and one-sided). The SPD interface API is a monolithic do-every= thing serialized format to control an engine but extremely badly/poorly/sho= rt sighted (regardless if it is SDP or whatever instead), and it's wholly unneeded.

    Short summary: "I don't want to use SDP".  Right?

    3) I don't want a replacement for= SDP with another more "pretty" format like JSON.

    Short summary: "I don't want to use SDP or a different syntax for= SDP".  Right?

    4) I want no specified requiremen= t from the browser to have any particular form of media negotiation API req= uirement what-so-ever (regardless if I can opt to substitute with my own fo= rmat on the wire or not)

    Short summary: "I don't want to use SDP or a different syntax for= SDP".  Right?
     
    5) Using SDP with offer/answer bu= ild into the browser binary is a horribly BAD technical choice (even for SI= P folks) and must be stopped, see: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html

    Short summary: "I don't want to use SDP".  Right?
     


    I too want to understand the rational for keeping something as bad as SDP w= ith offer/answer as the primary mechanism for controlling the media compone= nts and interaction to those component and more importantly, I'd too would = like to open debate to agreeing or not to provide a lower layer API rather than a media negotiation API as= a complete substitute alternative to SDP with offer/answer.

    If we can agree that it's far superior to have a lower level media/RTC comp= onent API rather than a media negotiation API, then we can propose what tha= t API could look like (and there are people who have already have starting = proposals). I'd throw my hat in the ring to propose such and API if necessary as I've written such engines= from scratch before. But I don't want to waste time proposing ore reviewin= g such an API which will be summarily dismissed because people are so stuck= on requiring a media negotiation API built into the browser binary, and specifically SDP with offer/answer = in this case.


    The WG may dislike and reject your proposal, but there's a bit of trut= h to the old mathematically incorrect sports adage "you miss 100% of t= he shots you don't take".


    Anyone who argues that they need/= want that simple SDP media negotiation API must understand that a lower lev= el API would allow a wrapper API to produce the same WebRTC API the have to= day but be built entirely from JavaScript

    That depends on how low-level you go.  If you go too low-level, i= t becomes infeasible to do things correctly and performantly in JavaScript.=
     
    upon a lower level API. Thus they can have their "just add-milk&q= uot; baking API. But those of us who need control of the raw ingredients be= yond the "just add milk" can still innovate.

    -Robin


    &= lt;compose-unknown-contact.jpg>
    = 19 June, 2013 2:49= AM
    Correct my if I'm wrong, but the API already leaves what g= oes over the wire completely up to the JS app.  So we couldn't re-open= a debate of "SDP or not SDP" for the wire format, because there'= s nothing to debate.  We already decided it would be left to the JS to decide.  The only thing left to debate is the AP= I.  

    Or am I wrong?




    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
    &= lt;compose-unknown-contact.jpg>
    = 19 June, 2013 2:34= AM
    Hi,
     
    We need to be very clear what we talk about, or= some people are always going to be confused :)
     
    So, AFAIK, the discussion is about SDP O/A usag= e in the API, only in the API, and nowhere but the API.
     
    Whatever people us on the wire is outside the s= cope.
     
    Right?
     
    Regards,
     
    Christer
     


    Sent from Windows using TouchDown= (www.nitrodesk.com<= /a>)

    -----Original Message-----
    From: Peter Thatcher [    pthatcher@google.com]
    To: Martin Thomson [martin.thomson@gmail.com]
    CC: rtcweb@ietf= .org [rtcweb@ietf.= org]
    Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate t= o be re-opened
    Martin, you're right; that was overly harsh of me.  A= dam, I apologize.  I'll be civil in the future.



    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
    &= lt;compose-unknown-contact.jpg>
    = 19 June, 2013 1:36= AM
    Martin, you're right; that was overly harsh of me.  A= dam, I apologize.  I'll be civil in the future.



    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
    &= lt;compose-unknown-contact.jpg>
    = 18 June, 2013 6:25= PM
    I agree with Peter, except for this bit:

    Adam is much harder to confuse than you think, or than he professes.
    Speaking of burning it all down and starting over. If you want a
    house-related analogy, that's not quite correct. It's refusing to
    build an extension because the old house, while legally fit for
    habitation, is falling down around your ears. Since you only need
    foundations, it's not that big a job (though I'll grant you that it's
    bigger than many people realize, even with that smaller scope).
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
    &= lt;compose-unknown-contact.jpg>
    = 18 June, 2013 6:16= PM
    Adam, I think you're confused.  As Ted pointed out, t= here are two different uses of SDP: 1.  as a control surface, 2. as a = message format for signalling.  SDPNG was trying to replace SDP for #2= .  While I believe this thread was started entirely focused on #1.  So you're talking about different things.

    So far the only time spent on trying to replace or avoid SDP for #1 ha= s been "comment 22", and to a lesser extent the proposal I just m= ade for adding 2 methods to PeerConnection (createLocalStream and createRem= oteStream).   I think it's incorrect to conclude that we should never try to improve #1 just because other in the past fail= ed to replace #2.  They're very different.

    I also don't think we should burn down WebRTC and start over, but desp= ite what some seem to think, we don't have to choose between "burn it = down" and "never improve it".  There are many options o= ther than the two extremes.



    By the way, a gentle reminder: SDP is not the only way to do #2.  = ;I work on a rather large system almost entirely build around Jingle, witho= ut a hint of SDP, and it works just fine.  Much better than SDP would = have, I think.  Just because SDPNG didn't work out doesn't mean there will never be any way other to do signalling t= han SDP.




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

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

    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.= ietf.org/mailman/listinfo/rtcweb
    --_000_AFC6D2DF3C384E2090A7A8A10E667471skypenet_-- From robin@hookflash.com Wed Jun 19 11:05:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFD621F9E17 for ; Wed, 19 Jun 2013 11:05:34 -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=[AWL=-0.143, BAYES_00=-2.599, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTf9qo4rXoov for ; Wed, 19 Jun 2013 11:05:33 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8144F21F9E0B for ; Wed, 19 Jun 2013 11:05:33 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id n10so7026252oag.14 for ; Wed, 19 Jun 2013 11:05:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=IaN+0DnuJYovU4dkjhkqUQBATmqrCMVoJQmb6ut4+us=; b=Ta8RZYgHL+z7B1lXKLqC4BaZF4vo/d7ErpoJDqVaDd551ueZPk+5koOKhzwu4S8nkQ gL1WXtJbnrBpiUNbxzUf6PsvfhoeMC6u/lGyCuGM82kzkuv5gtMgw3ohrKbzctcG6Vde viBNloND0flYk6pAHLrlz9+rwSifvUmcdMsg1cWLD1iWfsuIlveZEL4N9dtvQ5HjzTnV pRVM86BfZzXPlFPlSy/FgSOo68jiC2pmHC0XS0Ui/oQwM5AstWICVAfse57sVA3SVDaF 8b5r3VbmPADbT6RGmOub0d3AqGuF9Kg+mvauGlHOgaxMhLTpBLhFwFPvx8Oeiy7kALVV P7Kg== X-Received: by 10.60.36.226 with SMTP id t2mr2062483oej.6.1371665133054; Wed, 19 Jun 2013 11:05:33 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id r4sm26220139oem.3.2013.06.19.11.05.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 11:05:32 -0700 (PDT) Message-ID: <51C1F2E9.20405@hookflash.com> Date: Wed, 19 Jun 2013 14:05:29 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Peter Thatcher References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070004000807050208050701" X-Gm-Message-State: ALoCoQkt+fcbWJoQvRMMwd34qOb4dt6mRf1yg7vNPAdhhWs0Qg4jeC95GUZVV+fTIwIuYY8pmiGa Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 18:05:34 -0000 This is a multi-part message in MIME format. --------------070004000807050208050701 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Why aren't we using the JavaScript object model for control of components instead of serializing our control requests via SDP/whatever format and hoping that it worked? -Robin > Peter Thatcher > 19 June, 2013 12:49 PM > I asked "is there something that can't be done without sufficient SDP > munging"? You answered "I have something that can be done with > sufficient SDP munging". OK. But do you have something that *can't* > be done with SDP munging? > > If there's nothing that can't be done with SDP munging, then this > whole thread boils down to "give us an API that has the same amount of > control as the current one, but without requiring SDP munging to do > advanced things". And if that's is what is desired, then at least it > can be clear and concise. > > --------------070004000807050208050701 Content-Type: multipart/related; boundary="------------040903010409080908060708" --------------040903010409080908060708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
    Why aren't we using the JavaScript object model for control of components instead of serializing our control requests via SDP/whatever format and hoping that it worked?

    -Robin


    19 June, 2013 12:49 PM
    I asked "is there something that can't be done without sufficient SDP munging"?  You answered "I have something that can be done with sufficient SDP munging".   OK.  But do you have something that *can't* be done with SDP munging?

    If there's nothing that can't be done with SDP munging, then this whole thread boils down to "give us an API that has the same amount of control as the current one, but without requiring SDP munging to do advanced things".  And if that's is what is desired, then at least it can be clear and concise.


    --------------040903010409080908060708 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------040903010409080908060708-- --------------070004000807050208050701-- From matthew.kaufman@skype.net Wed Jun 19 11:05:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EE321F997F for ; Wed, 19 Jun 2013 11:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfagljPAg9ea for ; Wed, 19 Jun 2013 11:05:48 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 5B80921F9E2A for ; Wed, 19 Jun 2013 11:05:47 -0700 (PDT) Received: from BY2FFO11FD007.protection.gbl (10.1.15.202) by BY2FFO11HUB015.protection.gbl (10.1.14.88) with Microsoft SMTP Server (TLS) id 15.0.707.0; Wed, 19 Jun 2013 18:05:46 +0000 Received: from TK5EX14MLTC102.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.707.0 via Frontend Transport; Wed, 19 Jun 2013 18:05:46 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.171]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0136.001; Wed, 19 Jun 2013 18:04:33 +0000 From: "Matthew Kaufman (SKYPE)" To: Peter Thatcher Thread-Topic: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Thread-Index: AQHObEI8XC7enqULikaWynaBYkCsupk76I4AgAACKQCAAB+igIAAApYAgAB4ZYCAABBRgIAAIpyAgAB3lgCAAAaSgIAACJ6AgAAXWqs= Date: Wed, 19 Jun 2013 18:04:32 +0000 Message-ID: <0867CEB4-2983-4B48-92A3-2E96CF74D8CD@skype.net> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_0867CEB429834B4892A32E96CF74D8CDskypenet_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(24454002)(51704005)(51444003)(189002)(377454003)(51856001)(30436002)(81342001)(16406001)(53806001)(69226001)(47736001)(47446002)(46102001)(77096001)(54356001)(74876001)(76796001)(74662001)(49866001)(20776003)(31966008)(59766001)(65816001)(36756003)(6806003)(47976001)(71186001)(50986001)(81542001)(74502001)(33656001)(44976003)(77982001)(79102001)(74706001)(512934002)(74366001)(56816003)(56776001)(16236675002)(54316002)(76482001)(4396001)(63696002)(76786001)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB015; H:TK5EX14MLTC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 08828D20BC Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 18:05:52 -0000 --_000_0867CEB429834B4892A32E96CF74D8CDskypenet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All of what you say below is true, but this is entirely backwards from how = web page authors are supposed to interact with the browser. Imagine if displaying JPEG images in the page were equally possible, if you= wanted to munge a bunch of strings, but otherwise you were out of luck. Matthew Kaufman (Sent from my iPhone) On Jun 19, 2013, at 9:41 AM, "Peter Thatcher" > wrote: On Wed, Jun 19, 2013 at 9:10 AM, I=F1aki Baz Castillo > wrote: Hi Peter, for now just some comments (I agree that more use cases and other considerations must be provided): >> I don't think that the discussion is just about "SDP O/A usage in the >> API". We don't want a replacement for SDP, nor a new representation of >> SDP, nor to deal with blob strings between the JS layer and the WebRTC >> layer. > > > Please at least agree with Christer that this is about the API, not about > the signalling wire format. The API already allows whatever signalling w= ire > format you want, IMHO that is not entirely true. First of all, whichever the signaling protocol is, it must accomplish with SDP O/A semantics (since it must carry a SDP and receive a SDP to establish the communication). API calls must use the SDP O/A, but what goes on the wire doesn't have to b= e. With enough SDP hackery, you can do whatever you want over the wire, in= cluding not use O/A semantics. Second: Indeed the current spec does not mandate what should be sent in the wire. In practice that means we can use SIP over WebSocket, XMPP/Jingle over HTTP, or whatever. But in practice it also means that we must send a SDP in the wire. The SDP blob string can be hex-encoded/escaped/mangled/whatever by the JS app, but the SDP blob string generated by PeerConnection-A should arrive to PeerConnection-B. A sufficiently smart chunk of JS could call setLocalDescription/setRemoteDe= scription with SDP that it completely created itself, and send whatever it = wants over the wire. And since such a SDP is generated by the WebRTC stack and passed to the JS as an unmanageable blob string, the JS app cannot properly deal with it. The JS parse the SDP from createOffer/createAnswer, get the info it needs, = make decisions and then serialize different SDP back down in setLocalDescri= ption/setRemoteDescription. It's terribly ugly, but it works. So, currently WebRTC does not mandate the signaling protocol in-the-wire, but it does mandate the media signaling protocol in-the-wire (you need to pass a working SDP to the remote, sure), something that constrains the signaling protocol itself. It does not mandate SDP over the wire. It's possible to write a JS app tha= t gets everything working with no SDP on the wire. It's anything but prett= y, but it works. > and everything you mention from here on out is just the > API. So please just say to Christer "yes, this is all about the API". I= t > will make the rest of the discussion much more clear. > Ok, this is all about the API :) >> In short we want something like a JS wrapper of the native >> WebRTC API, > > > I work on the WebRTC implementation in Chrome, and I don't know what you > mean by "native WebRTC API". Such a thing does not really exist. The > implementation has three different layers of abstraction, each of which y= ou > might be referring to, but none of them which will give you what you want= . > The highest level uses SDP. The lowest level gives you media bits, but n= o > ICE, SRTP, DTLS, or SCTP. The middle layer gives you all those things > without SDP, but it still uses an abstract offer/answer for transport and > RTP setup (and even has a Jingle implementation on top of that). None of > those give you what you want. The "native WebRTC API" that you want to w= rap > doesn't exist. > Ok, IMHO nobody is still requesting a specific JS API but just > describing the features and capabilities such an API must provide. The > "similar to native WebRTC API" is just a comment to help understanding > what we mean, but of course each browser is free to implement its > native API(s) as it prefers so the "JS wrapper" concept does not make > sense. But you can't say "similar to native WebRTC API" because no such thing exis= ts. You can't be similar to something that doesn't exist :). >> to directly manage media/transport parameters and media >> streams without having to pass a monolithic and unmanageable SDP blob >> between the JS and the WebRTC layer. > > > That boils down to "the same power of the current API, without going thro= ugh > SDP". I think that's a clear requirement. So why don't you just say tha= t? > Would save everyone a lot of reading and misunderstanding. > You are right. >> calls to get the required media parameters, the JS can send them to >> the remote peer in the way it prefers (which may be via a SDP created >> by the JS app, or via an AJAX request for sending codecs/media-types >> info followed by a WebSocket connection for sending ICE candidates one >> by one, or serialized in JSON via a previously open DataChannel >> session... or whatever mechanism available in the Web and browsers). >> > > You already have that. > Can I first send my codecs list, then (once the peer notifies me > codecs compatibility) send the codecs preference order, then my ICE > candidates and later (not just when ICE process terminates) signal the > peer a "OK" message so we both start the multimedia audio/video/data > communication, all of this with the current API? I think so, yes. > (I mean without parsing the SDP blob and splitting it into blob fragments= ). Maybe... I don't know for sure. But generally, anything beyond the most ba= sic uses of the API requires at least some SDP hackery, and advanced uses r= equire a lot. Best regards. -- I=F1aki Baz Castillo > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_0867CEB429834B4892A32E96CF74D8CDskypenet_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    All of what you say below is true, but this is entirely backwards from= how web page authors are supposed to interact with the browser.

    Imagine if displaying JPEG images in the page were equally possible, i= f you wanted to munge a bunch of strings, but otherwise you were out of luc= k.

    Matthew Kaufman

    (Sent from my iPhone)

    On Jun 19, 2013, at 9:41 AM, "Peter Thatcher" <pthatcher@google.com> wrote:




    On Wed, Jun 19, 2013 at 9:10 AM, I=F1aki Baz Cas= tillo <ibc@aliax.net>= ; wrote:
    Hi Peter, for now just some comments (I agree that more use cases and
    other considerations must be provided):




    >> I don't think that the discussion is just about "SDP O/A usag= e in the
    >> API". We don't want a replacement for SDP, nor a new represen= tation of
    >> SDP, nor to deal with blob strings between the JS layer and the We= bRTC
    >> layer.
    >
    >
    > Please at least agree with Christer that this is about the API, not ab= out
    > the signalling wire format.  The API already allows whatever sign= alling wire
    > format you want,


    IMHO that is not entirely true.

    First of all, whichever the signaling protocol is, it must accomplish
    with SDP O/A semantics (since it must carry a SDP and receive a SDP to
    establish the communication).

    API calls must use the SDP O/A, but what goes on the wire doesn't have= to be.  With enough SDP hackery, you can do whatever you want over th= e wire, including not use O/A semantics.
     

    Second: Indeed the current spec does not mandate what should be sent
    in the wire. In practice that means we can use SIP over WebSocket,
    XMPP/Jingle over HTTP, or whatever. But in practice it also means that
    we must send a SDP in the wire. The SDP blob string can be
    hex-encoded/escaped/mangled/whatever by the JS app, but the SDP blob
    string generated by PeerConnection-A should arrive to
    PeerConnection-B.

    A sufficiently smart chunk of JS could call setLocalDescription/setRem= oteDescription with SDP that it completely created itself, and send whateve= r it wants over the wire.  
     
    And since such a SDP is generated by the WebRTC
    stack and passed to the JS as an unmanageable blob string, the JS app
    cannot properly deal with it.

    The JS parse the SDP from createOffer/createAnswer, get the info it ne= eds, make decisions and then serialize different SDP back down in setLocalD= escription/setRemoteDescription.  It's terribly ugly, but it works.
     
    So, currently WebRTC does not mandate the signaling protocol
    in-the-wire, but it does mandate the media signaling protocol
    in-the-wire (you need to pass a working SDP to the remote, sure),
    something that constrains the signaling protocol itself.

    It does not mandate SDP over the wire.  It's possible to write a = JS app that gets everything working with no SDP on the wire.  It's any= thing but pretty, but it works.




    > and everything you mention from here on out is just the
    > API.  So please just say to Christer "yes, this is all about= the API".  It
    > will make the rest of the discussion much more clear.

    > Ok, this is all about the API :)

    >> In short we want something like a JS wrapper of the native
    >> WebRTC API,
    >
    >
    > I work on the WebRTC implementation in Chrome, and I don't know what y= ou
    > mean by "native WebRTC API".  Such a thing does not rea= lly exist.  The
    > implementation has three different layers of abstraction, each of whic= h you
    > might be referring to, but none of them which will give you what you w= ant.
    > The highest level uses SDP.  The lowest level gives you media bit= s, but no
    > ICE, SRTP, DTLS, or SCTP.  The middle layer gives you all those t= hings
    > without SDP, but it still uses an abstract offer/answer for transport = and
    > RTP setup (and even has a Jingle implementation on top of that).  = ;None of
    > those give you what you want.  The "native WebRTC API" = that you want to wrap
    > doesn't exist.

    > Ok, IMHO nobody is still requesting a specific JS API but just
    > describing the features and capabilities such an API must provide. The=
    > "similar to native WebRTC API" is just a comment to help und= erstanding
    > what we mean, but of course each browser is free to implement its
    > native API(s) as it prefers so the "JS wrapper" concept does= not make
    > sense.

    But you can't say "similar to native WebRTC API" because no such thing exists. =  You can't be similar to something that doesn't exist :).


    >> to directly manage media/transport parameters and media
    >> streams without having to pass a monolithic and unmanageable SDP b= lob
    >> between the JS and the WebRTC layer.
    >
    >
    > That boils down to "the same power of the current API, without go= ing through
    > SDP".  I think that's a clear requirement.  So why don'= t you just say that?
    > Would save everyone a lot of reading and misunderstanding.

    > You are right.



    >> calls to get the required media parameters, the JS can send them t= o
    >> the remote peer in the way it prefers (which may be via a SDP crea= ted
    >> by the JS app, or via an AJAX request for sending codecs/media-typ= es
    >> info followed by a WebSocket connection for sending ICE candidates= one
    >> by one, or serialized in JSON via a previously open DataChannel >> session... or whatever mechanism available in the Web and browsers= ).
    >>
    >
    > You already have that.

    > Can I first send my codecs list, then (once the peer notifies me
    > codecs compatibility) send the codecs preference order, then my ICE > candidates and later (not just when ICE process terminates) signal the=
    > peer a "OK" message so we both start the multimedia audio/vi= deo/data
    > communication, all of this with the current API?

    I think so, yes.

    > (I mean without parsing the SDP blob and splitting it into blob fragme= nts).

    Maybe... I don't know for sure.  But generally, anyt= hing beyond the most basic uses of the API requires at least some SDP hacke= ry, and advanced uses require a lot.


    Best regards.




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

    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.= ietf.org/mailman/listinfo/rtcweb
    --_000_0867CEB429834B4892A32E96CF74D8CDskypenet_-- From pthatcher@google.com Wed Jun 19 11:08:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7489A21F9E31 for ; Wed, 19 Jun 2013 11:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aVJ+GYlaU8Z for ; Wed, 19 Jun 2013 11:08:04 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by ietfa.amsl.com (Postfix) with ESMTP id A9B9021F9E62 for ; Wed, 19 Jun 2013 11:08:03 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id y14so5387531pdi.16 for ; Wed, 19 Jun 2013 11:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/GbIUtR2CzQWKsPvVh2P65bifK3QA6kRziKMyoL99UA=; b=GXpkWMmOuuJsgTg73w57nSLDC30oCGCjoDliiAGTFgkhwLiLiYqaLgvYCk8pH0POFw 0XM2M5PvnTg4MzULhF9gkeP6966tryGCfzwVAZkex8hJA6QiZoRNeCsMzDuUEiPg2Vo7 r8L21eGInKbIG6Itl6BvGmT+p/M5m7IiahTSViKEZT3YF5p+COrk8vDHVW238nUDxYql W1tLYtT3fFpu91YOgSWm3XHE4MJnGTp/qBK2sq8B714BDK6ngGRRgtgjoOnZTKvFygry AlnsO7S12s41np4L70cOtMDFynwp7mzQYzSMh+uzeAxPSaDnqu9gLlF2G5qufGDJeDHl jCQw== 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=/GbIUtR2CzQWKsPvVh2P65bifK3QA6kRziKMyoL99UA=; b=Cgo/Yml9B+PHWLX/fCiTC9ppuK9AZeQEuWVDCycYQrn9WvR7EXv9aovnPFWg/3rSyJ vJd/J+Y8LL2j1rdzi7b5+cnC0BgYm7qohrPULzcrDNjmHsSrb/ZyBV72qt/3uvj3XK3v hoe0lagaSIwdKnXt4U3t+RCWOi1zGn8juZusXs6Nl1bfbLLdHJrLaR5eiN5b1tc33Vpa zP+kQcTCCIglGRxlOxqRSMFQEMgshEVaR5uQMfplUSJPu2DSHjGq+y1bdNjoPZ037DoC zoG+J84zMYEjlts24RCv66nC8V4NAhQO8Z9bXFMjxUSXb016SgYDd7bfQJ2wPCIgleHr aIgw== X-Received: by 10.68.163.165 with SMTP id yj5mr3946354pbb.141.1371665283428; Wed, 19 Jun 2013 11:08:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 11:07:22 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Wed, 19 Jun 2013 11:07:22 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b86d556f84b8404df85b59d X-Gm-Message-State: ALoCoQneb7mtYQHXT0wHjDL2VDW39BwdWh2CIg3rF5n7/QW3TJ6HyscYo/lqiukTVRrYTTHvEc/oTuq9uRv0wPAywzAsacGmBFwwerM1DyTqrZ9jz7G1BkaDVzpVY/P+59MKgP9jWdqoBB7dAvJ2N04nEL58xtLvhm3I6B+TvA4vBWTye4Bhpyhy+SXXdfE4DPLvLcwQVRme Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 18:08:09 -0000 --047d7b86d556f84b8404df85b59d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That is precisely the argument that will be used against you to do everything with SDP and only SDP. On Wed, Jun 19, 2013 at 10:45 AM, I=C3=B1aki Baz Castillo w= rote: > 2013/6/19 Peter Thatcher : > > I don't think it's removal of SDP that you want. I think what you want > is a > > way to use the API without using SDP. If the SDP is still there, but y= ou > > don't have to use it, you're still happy, right? > > AFAIK no API in the world provides two ways to do the same, or at > least, no API provide them with the same "quality" and "affection". > Duplicating the work does not seem a long-term solution IMHO. > > But I may be wrong :) > > > -- > I=C3=B1aki Baz Castillo > > --047d7b86d556f84b8404df85b59d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    That is precisely the argument that will be used against y= ou to do everything with SDP and only SDP.

    On Wed, Jun 19, 2013 at 10:45 AM, I=C3=B1a= ki Baz Castillo <ibc@aliax.net> wrote:
    2013/6/19 Peter Thatcher <pthatcher@google.com>:
    > I don't think it's removal of SDP that you w= ant. =C2=A0I think what you want is a
    > way to use the API without using SDP. =C2=A0If the SDP is still there,= but you
    > don't have to use it, you're still happy, right?

    AFAIK no API in the world provides two ways to do the same, or at
    least, no API provide them with the same "quality" and "affe= ction".
    Duplicating the work does not seem a long-term solution IMHO.

    But I may be wrong :)


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

    --047d7b86d556f84b8404df85b59d-- From pthatcher@google.com Wed Jun 19 11:13:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993E621F9E80 for ; Wed, 19 Jun 2013 11:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifXxklSHTYX7 for ; Wed, 19 Jun 2013 11:13:59 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E3BD121F9E6C for ; Wed, 19 Jun 2013 11:13:58 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc8so5341905pbc.18 for ; Wed, 19 Jun 2013 11:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ShZelHW2M/F4uP19Nn7+kykuI6tPQizkq8feLJFXCtQ=; b=G+7VwLtgPs2bMRTGXweejR10qRLXgnZ5WtZj+mv/GcwNh0IZJV+8rerOqO0uLyg5Gq nnSDwwcjJdW2gzUZF/l4W5khKbbhf3ACrxuIhD/mmnY0XT+mDxiJX/U8M1uZxPbHG1VA qmREiIuPGMb2b69gr1zIkRSiF9NlOf+hQP1uqBUiUIv/6YnD7iXLhPC5wd80D7C9rinc 2f3ZFJmFaXu/i9DPVxc369Ety4lthefTStq/704cxxSLXlyz7IvKqx1r1VxZHry65wyb 9aRZNKNWByNoDNjR+aDpeGKG8fUSuif/8MO7CmJdsNtuCnSof5wobZy23Qo5ew+5I8L5 Ku7Q== 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=ShZelHW2M/F4uP19Nn7+kykuI6tPQizkq8feLJFXCtQ=; b=WmFp0xV/BgL6GXktDQZlruxN8ddenFq5Fob9i/35LqZKlYo7SZhVQj5pgCPVs+pxUD PTPleAib6hU6w8YV7Rhgz6GPu/408XbjqaBcPLsb0q43AZBdhBEfw2u0FbW78RkRiGdP sgrynCO9orH4V3Dr6yiD/IGiKS5ous8goakUB+4AbrMCaiYjSnXda2Oo1vxBvQxKrE42 NvY0Gig9hAsWHX5Hag4Qojo/JNH9HGUiaW2KYrYJtY033jo9bgCmBPv8lAN8EeQ4RZAC P1pVgDU9tw4wCmYR+SOgz3DD91X8cFtSwDrNQdaflVDW2dIWXZVmNH0GzRIkChr5SSZM iesg== X-Received: by 10.66.83.7 with SMTP id m7mr8001486pay.150.1371665638643; Wed, 19 Jun 2013 11:13:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 11:13:18 -0700 (PDT) In-Reply-To: References: <51C1D55D.6040905@hookflash.com> From: Peter Thatcher Date: Wed, 19 Jun 2013 11:13:18 -0700 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=f46d042ef48d24784504df85cb1a X-Gm-Message-State: ALoCoQkrPO9g+4H69Mh3MdGtO096x/0JL06cNazvC/amplKGD9toFW3qBGtL3zOxbuUHUmFtcUDMiq7HnoGiVYn3Cy+HKLcKwrY/IFYVEzr5aF05qJclQ3A5OipqnkfpTFno072OqJDk1EP0YCDzY8Hi6qPXpVV2SSMeUbBuK1nsv++2Jb5xgug3g/vXViFMfjyBk52Jft5d Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 18:13:59 -0000 --f46d042ef48d24784504df85cb1a Content-Type: text/plain; charset=UTF-8 On Wed, Jun 19, 2013 at 10:17 AM, Roman Shpount wrote: > > On Wed, Jun 19, 2013 at 1:01 PM, Peter Thatcher wrote: > >> There are two separate things here: 1. adding to the current API to >> allow JS to avoid SDP. 2. removing what is there that uses SDP. >> >> You're saying you want to add new things and remove olds things. But I >> think really you just want to add what you want, and it would matter if >> what you didn't want to use were still there. So I think it's better to >> talk about what we can add to the API to make it easier to work with rather >> than talk about starting from scratch. Removing the existing pieces would >> not be nearly as easy as you make it sound. >> >> > Let me approach this from a different angle: Do you think it is possible > to create an interoperable, re-implementable API based on SDP? Currently, > SDP format changes with each release in a way that breaks both SDP mungling > code and external connected end-points. What I want is an API that does not > rely on a string blog to encapsulate every new feature. New features should > be implemented via new methods. I need something standard enough that I can > have a stable application implementation. As it stands right now WebRTC > will not pass the W3C standard process, so we need either spend a lot more > time tying down SDP or create the API that avoids it. I think you > underestimate the amount of effort needed to finalize SDP. At the current > rate I see this process taking another 2-3 years. It also creates a > dependency on MMUSIC, which has its own priorities. So, if you want a > realistic API standard, you need to look for a way around SDP. > I think an API that allows JS to not have to do SDP munging it much better. That's why I proposed a step in that direction. > > Also, using SDP just for transport is wasteful. All you need are 3 string > parameters which can be passed individually without parsing/creating a > string blog which carries another 5 things that carry no meaning for > transport (version, origin, etc). > Agreed. I'd rather not have it, but I'm trying to make incremental improvements here. I don't want to blow up everything and start from scratch. > _____________ > Roman Shpount > > --f46d042ef48d24784504df85cb1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Wed, Jun 19, 2013 at 10:17 AM, Roman Shpount &= lt;roman@telurix.com= > wrote:

    On Wed, Jun 19, 2013 at 1:01 PM, Peter Thatcher <ptha= tcher@google.com> wrote:
    There are two separate things here: 1. =C2=A0adding to the= current API to allow JS to avoid SDP. =C2=A02. =C2=A0removing what is ther= e that uses SDP. =C2=A0

    You're saying you want to add new things and remove= olds things. =C2=A0But I think really you just want to add what you want, = and it would matter if what you didn't want to use were still there. = =C2=A0So I think it's better to talk about what we can add to the API t= o make it easier to work with rather than talk about starting from scratch.= =C2=A0Removing the existing pieces would not be nearly as easy as you make= it sound.


    Let me approach this from a different angle: Do you think it is possible= to create an interoperable, re-implementable API based on SDP? Currently, = SDP format changes with each release in a way that breaks both SDP mungling= code and external connected end-points. What I want is an API that does no= t rely on a string blog to encapsulate every new feature. New features shou= ld be implemented via new methods. I need something standard enough that I = can have a stable application implementation. As it stands right now WebRTC= will not pass the W3C standard process, so we need either spend a lot more= time tying down SDP or create the API that avoids it. I think you =C2=A0un= derestimate the amount of effort needed to finalize SDP. At the current rat= e I see this =C2=A0process taking another 2-3 years. It also creates a depe= ndency on MMUSIC, which has its own priorities. So, if you want a realistic= API standard, you need to look for a way around SDP.

    I think an API that allows JS to not= have to do SDP munging it much better. =C2=A0That's why I proposed a s= tep in that direction.
    =C2=A0

    Also, using SDP just for transport is wasteful. All you= need are 3 string parameters which can be passed individually without pars= ing/creating a string blog which carries another 5 things that carry no mea= ning for transport (version, origin, etc).

    Agreed. =C2=A0I'd rather not hav= e it, but I'm trying to make incremental improvements here. =C2=A0 I do= n't want to blow up everything and start from scratch.
    =C2=A0=
    _____________
    Roman = Shpount
    =C2=A0

    --f46d042ef48d24784504df85cb1a-- From matthew@matthew.at Wed Jun 19 11:16:41 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8693521F9B12 for ; Wed, 19 Jun 2013 11:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.081 X-Spam-Level: X-Spam-Status: No, score=-1.081 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcaS1sMI+rx1 for ; Wed, 19 Jun 2013 11:16:36 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826FE21F9E1A for ; Wed, 19 Jun 2013 11:16:36 -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 1D7C8250041 for ; Wed, 19 Jun 2013 11:16:36 -0700 (PDT) Message-ID: <51C1F587.3080506@matthew.at> Date: Wed, 19 Jun 2013 11:16:39 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51C1D55D.6040905@hookflash.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 18:16:41 -0000 On 6/19/2013 11:13 AM, Peter Thatcher wrote: > > > > > Agreed. I'd rather not have it, but I'm trying to make incremental > improvements here. I don't want to blow up everything and start from > scratch. > My position is that there are no incremental improvements possible without removing the O/A state machine from the browser. The whole point of JavaScript and the ability to manipulate objects is so that programmers can make the browser do things. Offer/Answer perverts that so significantly as to prevent reasonable JavaScript programming practice. Matthew Kaufman From matthew@matthew.at Wed Jun 19 11:18:23 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C3321F9E98 for ; Wed, 19 Jun 2013 11:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.197 X-Spam-Level: X-Spam-Status: No, score=-1.197 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci3RNnSWhVUI for ; Wed, 19 Jun 2013 11:18:18 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447AF21F9B12 for ; Wed, 19 Jun 2013 11:18:18 -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 38864250041; Wed, 19 Jun 2013 11:18:17 -0700 (PDT) Message-ID: <51C1F5ED.9090308@matthew.at> Date: Wed, 19 Jun 2013 11:18:21 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Robin Raymond References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> In-Reply-To: <51C1F2E9.20405@hookflash.com> Content-Type: multipart/alternative; boundary="------------070301030208050201040101" Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 18:18:23 -0000 This is a multi-part message in MIME format. --------------070301030208050201040101 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/19/2013 11:05 AM, Robin Raymond wrote: > > Why aren't we using the JavaScript object model for control of > components instead of serializing our control requests via > SDP/whatever format and hoping that it worked? > That's a great question. Have you read the CU-RTCWEB proposal? Is it any closer to what you imagined the RTCWEB API might be? Matthew Kaufman --------------070301030208050201040101 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
    On 6/19/2013 11:05 AM, Robin Raymond wrote:

    Why aren't we using the JavaScript object model for control of components instead of serializing our control requests via SDP/whatever format and hoping that it worked?

    That's a great question. Have you read the CU-RTCWEB proposal? Is it any closer to what you imagined the RTCWEB API might be?

    Matthew Kaufman
    --------------070301030208050201040101-- From pthatcher@google.com Wed Jun 19 11:26:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0A621F9E11 for ; Wed, 19 Jun 2013 11:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNXIzurpM0uw for ; Wed, 19 Jun 2013 11:26:56 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8777F21F9CFA for ; Wed, 19 Jun 2013 11:26:56 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp16so5387853pbb.28 for ; Wed, 19 Jun 2013 11:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ppDRZv9b3lDdaTYIX0fsBmF/s0bX0F6lr2XAR22euHM=; b=f4rA5mPdXqmQj1HOMUe9fNnW8uVn8A0VcfbCy8jJ2oUkkm3cANLy05NSq63WMl3IhR IeFBiLjuaTL28RujoTjDX+Aprb4yVz85abjya6sMfVZVJIQlqBvticGYPNz0atQmYaNE dOH+EmDpQDP06IUfiNt0sIxm2YZOF+C2+QMEkzeDeXJDOqSvtZGbwuyRtS2jsxCzedmL EZHDeRVhKZgCPjdxXXCJZRmdzHRH0GJjD7eKb6dd1owtKO7Kx7R0MMPz6P5Jb/1VBTvk wkELKMk0NTRz1gTcUbuH3F/CI/WjJxnHW7vz6ZYLE6O7xLdwciA+FT/gwb90Mbhn5MHE PTjQ== 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=ppDRZv9b3lDdaTYIX0fsBmF/s0bX0F6lr2XAR22euHM=; b=hThiISI6ucQN5VHFIoBQyXkE96aJdxojD4XTaDts2QaA1gCSbhL/IVcngtIJGPBYAt CgkXSb4UBjvdBnhycE9WtxguGGczZOf1iif6hxx0ciU8QVlmtblKDx1Vadqpi7ai7/Ir Yxm4irHLLF5cValfGCJZFHPrDZOxhpIG6RRY7ZHJGsGFeTn8yclxdVtxJ0djhr1CFfny WWc9kXpI4LEqe7Khn64xGei3ux8MWzna4oEx/WAvyLbMBNdNf/+I8rz+S97L99O3SE0X MtksugmtBG3HYwT90yCOG+mVelBvhcXoPww0yto/17ilCz0EMCnNV6m/Eb0Z4Vk1sWmC xwZQ== X-Received: by 10.68.213.231 with SMTP id nv7mr4100336pbc.70.1371666416210; Wed, 19 Jun 2013 11:26:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 11:26:15 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Wed, 19 Jun 2013 11:26:15 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=e89a8f923c7a7d40ff04df85f950 X-Gm-Message-State: ALoCoQlrzmT1qH542DFSJX3HUuKdW0gTwZRyT/Grokrh84y9zKzl25OSVCVQzkF9HaY+NMmTOK8vsxkCpBtcHH7RPt/8QaFOrnm+pH6TpzJ279TVD7wN4g2e9cxIOzXIGbPw07vylKBfUJMrt4t+PHKMQZsGslzYBda1EmwFOce1UKYUkbO5klPZDCv8jcmLfP5gbP+g80r8 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 18:26:57 -0000 --e89a8f923c7a7d40ff04df85f950 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 19, 2013 at 10:46 AM, Martin Thomson wrote: > On 19 June 2013 08:15, Peter Thatcher wrote: > > Unfortunately, Microsoft's input seems to be "our way or the highway" > > The good thing about this forum is that correcting gross > misrepresentation is as easy as it is to propagate it. > I'll happily be wrong about my representation of Mircosoft's standpoint, but Matthew just said "My position is that there are no incremental improvements possible without removing the O/A state machine from the browser." That's pretty hardline, with no room for compromise. But to be fair, I retract my comment of "Microsoft's input seems to be 'our way or the highway'" and would like to replace it with "Microsoft's input seems to be 'no incremental improvements without removing O/A from the browser'". How's that? > > Microsoft's input is that Offer/Answer is difficult to remove without > also removing a reliance on SDP at the same time. CU-RTC-Web is a > demonstration of one solution to that problem that we believe is > workable. That proposal was input, not ultimatum. We'd be happy to > consider other alternatives, but we don't believe that any attempt > that retains both O/A and SDP to be a worthwhile step. > I'm fine with the goal of avoiding SDP and O/A. My proposal that started this thread does just that for media streams (but not transports). It's the "no incremental improvements" part that I have issue with. I believe we can do this with incremental improvements. > > The proposals I've seen for incremental refinement don't successfully > avoid the SDPNG trap. Most increase the API surface area, often > dramatically, which burdens both browser implementations and API > users. I personally don't believe it to be possible to avoid this > problem without tackling the core problem, which unfortunately > requires a little bit of courage. > I disagree. My proposal eliminates at least half of the pain by only adding two methods to PeerConnection (and a few dictionaries). That does add some burden to the browser, but relieves a lot of burden from the API users. --e89a8f923c7a7d40ff04df85f950 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Wed, Jun 19, 2013 at 10:46 AM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
    On 19 June 2013 08:15, Peter Thatcher &l= t;pthatcher@google.com> wrot= e:
    > Unfortunately, Microsoft's input seems to be "our way or the = highway"

    The good thing about this forum is that correcting gross
    misrepresentation is as easy as it is to propagate it.

    I'll happily be wrong about my representation of Mircos= oft's standpoint, but Matthew just said "My position is that ther= e are no incremental improvements possible without removing the O/A state m= achine from the browser." =C2=A0That's pretty hardline, with no ro= om for compromise. =C2=A0

    But to be fair, I retract my comment of "= Microsoft's input seems to be= 'our way or the highway'" and would like to replace it with= =C2=A0
    =C2=A0"Microsoft's= input seems to be 'no incremental improvements without removing O/A fr= om the browser'". =C2=A0How's that?
    =C2=A0

    Microsoft's input is that Offer/Answer is difficult to remove without also removing a reliance on SDP at the same time. =C2=A0CU-RTC-Web is a
    demonstration of one solution to that problem that we believe is
    workable. =C2=A0That proposal was input, not ultimatum. =C2=A0We'd be h= appy to
    consider other alternatives, but we don't believe that any attempt
    that retains both O/A and SDP to be a worthwhile step.

    I'm fine with the goal of avoiding SDP and O/A. =C2=A0M= y proposal that started this thread does just that for media streams (but n= ot transports).

    It's the "no incremental improvements" pa= rt that I have issue with. =C2=A0I believe we can do this with incremental = improvements.

    =C2=A0

    The proposals I've seen for incremental refinement don't successful= ly
    avoid the SDPNG trap. =C2=A0Most increase the API surface area, often
    dramatically, which burdens both browser implementations and API
    users. =C2=A0I personally don't believe it to be possible to avoid this=
    problem without tackling the core problem, which unfortunately
    requires a little bit of courage.

    I disagree. =C2=A0M= y proposal eliminates at least half of the pain by only adding two methods = to PeerConnection (and a few dictionaries). =C2=A0That does add some burden= to the browser, but relieves a lot of burden from the API users.

    --e89a8f923c7a7d40ff04df85f950-- From hadriel.kaplan@oracle.com Wed Jun 19 11:28:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6577B21F9E46 for ; Wed, 19 Jun 2013 11:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p97hu50dqzTi for ; Wed, 19 Jun 2013 11:28:02 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0869821F9CFA for ; Wed, 19 Jun 2013 11:28:01 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5JILeaG003912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jun 2013 18:21:41 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5JIRvgp027865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 18:27:58 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5JIRvQ7015644; Wed, 19 Jun 2013 18:27:57 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Jun 2013 11:27:57 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51C02EE8.5070809@ericsson.com> Date: Wed, 19 Jun 2013 14:27:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 18:28:07 -0000 On Jun 18, 2013, at 5:56 AM, Magnus Westerlund = wrote: >>> If you want to discuss this, write a draft describing how how your=20= >>> additional keying is to be integrated, what the pro and cons of it. >>> That will enable direct discussion of a proposal. The WG clearly >>> are opinionated on this matter, but apparently don't have energy to >>> produce proposals. >>=20 >> There *are* drafts.=20 >> http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00=20 >> http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 There >> are even powerpoint slides, sent to the chairs the last time this >> meeting almost happened but didn't. >=20 > One of those drafts has been expired since February I would like to > point out. You're just messing with me right? You're pointing out the drafts are = old, in response to a complaint the meeting's been delayed multiple = times?? Might it be the drafts are old because the meeting's been = delayed multiple times?!? -hadriel From pthatcher@google.com Wed Jun 19 11:36:20 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DBF21F9CD1 for ; Wed, 19 Jun 2013 11:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMh6NZUftHA4 for ; Wed, 19 Jun 2013 11:36:20 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2994821F9931 for ; Wed, 19 Jun 2013 11:35:59 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id um15so5346670pbc.38 for ; Wed, 19 Jun 2013 11:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wmfEnt9Kzs0mktpz8ckPDZAVulEayRRsETV/JfE/swI=; b=ADcco3wkT/1CZWGljA/S/63FhTmYUcPJEV1+P73SadabC6Ah2qxYbUsN9STflzf2Of greAORhB6F+xxSYpv/juGXI6SrK8/Pi+dzZ3zIANelYqN8LZESXwRsegLKRnE92FKAR2 APINu3Rl0QlF+Pjr4uFn80sV6brCHEQqfRnecgHPCOo7Bv/EbJD5JRzv2pPR16NSYdGN J9ddKmDG8jyLMLywK6g9c6pu/uYPNaichyl8w0FZCRDXmHkGAj8+iIUBthgXO9xWB4PE Ui6FfiwB1JVUemjb3hi9g7IZOeW8v3ObRgp6307RwNTUfh19WpuHkkX4oJWLy0yZAAVy FoCA== 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=wmfEnt9Kzs0mktpz8ckPDZAVulEayRRsETV/JfE/swI=; b=nc0pg1pWr/nd1y2+t6X8Y0e12pdLlrEPSYkzhZ27AvDEsiK+dFNQGaV4gFYMmAu9VX nC/pBQ9koNOEsDegNsZP0PXJ9FU49GxlTHvEvzHqLBvmMuwKOmFbZnh8B0C972z7Ba3c PP2AAziaPEVGM3nMcdPM6tTDcyB5g/QhB7xGp02YhArjEq3tbR65JYOAZWSji3pUThkI NsrIiDYcu2mejwpS66R6G3qfnQvncspbUpGdhmonk4ubfcGDvbzYFOpjS40jIx19QkJs w7KSGZJM5T9PZF5ssC0kyQdgQJ8ABEuTlhqQcAci8wARETUka3EnZ9MbdW1QbavEws4M rolw== X-Received: by 10.66.83.7 with SMTP id m7mr8081399pay.150.1371666958838; Wed, 19 Jun 2013 11:35:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 11:35:18 -0700 (PDT) In-Reply-To: References: <51C1D55D.6040905@hookflash.com> From: Peter Thatcher Date: Wed, 19 Jun 2013 11:35:18 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=f46d042ef48dd4ff0d04df8619c0 X-Gm-Message-State: ALoCoQmjQeBUR+wv79JjDIVYRoWAsiliHtV5VpgXaQHuuCPYmQ2aRC1jI0gB7x4FaxTYdIGlN15udC8uBNKRJRBbvSNkSZS3uh32XUoAazZ2decyfuGQITagALrZ3uWtHFnYKTaHT0TWD70sFh5z29jDabDGgE62fH0xGnpj36Onv5R7WVL1nirH1XgLQQNvksPUxZST98dz Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 18:36:21 -0000 --f46d042ef48dd4ff0d04df8619c0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 19, 2013 at 10:20 AM, I=C3=B1aki Baz Castillo w= rote: > 2013/6/19 Peter Thatcher > > > You don't need a lower level API. SDP munging can get you what you > need. But what you want is to not have to do SDP munging. > > > > My proposal is to add two methods to PeerConnection that, if optionally > used by JS, will give you what you want for media streams: the ability to > control what is sent and received without SDP munging. It does not, > however, relieve you from SDP munging on the transport side. But as I've > pointed out, that's limited to about 10 lines of SDP, so at least it's mu= ch > less SDP munging. Later, once could consider more simple additions that > reduce the need for SDP munging further. > > > You base your proposal on the fact that SDP is here forever and must > be used in WebRTC, and then propose some new API methods along with > *lot* of SDP JS parsing/mangling/hackery to mitigate the API > limitations. > Not quite. I base my proposal on the fact that you can currently do everything via SDP mangling, and I propose a simple addition that would allow getting rid of a lot of that SDP munging. There is still some, which could theoretically be addressed with more future additions, but at least the munging is greatly reduced with my proposal. I also assume that blowing up everything and started over without SDP in the browser isn't going to fly with the WG. I'd be happy to be proven wrong, but I'm trying to be realistic. > > While it could be the best we have for now, IMHO it is still a hack or > workaround to just circumvent the real problem and the real > limitation. > There are two parts to the real problem: transports and streams. My proposal solves one of them and leaves the other for future improvement. I thing it's better than just a hack or circumvention. > Things can be done much better if we remove SDP from the equation. I won't disagree, but I don't think it's realistic with the WG to remove SDP from the API. I think the best we can get is to allow SDP to choose wether to use SDP or not. Choose your battles. > > > Best regards. > > > > -- > I=C3=B1aki Baz Castillo > > --f46d042ef48dd4ff0d04df8619c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Wed, Jun 19, 2013 at 10:20 AM, I=C3=B1aki Baz Castillo <ibc@aliax.n= et> wrote:
    2013/6/19 Peter Thatcher &= lt;pthatcher@google.com>

    > You don't need a lower level API. =C2=A0SDP munging can get you wh= at you need. =C2=A0But what you want is to not have to do SDP munging.
    >
    > My proposal is to add two methods to PeerConnection that, if optionall= y used by JS, will give you what you want for media streams: the ability to= control what is sent and received without SDP munging. =C2=A0It does not, = however, relieve you from SDP munging on the transport side. =C2=A0But as I= 've pointed out, that's limited to about 10 lines of SDP, so at lea= st it's much less SDP munging. =C2=A0Later, once could consider more si= mple additions that reduce the need for SDP munging further.


    You base your proposal on the fact that SDP is here forever and must<= br> be used in WebRTC, and then propose some new API methods along with
    *lot* of SDP JS parsing/mangling/hackery to mitigate the API
    limitations.

    Not quite. =C2=A0I base my= proposal on the fact that you can currently do everything via SDP mangling= , and I propose a simple addition that would allow getting rid of a lot of = that SDP munging. =C2=A0 =C2=A0There is still some, which could theoretical= ly be addressed with more future additions, but at least the munging is gre= atly reduced with my proposal.

    I also assume that blowing up everything and started ov= er without SDP in the browser isn't going to fly with the WG. =C2=A0I&#= 39;d be happy to be proven wrong, but I'm trying to be realistic.
    =C2=A0

    While it could be the best we have for now, IMHO it is still a hack or
    workaround to just circumvent the real problem and the real
    limitation.
    =C2=A0
    There are two parts t= o the real problem: transports and streams. =C2=A0My proposal solves one of= them and leaves the other for future improvement. =C2=A0I thing it's b= etter than just a hack or circumvention.


    Things can be done much better if we remove SDP from the equation.=C2=A0

    I won't disagree, but I don't think i= t's realistic with the WG to remove SDP from the API. =C2=A0I think the= best we can get is to allow SDP to choose wether to use SDP or not. =C2=A0= Choose your battles.
    =C2=A0


    Best regards.



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

    --f46d042ef48dd4ff0d04df8619c0-- From pthatcher@google.com Wed Jun 19 11:41:13 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31CB21F99F0 for ; Wed, 19 Jun 2013 11:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzcA6Jz8mRKv for ; Wed, 19 Jun 2013 11:41:13 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 21B2A21F997F for ; Wed, 19 Jun 2013 11:41:13 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc8so5363780pbc.32 for ; Wed, 19 Jun 2013 11:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NgZ8CXO03GQVnxpW8VPyB1Z4RO0l+GJORndF5h3UMfQ=; b=MyKg6UARvDVnt/mtLFFIbDEudn+ApXNHMcwpMUMvseI9czx8n2Nsm0GO6MFms6KDOy 4Bmq55ZRdz3ys7pCdPT0qKs1LpqIkiEO0Z5Go915fQCfSiRzC37zV+ctknMZaLZ04J9P lRSKZVpAT7RtduoFq/Y7RKiGQ5eKCmHR0PsS2gPktJ48xy/Vhuf9HeEPcvALTcT6T9Uy xjN33nfXu40SxvxzJY9dvczLYlN0kGjr9O0HMX7cY2AJgNk4aDfsiq57kCAP583Htbnh GG6G1OnfT4DWfp8LOzmJ7cBV+Jx/XLLgSgT9+MvF53w3JUn/9/ysVR1VBbr4YzA2aiV9 htkA== 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=NgZ8CXO03GQVnxpW8VPyB1Z4RO0l+GJORndF5h3UMfQ=; b=R/Gw0AYBj5WGGPuD1XDDbwow+BWBEahreTrSkHmrqbjCXM0b0eGloPdqmsoMWtYm8S J37Q8C8dx4Q7BJS6wYqF3+2zMLjIplujZZP4NFkwm/5IkXv/03VqeHGEPivUMtTmERz5 vmYZRHSBawxkY6ANkkeR9/RcaJXwSdImaUhE88P7vWRJEoHfcBIjhsNTcGQpAZGNSRqm dq/nbYyG3zCvLfs8+Cpihk25bOEXUWbru/XTGsQ9qrZKC0m745FnS5dZt7aIMNxKIdOa gy3lfvPkjgZRowb4vQUPxsZujpcCrucSrh1kUh9i9ogV0WkGVFWrSs3IU4DT4B6CcQBh 6AaA== X-Received: by 10.68.19.72 with SMTP id c8mr3985712pbe.219.1371667272782; Wed, 19 Jun 2013 11:41:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 11:40:31 -0700 (PDT) In-Reply-To: <51C1EE64.1010109@matthew.at> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1EE64.1010109@matthew.at> From: Peter Thatcher Date: Wed, 19 Jun 2013 11:40:31 -0700 Message-ID: To: Matthew Kaufman Content-Type: multipart/alternative; boundary=bcaec53af13a8b6f0604df862cc7 X-Gm-Message-State: ALoCoQkWe7B7i3JBB+GYJ2x+p1ovwq8ZTIqbC7G1cTpMEiiTPDKdMNuX4hr2GSXHgE+D8M24e5MlkR8n4Iac9pEzEbM9//Pm9/k1RpJP1QIl3Aspyew3PdL/K0ymV1LF7hW9Q1nd0M4wMaZBTpZYNg6jL+Mckz5YFcBXMl/H7O18pAz1cPrie+KIFvh21fPfe5a+pxWOqq12 Cc: "" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 18:41:13 -0000 --bcaec53af13a8b6f0604df862cc7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 19, 2013 at 10:46 AM, Matthew Kaufman wrote= : > On 6/19/2013 10:35 AM, Peter Thatcher wrote: > > > > > On Wed, Jun 19, 2013 at 10:27 AM, I=C3=B1aki Baz Castillo = wrote: > >> 2013/6/19 Peter Thatcher : >> > Of course. That's why I made a proposal that attempts to lessen the >> pain >> > (the NoPlan JS API). I'm trying to help you :). >> >> And don't you agree that the pain is even less if we entirely remove SD= P? >> >> > I don't think it's removal of SDP that you want. I think what you want > is a way to use the API without using SDP. If the SDP is still there, bu= t > you don't have to use it, you're still happy, right? > > > I want the offer/answer state machine to go away. I don't like an API tha= t > requires me to fight with it to get it to do what I want, no matter what > kinds of things I put in (SDP, JSON, wahtever). > > Are you demanding both adding what you want and removing what is there? Or, if you could add everything you want, but leave what is currently there (SDP O/A), would you be content? Why should I need to have the browser make an "offer" that I can then > manipulate to turn into an "answer" just to get it to listen to some RTP > and render it? > With my recent proposal (NoPlan JS API), you don't have to, at least not for media streams. You just tell the browser what to send with on the send side, and then what to receive with on the receive side. My proposal does not cover transports, however. It's an incremental improvement that relieves some of the pain, but not all. > > > Matthew Kaufman > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec53af13a8b6f0604df862cc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Wed, Jun 19, 2013 at 10:46 AM, Matthew Kaufman <matthew@matthe= w.at> wrote:
    =20 =20 =20
    On 6/19/2013 10:35 AM, Peter Thatcher wrote:



    On Wed, Jun 19, 2013 at 10:27 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
    2013/6/19 Peter Thatcher <pthatcher@google.com>:
    > Of course. =C2=A0That's why I made a proposal t= hat attempts to lessen the pain
    > (the NoPlan JS API). =C2=A0I'm trying to help you = :).

    And don't you agree that the pain is even less if we entirely remove SDP?


    I don't think it's removal of SDP that you want. = =C2=A0I think what you want is a way to use the API without using SDP. =C2=A0If the SDP is still there, but you don't have = to use it, you're still happy, right?

    I want the offer/answer state machine to go away. I don't like an API that requires me to fight with it to get it to do what I want, no matter what kinds of things I put in (SDP, JSON, wahtever).


    Are you demanding both addin= g what you want and removing what is there? =C2=A0Or, =C2=A0if you could ad= d everything you want, but leave what is currently there (SDP O/A), would y= ou be content?

    Why should I need to have the browser make an "offer" that I = can then manipulate to turn into an "answer" just to get it to li= sten to some RTP and render it?

    With my r= ecent proposal (NoPlan JS API), you don't have to, at least not for med= ia streams. =C2=A0You just tell the browser what to send with on the send s= ide, and then what to receive with on the receive side. =C2=A0My proposal d= oes not cover transports, however. =C2=A0It's an incremental improvemen= t that relieves some of the pain, but not all.
    =C2=A0


    Matthew Kaufman

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


    --bcaec53af13a8b6f0604df862cc7-- From pthatcher@google.com Wed Jun 19 11:44:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D514821F99F0 for ; Wed, 19 Jun 2013 11:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YucPMxzhrEvO for ; Wed, 19 Jun 2013 11:44:17 -0700 (PDT) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB1421F9935 for ; Wed, 19 Jun 2013 11:44:17 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id 10so5369328pdi.11 for ; Wed, 19 Jun 2013 11:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=86HXfZ8ztEUZVDMDbBOPeQ2Jd2+YL/HwBI1Mu0+3MnU=; b=I9tUI9omLSG/jCjgTKEeLWJw10mh7eOKoT47QQK7mE7iBDJDR9irKaSJdtd/keE2Ir xNqzkly0pXCGw6kJl8F4KdW5VnayUDdcgtEvzgOi+OGPebUbSCZpMUBjNjli6feNBMf4 1MNBy6lC+e0inwhMW+ZnF0Hlje6EmH42UE60AaVIV1F40Etv/JQq7q8lxQCq7bOA5VYG +FOJIPx6PVnmgfLNn/mLcEpy/OL45Rzv5Kgx9dAaMm1q2H4MziIeAZE8Lh8DnpQMHwXS oz9SlkRwb8368CNKT8e2C5vh4OqbL81RQKN17vRLrJp6iqQ3vavUP7wVoPEs0MGnUrpg khTQ== 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=86HXfZ8ztEUZVDMDbBOPeQ2Jd2+YL/HwBI1Mu0+3MnU=; b=Si7A58hNyj1Nsj7Uj0pnSiyIKGtkUZTrJFhIWHHVIoSwCKNwJUdIth0ZttbzUHVKLd phBqYQq87eby91F3p8pjgOJbsA3XqOJEFqOCZYCwNRvDS1L8rgUyjCgBwlHM3jzt026+ y9Z8zCsi0ZelcDhK342VXKcha6Fp6XmPFAkb86I4J9997kmut7rItUgvVh7L7eLcZqEe I0si4FIGrQQcKtMJQciz8GYixdaiKz2T5hhdFzIDhLj8C0IJOsDsUEp+G3CGuJ54FVNr 36PesEZV5KnchoVOYno6LCzKLctE4q/AvI8KdxT9zJKh0ahx8kDlKHw2MOUIopDWHsO4 pOrg== X-Received: by 10.68.1.226 with SMTP id 2mr4104853pbp.150.1371667457281; Wed, 19 Jun 2013 11:44:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 11:43:37 -0700 (PDT) In-Reply-To: <0867CEB4-2983-4B48-92A3-2E96CF74D8CD@skype.net> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <0867CEB4-2983-4B48-92A3-2E96CF74D8CD@skype.net> From: Peter Thatcher Date: Wed, 19 Jun 2013 11:43:37 -0700 Message-ID: To: "Matthew Kaufman (SKYPE)" Content-Type: multipart/alternative; boundary=bcaec53148178aa7b704df863739 X-Gm-Message-State: ALoCoQnf/i+tg+PLghkqdAZi2Uz3rr8rULx8ikgMNEcj4HzjyDGJ4XvipobHJIszzmTnCaXYyHlT5UbpIEC+Q/bHnkiJrJgM9Ks+rH+n6FFTPHu5oIL3twj4UmId2EpUPhuKl8WghAQ5ACtk4dZjsQ/LOBasoZ09dymliVArxk7PqNXLVAz0Qm6rj/IecZbKRCVlOIg13W41 Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 18:44:22 -0000 --bcaec53148178aa7b704df863739 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 19, 2013 at 11:04 AM, Matthew Kaufman (SKYPE) < matthew.kaufman@skype.net> wrote: > All of what you say below is true, but this is entirely backwards from > how web page authors are supposed to interact with the browser. > > > Imagine if displaying JPEG images in the page were equally possible, if > you wanted to munge a bunch of strings, but otherwise you were out of luc= k. > Web page authors currently interact with the browser by munging lots of URLs, HTML, CSS, and JS. Why not SDP? It's one more buzz word to add to your resume. (I'm trolling) > Matthew Kaufman > > (Sent from my iPhone) > > On Jun 19, 2013, at 9:41 AM, "Peter Thatcher" > wrote: > > > > > On Wed, Jun 19, 2013 at 9:10 AM, I=C3=B1aki Baz Castillo = wrote: > >> Hi Peter, for now just some comments (I agree that more use cases and >> other considerations must be provided): >> >> >> >> >> >> I don't think that the discussion is just about "SDP O/A usage in the >> >> API". We don't want a replacement for SDP, nor a new representation o= f >> >> SDP, nor to deal with blob strings between the JS layer and the WebRT= C >> >> layer. >> > >> > >> > Please at least agree with Christer that this is about the API, not >> about >> > the signalling wire format. The API already allows whatever signallin= g >> wire >> > format you want, >> >> >> IMHO that is not entirely true. >> >> First of all, whichever the signaling protocol is, it must accomplish >> with SDP O/A semantics (since it must carry a SDP and receive a SDP to >> establish the communication). >> > > API calls must use the SDP O/A, but what goes on the wire doesn't have > to be. With enough SDP hackery, you can do whatever you want over the > wire, including not use O/A semantics. > > >> >> Second: Indeed the current spec does not mandate what should be sent >> in the wire. In practice that means we can use SIP over WebSocket, >> XMPP/Jingle over HTTP, or whatever. But in practice it also means that >> we must send a SDP in the wire. The SDP blob string can be >> hex-encoded/escaped/mangled/whatever by the JS app, but the SDP blob >> string generated by PeerConnection-A should arrive to >> PeerConnection-B. > > > A sufficiently smart chunk of JS could call > setLocalDescription/setRemoteDescription with SDP that it completely > created itself, and send whatever it wants over the wire. > > >> And since such a SDP is generated by the WebRTC >> stack and passed to the JS as an unmanageable blob string, the JS app >> cannot properly deal with it. >> > > The JS parse the SDP from createOffer/createAnswer, get the info it > needs, make decisions and then serialize different SDP back down in > setLocalDescription/setRemoteDescription. It's terribly ugly, but it wor= ks. > > >> So, currently WebRTC does not mandate the signaling protocol >> in-the-wire, but it does mandate the media signaling protocol >> in-the-wire (you need to pass a working SDP to the remote, sure), >> something that constrains the signaling protocol itself. >> > > It does not mandate SDP over the wire. It's possible to write a JS app > that gets everything working with no SDP on the wire. It's anything but > pretty, but it works. > > > > > > and everything you mention from here on out is just the > > API. So please just say to Christer "yes, this is all about the API". > It > > will make the rest of the discussion much more clear. > > > Ok, this is all about the API :) > > >> In short we want something like a JS wrapper of the native > >> WebRTC API, > > > > > > I work on the WebRTC implementation in Chrome, and I don't know what yo= u > > mean by "native WebRTC API". Such a thing does not really exist. The > > implementation has three different layers of abstraction, each of which > you > > might be referring to, but none of them which will give you what you > want. > > The highest level uses SDP. The lowest level gives you media bits, but > no > > ICE, SRTP, DTLS, or SCTP. The middle layer gives you all those things > > without SDP, but it still uses an abstract offer/answer for transport a= nd > > RTP setup (and even has a Jingle implementation on top of that). None = of > > those give you what you want. The "native WebRTC API" that you want to > wrap > > doesn't exist. > > > Ok, IMHO nobody is still requesting a specific JS API but just > > describing the features and capabilities such an API must provide. The > > "similar to native WebRTC API" is just a comment to help understanding > > what we mean, but of course each browser is free to implement its > > native API(s) as it prefers so the "JS wrapper" concept does not make > > sense. > > But you can't say "similar to native WebRTC API" because no such thing > exists. You can't be similar to something that doesn't exist :). > > > >> to directly manage media/transport parameters and media > >> streams without having to pass a monolithic and unmanageable SDP blob > >> between the JS and the WebRTC layer. > > > > > > That boils down to "the same power of the current API, without going > through > > SDP". I think that's a clear requirement. So why don't you just say > that? > > Would save everyone a lot of reading and misunderstanding. > > > You are right. > > > > >> calls to get the required media parameters, the JS can send them to > >> the remote peer in the way it prefers (which may be via a SDP created > >> by the JS app, or via an AJAX request for sending codecs/media-types > >> info followed by a WebSocket connection for sending ICE candidates one > >> by one, or serialized in JSON via a previously open DataChannel > >> session... or whatever mechanism available in the Web and browsers). > >> > > > > You already have that. > > > Can I first send my codecs list, then (once the peer notifies me > > codecs compatibility) send the codecs preference order, then my ICE > > candidates and later (not just when ICE process terminates) signal the > > peer a "OK" message so we both start the multimedia audio/video/data > > communication, all of this with the current API? > > I think so, yes. > > > (I mean without parsing the SDP blob and splitting it into blob > fragments). > > Maybe... I don't know for sure. But generally, anything beyond the most > basic uses of the API requires at least some SDP hackery, and advanced us= es > require a lot. > > > Best regards. > > > > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec53148178aa7b704df863739 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On Wed, Jun 19, 2013 at 11:04 AM, Matthew Kaufman (SKYPE) = <matthew.kaufman@skype.net> wrote:
    All of what you say below is true, but this is entirely backwards from= how web page authors are supposed to interact with the browser.

    =C2=A0
    Imagine if displaying JPEG images in the page were equally possible, i= f you wanted to munge a bunch of strings, but otherwise you were out of luc= k.


    Web page auth= ors currently interact with the browser by munging lots of URLs, HTML, CSS,= and JS. =C2=A0Why not SDP? =C2=A0It's one more buzz word to add to you= r resume.


    (I'm trolling)=C2=A0

    <= /div>

    Matthew Kaufman

    (Sent from my iPhone)

    On Jun 19, 2013, at 9:41 AM, "Peter Thatcher" <pthatcher@google.com> wro= te:




    On Wed, Jun 19, 2013 at 9:10 AM, I=C3=B1aki Baz = Castillo <ibc@aliax.net>= ; wrote:
    Hi Peter, for now just some comments (I agree that more use cases and
    other considerations must be provided):




    >> I don't think that the discussion is just about "SDP O/A = usage in the
    >> API". We don't want a replacement for SDP, nor a new repr= esentation of
    >> SDP, nor to deal with blob strings between the JS layer and the We= bRTC
    >> layer.
    >
    >
    > Please at least agree with Christer that this is about the API, not ab= out
    > the signalling wire format. =C2=A0The API already allows whatever sign= alling wire
    > format you want,


    IMHO that is not entirely true.

    First of all, whichever the signaling protocol is, it must accomplish
    with SDP O/A semantics (since it must carry a SDP and receive a SDP to
    establish the communication).

    API calls must use the SDP O/A, but what goes on the wire doesn't = have to be. =C2=A0With enough SDP hackery, you can do whatever you want ove= r the wire, including not use O/A semantics.
    =C2=A0

    Second: Indeed the current spec does not mandate what should be sent
    in the wire. In practice that means we can use SIP over WebSocket,
    XMPP/Jingle over HTTP, or whatever. But in practice it also means that
    we must send a SDP in the wire. The SDP blob string can be
    hex-encoded/escaped/mangled/whatever by the JS app, but the SDP blob
    string generated by PeerConnection-A should arrive to
    PeerConnection-B.

    A sufficiently smart chunk of JS could call setLocalDescription/setRem= oteDescription with SDP that it completely created itself, and send whateve= r it wants over the wire. =C2=A0
    =C2=A0
    And since such a SDP is generated by the WebRTC
    stack and passed to the JS as an unmanageable blob string, the JS app
    cannot properly deal with it.

    The JS parse the SDP from createOffer/createAnswer, get the info it ne= eds, make decisions and then serialize different SDP back down in setLocalD= escription/setRemoteDescription. =C2=A0It's terribly ugly, but it works= .
    =C2=A0
    So, currently WebRTC does not mandate the signaling protocol
    in-the-wire, but it does mandate the media signaling protocol
    in-the-wire (you need to pass a working SDP to the remote, sure),
    something that constrains the signaling protocol itself.

    It does not mandate SDP over the wire. =C2=A0It's possible to writ= e a JS app that gets everything working with no SDP on the wire. =C2=A0It&#= 39;s anything but pretty, but it works.




    > and everything you mention from here on out is just the
    > API. =C2=A0So please just say to Christer "yes, this is all about= the API". =C2=A0It
    > will make the rest of the discussion much more clear.

    > Ok, this is all about the API :)

    >> In short we want something like a JS wrapper of the native
    >> WebRTC API,
    >
    >
    > I work on the WebRTC implementation in Chrome, and I don't know wh= at you
    > mean by "native WebRTC API". =C2=A0Such a thing does not rea= lly exist. =C2=A0The
    > implementation has three different layers of abstraction, each of whic= h you
    > might be referring to, but none of them which will give you what you w= ant.
    > The highest level uses SDP. =C2=A0The lowest level gives you media bit= s, but no
    > ICE, SRTP, DTLS, or SCTP. =C2=A0The middle layer gives you all those t= hings
    > without SDP, but it still uses an abstract offer/answer for transport = and
    > RTP setup (and even has a Jingle implementation on top of that). =C2= =A0None of
    > those give you what you want. =C2=A0The "native WebRTC API" = that you want to wrap
    > doesn't exist.

    > Ok, IMHO nobody is still requesting a specific JS API but just
    > describing the features and capabilities such an API must provide. The=
    > "similar to native WebRTC API" is just a comment to help und= erstanding
    > what we mean, but of course each browser is free to implement its
    > native API(s) as it prefers so the "JS wrapper" concept does= not make
    > sense.

    But you can't say "simila= r to native WebRTC API" because no such thing exists. =C2=A0You= can't be similar to something that doesn't exist :).


    >> to directly manage media/transport parameters and media
    >> streams without having to pass a monolithic and unmanageable SDP b= lob
    >> between the JS and the WebRTC layer.
    >
    >
    > That boils down to "the same power of the current API, without go= ing through
    > SDP". =C2=A0I think that's a clear requirement. =C2=A0So why = don't you just say that?
    > Would save everyone a lot of reading and misunderstanding.

    > You are right.



    >> calls to get the required media parameters, the JS can send them t= o
    >> the remote peer in the way it prefers (which may be via a SDP crea= ted
    >> by the JS app, or via an AJAX request for sending codecs/media-typ= es
    >> info followed by a WebSocket connection for sending ICE candidates= one
    >> by one, or serialized in JSON via a previously open DataChannel >> session... or whatever mechanism available in the Web and browsers= ).
    >>
    >
    > You already have that.

    > Can I first send my codecs list, then (once the peer notifies me
    > codecs compatibility) send the codecs preference order, then my ICE > candidates and later (not just when ICE process terminates) signal the=
    > peer a "OK" message so we both start the multimedia audio/vi= deo/data
    > communication, all of this with the current API?

    I think so, yes.

    > (I mean without parsing the SDP blob and splitting it into blob fragme= nts).

    Maybe... I don't know for sure. =C2=A0But generally, anything beyo= nd the most basic uses of the API requires at least some SDP hackery, and a= dvanced uses require a lot.


    Best regards.




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

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

    --bcaec53148178aa7b704df863739-- From pthatcher@google.com Wed Jun 19 11:47:20 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8598A21F9E1B for ; Wed, 19 Jun 2013 11:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs4ILLmbvqL3 for ; Wed, 19 Jun 2013 11:47:20 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id AA15D21F9E59 for ; Wed, 19 Jun 2013 11:47:17 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id um15so5310155pbc.24 for ; Wed, 19 Jun 2013 11:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TZ8d9WUDpibXphADSWgblRVP/eC6y0x+/RKrsVUNHyc=; b=UhWD3kC4ei+H3f0iOJVtNmo45bi5O4QsFXUkJlw1rOLxpZMOU79Pd0vs+cOucANWGF sQ99un9DF1yyxfL+fWrhlAFgQgntcv7EUXg16gOSwlRQYjV/qL0OMUghyq3xnAQ5LZkZ MKDzuLou/CeYu0jI7L6LxgkQw+JPj/RnEAeZCaVI1VlzIN7enH5k62EkYsdROplg/pgD sEFifyknHmqIR8F30UwJ5knu9CTNVA+ETh200eLXJP2iOvg7Xkp7eyDMW0KY0Vu7VzJY O08EYvr5rE0PCVYRF45a7DXjPtyXrscxyYLtfk4i5bAKywszrZW+hfPLpSR7dK8Xg9HL xkkw== 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=TZ8d9WUDpibXphADSWgblRVP/eC6y0x+/RKrsVUNHyc=; b=CQgMGXiRWE/VYAawb7O3LmzJrwE0M50mjqf9fD/qJ4hytCcvGus0v2kkz2M1cc7/ao G4krXOZ8PFSwK+c51oEndNaWmuDECD4VtrTIcc8168oV0xikYqHf2NbLnADhdTRHTkqG HAMIF6nuKjhxPyV7rJ5BY8aNVyBErlsnXMDxPkTs97Mc6uJpx9TdwaVpDk7P7gHzTjsW b23gcu5FKwuqodRP8T4Gp5ERcpnBaDE/1O1KtPvzeNIfJbNJes6u0K8z+P2IWksmPMbI +viweaPviHAV6XmeE+qOrTyjIPbQLIkVgpWzP1d/+jEsSLjKL9x/2ZDRLKL9bnd0DO81 MFow== X-Received: by 10.66.240.70 with SMTP id vy6mr8171553pac.70.1371667637195; Wed, 19 Jun 2013 11:47:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 11:46:37 -0700 (PDT) In-Reply-To: <51C1F5ED.9090308@matthew.at> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> From: Peter Thatcher Date: Wed, 19 Jun 2013 11:46:37 -0700 Message-ID: To: Matthew Kaufman Content-Type: multipart/alternative; boundary=047d7b15aba943fb8304df864266 X-Gm-Message-State: ALoCoQn73gi7R0IjyO76YjHpbmUjt6nFnrMqpf99XOmjATc3fGMmLvxyvbOVwfYc1gQi7Skwk9ecmcqytG/a7VvFXDrSSlQdRv7K22cWmgqwxkdwIPHBE6YIPEiY7Uv1CWAOUeVVoBXREicKrUqdCExXydeppmVMscWnOSjMplOS6Twj8WBTKB6+GZZXWznS0Zc+yg+eK51O Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 18:47:20 -0000 --047d7b15aba943fb8304df864266 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 19, 2013 at 11:18 AM, Matthew Kaufman wrote: > On 6/19/2013 11:05 AM, Robin Raymond wrote: > > > Why aren't we using the JavaScript object model for control of components > instead of serializing our control requests via SDP/whatever format and > hoping that it worked? > > That's a great question. Have you read the CU-RTCWEB proposal? Is it any > closer to what you imagined the RTCWEB API might be? > My "NoPlan JS API" proposal also allows control of components without serialize control via a format, if the JS chooses to do so (SDP is still there if JS wants). It only does so for media streams, not for transports, but it allows incremental improvement to the API. > > > Matthew Kaufman > --047d7b15aba943fb8304df864266 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Wed, Jun 19, 2013 at 11:18 AM, Matthew Kaufman <matthew@matthe= w.at> wrote:
    =20 =20 =20
    On 6/19/2013 11:05 AM, Robin Raymond wrote:
    =20
    Why aren't we using the JavaScript object model for control of components instead of serializing our control requests via SDP/whatever format and hoping that it worked?

    That's a great question. Have you read the CU-RTCWEB proposal? Is i= t any closer to what you imagined the RTCWEB API might be?

    My "NoPlan JS API" proposal also allows c= ontrol of components without serialize control via a format, if the JS choo= ses to do so (SDP is still there if JS wants). =C2=A0It only does so for me= dia streams, not for transports, but it allows incremental improvement to t= he API.
    =C2=A0


    Matthew Kaufman

    --047d7b15aba943fb8304df864266-- From pthatcher@google.com Wed Jun 19 11:51:37 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB6F21F9EA2 for ; Wed, 19 Jun 2013 11:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFfihaNCBtZb for ; Wed, 19 Jun 2013 11:51:32 -0700 (PDT) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by ietfa.amsl.com (Postfix) with ESMTP id A442021F9E16 for ; Wed, 19 Jun 2013 11:51:32 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id r10so5365604pdi.27 for ; Wed, 19 Jun 2013 11:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=y6kDCKjMc1Ox5Wz7/HTnR53hAf6yvjz0csnbE+7+sJI=; b=ZqiZ86yIkdBpLl5WIykMG8diwhEipdxczJ5OcyA1HRc4J+jvxObTXp3fHdif2Ml156 qKHy0w+Ruwzy//VRGSYjIdkxBwez37wS2RNXN7EjZDrJZI6oakcAkj6bfSlVb2q2wQlD JybidOWT/8gL7xxanXIzHmhl7wnmVDFR5Q1LgPNWj03XOXuO08sSqVIGwDhPeDmKLy3L mlExQjS8PuY6It5/RGwLZlEvLQo8Wt3+kIYVuEiTn0iTz1dcVkPi1Kh61EdCkkisVZG3 p6M0yuRvMXU1BMcs8u42VDiEwwmZYuKvbEsmZStJOeDB5KykG3Z+FCXmIjJd5J7QEMWk 3+eA== 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=y6kDCKjMc1Ox5Wz7/HTnR53hAf6yvjz0csnbE+7+sJI=; b=MuQ4cuaNxT02HbwLvupM9f5sfBaf3m3IzyT+bCAzMCQFd0LYuKSKjc8hv5ofFthgZ+ iGLnkJevaf+KzUlIXvBfjhXgRUA0cpDPtuSmvcl3/FuAEaiI+mHJDjrsEfAftpjNHKWB 4wlRqjz/h91uC5GKxKa1abgEPtT38XPBQwBmltJDD5yplzRI5bnFSsP/yBbjrvMkllIE 082m9VsQVNGmRz/LP9m0hqC7WvqKD5J+EsmiwQuZ8eTTzPLuyRL6KRL/wJwg2NuG3Nji +gqy+W2UFHTyaBx0NOpVB/XNQNqjn+mH9TaaaC4taSGD4knrQI8lQdWEcsBsg6USsCpw yOLQ== X-Received: by 10.68.69.108 with SMTP id d12mr4051710pbu.187.1371667891915; Wed, 19 Jun 2013 11:51:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 11:50:51 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> From: Peter Thatcher Date: Wed, 19 Jun 2013 11:50:51 -0700 Message-ID: To: "Matthew Kaufman (SKYPE)" Content-Type: multipart/alternative; boundary=0015174989ee72c43104df865160 X-Gm-Message-State: ALoCoQl+tHvLaD82oYCEl/+ZHdAOq20vdXJ/SjVCu2yOegxglD/Cew8LL/jkGovRy6MSWF3BVvsRhlnpjqDJ6ee4kbd4GjV8iMvD1GFArunGuv2U6iyo0YHmiAYNL+0np5MYlM+msTfc9MS/Z0rKbeCMIuN6f6624Z/u9q46midNO3tK5L0KMB16k/FZzQLJfEpeoeUj56qm Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 18:51:37 -0000 --0015174989ee72c43104df865160 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 19, 2013 at 11:01 AM, Matthew Kaufman (SKYPE) < matthew.kaufman@skype.net> wrote: > Fighting the offer/answer machinery in the browser is always possible, > but never easier. > > I want an API that let's me tell the browser what to do, not engage in > an argument with it until it is beaten into submission. I think an API that > let's me tell the browser what to do will then also be much easier to > extend to give me *more* control. > > My recent "NoPlan JS API" give you precisely that, at least for media streams (not for transports). But it's an incremental improvement, which you have categorically rejected. > As an example, putting A and V over the same transport... Could be one > more JS API, instead of a discussion at MMUSIC about how to encode that in > our must-use SDP, followed by JS code I need to write to argue with the > browser when it offers that but I want to turn it off, or vice versa. > Again, my "NoPlan JS API" give you exactly that, at least in theory. No one has implemented it yet :). > > Matthew Kaufman > > (Sent from my iPhone) > > On Jun 19, 2013, at 9:50 AM, "Peter Thatcher" > wrote: > > I asked "is there something that can't be done without sufficient SDP > munging"? You answered "I have something that can be done with sufficient > SDP munging". OK. But do you have something that *can't* be done with > SDP munging? > > If there's nothing that can't be done with SDP munging, then this whole > thread boils down to "give us an API that has the same amount of control as > the current one, but without requiring SDP munging to do advanced things". > And if that's is what is desired, then at least it can be clear and > concise. > > > > > On Wed, Jun 19, 2013 at 9:36 AM, Matthew Kaufman wrote: > >> I provided a use case that, unless one wants to write a bunch of >> SDP-munging JS state machine cannot be done. >> >> The problem is that such use cases are either 1) ignored or 2) >> dismissed because of course if one writes said JS, they are possible with >> the current API >> >> Matthew Kaufman >> >> (Sent from my iPhone) >> >> On Jun 19, 2013, at 9:28 AM, Peter Thatcher wrote: >> >> I might be wrong, but I tried reading and understanding your whole >> email, and it seems to come down to "I don't want to use SDP or a different >> (JSON) form of SDP". That's a fine thing to request, but why don't you >> just say that? It would save everyone a lot of reading and confusion to be >> more concise. >> >> Or, if you have specific things you'd like to do but can't, what are >> they? I think that would help me, and others, understand more easily. Use >> cases would be helpful. >> >> On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond wrote: >> >>> >>> The trouble is not that we can choose to send whatever we want over the >>> wire. I know we can. If the WebRTC API is left with SDP as it stands, I'll >>> dissect the SDP from the browser, reinterpret and reconstruct on the SDP on >>> the remote side. That is NOT the issue. >>> >>> The summary of what I want/believe: >>> 1) I want as close to raw access to RTP/ICE streams, media, sources, >>> outputs, codecs as viable. Obviously doing the actual transmission, >>> encoding/decoding from JS is not feasible (yet), nor is secure [ICE >>> must occur for mutual agreement to exchange data between peers], but having >>> controls for how these components are wired together is extremely feasible >>> from JS and would allow immensely powerful apps to be produced from JS. >>> >> >> What would you like to do that you can't do via SDP right now? You >> said this isn't just about working through SDP. But I don't see anything >> concrete you can't do right now with sufficient SDP >> parsing/building/munging/hackery. >> >> >> >>> 2) I don't want my primary interface to control media/RTP engines to be >>> via obtaining or providing SDPs to the browser (or any alternative >>> serialized format); especially given that SDP requires a round trip >>> offer/answer to the remote party to affect change (e.g. it's entirely >>> possible to do that stateless and one-sided). The SPD interface API is a >>> monolithic do-everything serialized format to control an engine but >>> extremely badly/poorly/short sighted (regardless if it is SDP or whatever >>> instead), and it's wholly unneeded. >>> >> >> Short summary: "I don't want to use SDP". Right? >> >> 3) I don't want a replacement for SDP with another more "pretty" format >>> like JSON. >>> >> >> Short summary: "I don't want to use SDP or a different syntax for SDP". >> Right? >> >> 4) I want no specified requirement from the browser to have any >>> particular form of media negotiation API requirement what-so-ever >>> (regardless if I can opt to substitute with my own format on the wire or >>> not) >>> >> >> Short summary: "I don't want to use SDP or a different syntax for SDP". >> Right? >> >> >>> 5) Using SDP with offer/answer build into the browser binary is a >>> horribly BAD technical choice (even for SIP folks) and must be stopped, >>> see: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html >>> >> >> Short summary: "I don't want to use SDP". Right? >> >> >>> >>> >>> I too want to understand the rational for keeping something as bad as >>> SDP with offer/answer as the primary mechanism for controlling the media >>> components and interaction to those component and more importantly, I'd too >>> would like to open debate to agreeing or not to provide a lower layer API >>> rather than a media negotiation API as a complete substitute alternative to >>> SDP with offer/answer. >>> >>> If we can agree that it's far superior to have a lower level media/RTC >>> component API rather than a media negotiation API, then we can propose what >>> that API could look like (and there are people who have already have >>> starting proposals). I'd throw my hat in the ring to propose such and API >>> if necessary as I've written such engines from scratch before. But I don't >>> want to waste time proposing ore reviewing such an API which will be >>> summarily dismissed because people are so stuck on requiring a media >>> negotiation API built into the browser binary, and specifically SDP with >>> offer/answer in this case. >>> >> >> >> The WG may dislike and reject your proposal, but there's a bit of truth >> to the old mathematically incorrect sports adage "you miss 100% of the >> shots you don't take". >> >> >> Anyone who argues that they need/want that simple SDP media negotiation >>> API must understand that a lower level API would allow a wrapper API to >>> produce the same WebRTC API the have today but be built entirely from >>> JavaScript >>> >> >> That depends on how low-level you go. If you go too low-level, it >> becomes infeasible to do things correctly and performantly in JavaScript. >> >> >>> upon a lower level API. Thus they can have their "just add-milk" >>> baking API. But those of us who need control of the raw ingredients beyond >>> the "just add milk" can still innovate. >>> >>> -Robin >>> >>> >>> >>> Peter Thatcher >>> 19 June, 2013 2:49 AM >>> Correct my if I'm wrong, but the API already leaves what goes over >>> the wire completely up to the JS app. So we couldn't re-open a debate of >>> "SDP or not SDP" for the wire format, because there's nothing to debate. >>> We already decided it would be left to the JS to decide. The only thing >>> left to debate is the API. >>> >>> Or am I wrong? >>> >>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> Christer Holmberg >>> 19 June, 2013 2:34 AM >>> Hi, >>> >>> We need to be very clear what we talk about, or some people are always >>> going to be confused :) >>> >>> So, AFAIK, the discussion is about SDP O/A usage in the API, only in the >>> API, and nowhere but the API. >>> >>> Whatever people us on the wire is outside the scope. >>> >>> Right? >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> Sent from *Windows* using *TouchDown* (www.nitrodesk.com) >>> >>> -----Original Message----- >>> *From:* Peter Thatcher [pthatcher@google.com] >>> *To:* Martin Thomson [martin.thomson@gmail.com] >>> *CC:* rtcweb@ietf.org [rtcweb@ietf.org] >>> *Subject:* Re: [rtcweb] Requesting "SDP or not SDP" debate to be >>> re-opened >>> Martin, you're right; that was overly harsh of me. Adam, I apologize. >>> I'll be civil in the future. >>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> Peter Thatcher >>> 19 June, 2013 1:36 AM >>> Martin, you're right; that was overly harsh of me. Adam, I >>> apologize. I'll be civil in the future. >>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> Martin Thomson >>> 18 June, 2013 6:25 PM >>> I agree with Peter, except for this bit: >>> >>> Adam is much harder to confuse than you think, or than he professes. >>> >>> Speaking of burning it all down and starting over. If you want a >>> house-related analogy, that's not quite correct. It's refusing to >>> build an extension because the old house, while legally fit for >>> habitation, is falling down around your ears. Since you only need >>> foundations, it's not that big a job (though I'll grant you that it's >>> bigger than many people realize, even with that smaller scope). >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> Peter Thatcher >>> 18 June, 2013 6:16 PM >>> Adam, I think you're confused. As Ted pointed out, there are two >>> different uses of SDP: 1. as a control surface, 2. as a message format for >>> signalling. SDPNG was trying to replace SDP for #2. While I believe this >>> thread was started entirely focused on #1. So you're talking about >>> different things. >>> >>> So far the only time spent on trying to replace or avoid SDP for #1 >>> has been "comment 22", and to a lesser extent the proposal I just made for >>> adding 2 methods to PeerConnection (createLocalStream and >>> createRemoteStream). I think it's incorrect to conclude that we should >>> never try to improve #1 just because other in the past failed to replace >>> #2. They're very different. >>> >>> I also don't think we should burn down WebRTC and start over, but >>> despite what some seem to think, we don't have to choose between "burn it >>> down" and "never improve it". There are many options other than the two >>> extremes. >>> >>> >>> >>> By the way, a gentle reminder: SDP is not the only way to do #2. I >>> work on a rather large system almost entirely build around Jingle, without >>> a hint of SDP, and it works just fine. Much better than SDP would have, I >>> think. Just because SDPNG didn't work out doesn't mean there will never be >>> any way other to do signalling than SDP. >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > --0015174989ee72c43104df865160 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Wed, Jun 19, 2013 at 11:01 AM, Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net> wrote:
    Fighting the offer/answer machinery in the browser is always possible,= but never easier.

    I want an API that let's me tell the browser what to do, not engag= e in an argument with it until it is beaten into submission. I think an API= that let's me tell the browser what to do will then also be much easie= r to extend to give me *more* control.


    My recent "NoPla= n JS API" give you precisely that, at least for media streams (not for= transports). =C2=A0But it's an incremental improvement, which you have= categorically rejected.
    =C2=A0
    As an example, putting A and V over the same transport... Could be one= more JS API, instead of a discussion at MMUSIC about how to encode that in= our must-use SDP, followed by JS code I need to write to argue with the br= owser when it offers that but I want to turn it off, or vice versa.

    Again, my "NoPlan JS API" give you exactly that, at least i= n theory. =C2=A0No one has implemented it yet :).=C2=A0



    Matthew Kaufman

    (Sent from my iPhone)

    On Jun 19, 2013, at 9:50 AM, "Peter Thatcher" <pthatcher@google.com> wro= te:

    I asked "is there something that can't be done wi= thout sufficient SDP munging"? =C2=A0You answered "I have somethi= ng that can be done with sufficient SDP munging". =C2=A0 OK. =C2=A0But= do you have something that *can't* be done with SDP munging?

    If there's nothing that can't be done with SDP munging, then t= his whole thread boils down to "give us an API that has the same amoun= t of control as the current one, but without requiring SDP munging to do ad= vanced things". =C2=A0And if that's is what is desired, then at least it can be clear and concise.




    On Wed, Jun 19, 2013 at 9:36 AM, Matthew Kaufman= <matthew@matthew= .at> wrote:
    I provided a use case that, unless one wants to write a bunch of SDP-m= unging JS state machine cannot be done.

    The problem is that such use cases are either 1) ignored or 2) dismiss= ed because of course if one writes said JS, they are possible with the curr= ent API

    Matthew Kaufman

    (Sent from my iPhone)

    On Jun 19, 2013, at 9:28 AM, Peter Thatcher <pthatcher@google.com> wrote:

    I might be wrong, but I tried reading and understanding your whole ema= il, and it seems to come down to "I don't want to use SDP or a dif= ferent (JSON) form of SDP". =C2=A0That's a fine thing to request, = but why don't you just say that? =C2=A0It would save everyone a lot of reading and confusion to be more concise. =C2=A0

    Or, if you have specific things you'd like to do but can't, wh= at are they? =C2=A0I think that would help me, and others, understand more = easily. =C2=A0Use cases would be helpful.

    On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond <<= a href=3D"mailto:robin@hookflash.com" target=3D"_blank">robin@hookflash.com= > wrote:

    The trouble is not that we can choose to send whatever we want over the wir= e. I know we can. If the WebRTC API is left with SDP as it stands, I'll= dissect the SDP from the browser, reinterpret and reconstruct on the SDP o= n the remote side. That is NOT the issue.

    The summary of what I want/believe:
    1) I want as close to raw access to RTP/ICE streams, media, sources, output= s, codecs as viable. Obviously doing the actual transmission, encoding/deco= ding from JS is not feasible (yet), nor is secure [ICE must occur for mutual agreement to e= xchange data between peers], but having controls for how these components a= re wired together is extremely feasible from JS and would allow immensely p= owerful apps to be produced from JS.

    What would you like to do that you can't do via SDP right now? =C2= =A0You said this isn't just about working through SDP. =C2=A0But I don&= #39;t see anything concrete you can't do right now with sufficient SDP = parsing/building/munging/hackery.

    =C2=A0
    2) I don't want my primary in= terface to control media/RTP engines to be via obtaining or providing SDPs = to the browser (or any alternative serialized format); especially given tha= t SDP requires a round trip offer/answer to the remote party to affect change (e.g. it's entirely possible to d= o that stateless and one-sided). The SPD interface API is a monolithic do-e= verything serialized format to control an engine but extremely badly/poorly= /short sighted (regardless if it is SDP or whatever instead), and it's wholly unneeded.

    Short summary: "I don't want to use SDP". =C2=A0Right?

    3) I don't want a replacement= for SDP with another more "pretty" format like JSON.

    Short summary: "I don't want to use SDP or a different syntax= for SDP". =C2=A0Right?

    4) I want no specified requiremen= t from the browser to have any particular form of media negotiation API req= uirement what-so-ever (regardless if I can opt to substitute with my own fo= rmat on the wire or not)

    Short summary: "I don't want to use SDP or a different syntax= for SDP". =C2=A0Right?
    =C2=A0
    5) Using SDP with offer/answer bu= ild into the browser binary is a horribly BAD technical choice (even for SI= P folks) and must be stopped, see: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html

    Short summary: "I don't want to use SDP". =C2=A0Right?
    =C2=A0


    I too want to understand the rational for keeping something as bad as SDP w= ith offer/answer as the primary mechanism for controlling the media compone= nts and interaction to those component and more importantly, I'd too wo= uld like to open debate to agreeing or not to provide a lower layer API rather than a media negotiation API as= a complete substitute alternative to SDP with offer/answer.

    If we can agree that it's far superior to have a lower level media/RTC = component API rather than a media negotiation API, then we can propose what= that API could look like (and there are people who have already have start= ing proposals). I'd throw my hat in the ring to propose such and API if necessary as I've written such eng= ines from scratch before. But I don't want to waste time proposing ore = reviewing such an API which will be summarily dismissed because people are = so stuck on requiring a media negotiation API built into the browser binary, and specifically SDP with offer/answer = in this case.


    The WG may dislike and reject your proposal, but there's a bit of = truth to the old mathematically incorrect sports adage "you miss 100% = of the shots you don't take".


    Anyone who argues that they need/= want that simple SDP media negotiation API must understand that a lower lev= el API would allow a wrapper API to produce the same WebRTC API the have to= day but be built entirely from JavaScript

    That depends on how low-level you go. =C2=A0If you go too low-level, i= t becomes infeasible to do things correctly and performantly in JavaScript.=
    =C2=A0
    upon a lower level API. Thus they can have their "just add-milk&q= uot; baking API. But those of us who need control of the raw ingredients be= yond the "just add milk" can still innovate.

    -Robin


    &= lt;compose-unknown-contact.jpg>
    = 19 June, 2013 2:49= AM
    Correct my if I'm wrong, but the API already leaves wh= at goes over the wire completely up to the JS app. =C2=A0So we couldn't= re-open a debate of "SDP or not SDP" for the wire format, becaus= e there's nothing to debate. =C2=A0We already decided it would be left to the JS to decide. =C2=A0The only thing left to debate is the AP= I. =C2=A0

    Or am I wrong?




    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
    &= lt;compose-unknown-contact.jpg>
    = 19 June, 2013 2:34= AM
    Hi,
    =C2=A0
    We need to be very clear what we talk about, or= some people are always going to be confused :)
    =C2=A0
    So, AFAIK, the discussion is about SDP O/A usag= e in the API, only in the API, and nowhere but the API.
    =C2=A0
    Whatever people us on the wire is outside the s= cope.
    =C2=A0
    Right?
    =C2=A0
    Regards,
    =C2=A0
    Christer
    =C2=A0


    Sent from Windows using TouchDown= (www.nitrodesk.com<= /a>)

    -----Original Message-----
    From: Peter Thatcher [    pthatcher@google.com]
    To: Martin Thomson [martin.thomson@gmail.com]
    CC: rtcweb@ietf= .org [rtcweb@ietf.= org]
    Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate t= o be re-opened
    Martin, you're right; that was overly harsh of me. =C2= =A0Adam, I apologize. =C2=A0I'll be civil in the future.



    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
    &= lt;compose-unknown-contact.jpg>
    = 19 June, 2013 1:36= AM
    Martin, you're right; that was overly harsh of me. =C2= =A0Adam, I apologize. =C2=A0I'll be civil in the future.



    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
    &= lt;compose-unknown-contact.jpg>
    = 18 June, 2013 6:25= PM
    I agree with Peter, except for this bit:

    Adam is much harder to confuse than you think, or than he professes.
    Speaking of burning it all down and starting over. If you want a
    house-related analogy, that's not quite correct. It's refusing to build an extension because the old house, while legally fit for
    habitation, is falling down around your ears. Since you only need
    foundations, it's not that big a job (though I'll grant you that it= 's
    bigger than many people realize, even with that smaller scope).
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
    &= lt;compose-unknown-contact.jpg>
    = 18 June, 2013 6:16= PM
    Adam, I think you're confused. =C2=A0As Ted pointed ou= t, there are two different uses of SDP: 1. =C2=A0as a control surface, 2. a= s a message format for signalling. =C2=A0SDPNG was trying to replace SDP fo= r #2. =C2=A0While I believe this thread was started entirely focused on #1. =C2=A0So you're talking about different things.

    So far the only time spent on trying to replace or avoid SDP for #1 ha= s been "comment 22", and to a lesser extent the proposal I just m= ade for adding 2 methods to PeerConnection (createLocalStream and createRem= oteStream). =C2=A0 I think it's incorrect to conclude that we should never try to improve #1 just because other in the past fail= ed to replace #2. =C2=A0They're very different.

    I also don't think we should burn down WebRTC and start over, but = despite what some seem to think, we don't have to choose between "= burn it down" and "never improve it". =C2=A0There are many o= ptions other than the two extremes.



    By the way, a gentle reminder: SDP is not the only way to do #2. =C2= =A0I work on a rather large system almost entirely build around Jingle, wit= hout a hint of SDP, and it works just fine. =C2=A0Much better than SDP woul= d have, I think. =C2=A0Just because SDPNG didn't work out doesn't mean there will never be any way other to do signalli= ng than SDP.




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

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

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

    --0015174989ee72c43104df865160-- From hadriel.kaplan@oracle.com Wed Jun 19 12:23:40 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA4621F995C for ; Wed, 19 Jun 2013 12:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDtDRyJIRwOp for ; Wed, 19 Jun 2013 12:23:32 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFEF21F9B8F for ; Wed, 19 Jun 2013 12:23:32 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5JJNUhT009458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jun 2013 19:23:31 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5JJNT3M006285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 19:23:30 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5JJNTxn006276; Wed, 19 Jun 2013 19:23:29 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Jun 2013 12:23:29 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51C02EE8.5070809@ericsson.com> Date: Wed, 19 Jun 2013 15:23:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> To: "rtcweb-chairs@tools.ietf.org" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: rtcweb@ietf.org Subject: [rtcweb] Agenda time request for IETF 87 Berlin X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 19:23:40 -0000 Howdy, per the email below, I formally request agenda time to discuss - and = reach a conclusive vote on - whether to make SDES an MTI key exchange = mechanism, or not. I plan to present both sides of the argument with a set of pro/con = slides. I used to favor making SDES mandatory, but over time I've = become less sure if its benefits outweigh its drawbacks. Mostly though = what I care about is making a *decision* one way or the other, and = moving on. =20 I do *not* plan to present on DTLS-EKT at all, not even as a potential = alternative. I only plan to present on whether SDES should be MTI or = not for WebRTC implementations. I think this will take an hour at least, possibly longer. I can pretend = to claim it will take 15 minutes, but we all know that simply isn't true = unless someone disconnects the microphones in the room. I also expect = two or more other folks to want time to present on the same topic, so = it'll likely take even longer in total time. Lastly, I beg the chairs to make this agenda item topic (not necessarily = my presentation, but the general topic) the *first* agenda topic for = whichever meeting session it gets put in, so that we don't run out of = time on other topics and delay an SDES decision once again. -hadriel On Jun 18, 2013, at 5:56 AM, Magnus Westerlund = wrote: > Please request agenda time for > Berlin and ensure to update any drafts or other material to actually > take into account what actually has happened in the last 15 months. From prvs=48823f5ea6=christer.holmberg@ericsson.com Wed Jun 19 12:48:01 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4917721F9F3F for ; Wed, 19 Jun 2013 12:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.861 X-Spam-Level: X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9u4+uHq5PRT for ; Wed, 19 Jun 2013 12:47:41 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5039F21F9F2B for ; Wed, 19 Jun 2013 12:47:41 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-68-51c20adc0961 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1B.62.18006.CDA02C15; Wed, 19 Jun 2013 21:47:40 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 21:47:39 +0200 From: Christer Holmberg To: Peter Thatcher , Matthew Kaufman Thread-Topic: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Thread-Index: AQHObEI/LKM23biSMEicZL6ip01H1Jk7xwcAgAACKQCAAB+igIAAApYAgAB4ZYCAADHZMP//4oGAgAB39oCAACnpgIAAAi8AgAADwwCAABUmgIAAA5iAgAAH5oCAADG2IA== Date: Wed, 19 Jun 2013 19:47:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B1680@ESESSMB209.ericsson.se> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvre4drkOBBsd2KFq0zT7CYnFt+WtW i7X/2tkdmD0WbCr1WLLkJ5PHqU6vAOYobpukxJKy4Mz0PH27BO6MPcsfMBc8Yq84vlungfEE excjJ4eEgInEndW/WCBsMYkL99azdTFycQgJHGaUeDfrBROEs4hRYtGvfqAMBwebgIVE9z9t kAYRgUCJCS+ngzUzC6hKnD90jhHEFhbwkLh/dh07SLmIgKfE8rNVIGNEBCYxSvS9ns0EUsMC VD/l1y2wI3gFfCWON09nhNjVzC5x9nsjWBEn0IJDt7+BLWAEuu77qTVMEMvEJT4cvM4McbWA xJI956FsUYmXj/+xQthKEo1LnrCCHMEsoCmxfpc+RKuixJTuh1B7BSVOznzCMoFRbBaSqbMQ OmYh6ZiFpGMBI8sqRvbcxMyc9HKjTYzAiDm45bfqDsY750QOMUpzsCiJ8348tStQSCA9sSQ1 OzW1ILUovqg0J7X4ECMTByeI4JJqYPTr6u3UusgldGCPYvHBXRG/NC5u0FgaZ1NVYuS9cV+0 bOxcw9NxSp5veHOltq88y8L7Y+HVg5stlWO9b7YsKC2v/1F4I/j+uY+PNa4eYV7RcjGrZ9Oc OvWwZR+1Kpf66mxfv3TZrfAyx18Pfxg38QSvP/LyST2beFCOtvymm6dM4g6FWnyxd1JiKc5I NNRiLipOBABbAgWGawIAAA== Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 19:48:01 -0000 SGksDQoNCj4+PiBXaHkgYXJlbid0IHdlIHVzaW5nIHRoZSBKYXZhU2NyaXB0IG9iamVjdCBtb2Rl bCBmb3IgY29udHJvbCBvZiBjb21wb25lbnRzIGluc3RlYWQgb2Ygc2VyaWFsaXppbmcgb3VyIGNv bnRyb2wgcmVxdWVzdHMgdmlhIFNEUC93aGF0ZXZlciBmb3JtYXQgYW5kIGhvcGluZyB0aGF0IGl0 IHdvcmtlZD8NCj4+Pg0KPj4gVGhhdCdzIGEgZ3JlYXQgcXVlc3Rpb24uIEhhdmUgeW91IHJlYWQg dGhlIENVLVJUQ1dFQiBwcm9wb3NhbD8gSXMgaXQgYW55IGNsb3NlciB0byB3aGF0IHlvdSBpbWFn aW5lZCB0aGUgUlRDV0VCIEFQSSBtaWdodCBiZT8NCj4NCj4gTXkgIk5vUGxhbiBKUyBBUEkiIHBy b3Bvc2FsIGFsc28gYWxsb3dzIGNvbnRyb2wgb2YgY29tcG9uZW50cyB3aXRob3V0IHNlcmlhbGl6 ZSBjb250cm9sIHZpYSBhIGZvcm1hdCwgaWYgdGhlIEpTIGNob29zZXMgdG8gZG8gc28gKFNEUCBp cyBzdGlsbCB0aGVyZSBpZiBKUyB3YW50cykuIMKgSXQgb25seSBkb2VzIHNvIGZvciBtZWRpYSBz dHJlYW1zLCBub3QgZm9yIHRyYW5zcG9ydHMsIGJ1dCBpdCBhbGxvd3MgaW5jcmVtZW50YWwgaW1w cm92ZW1lbnQgdG8gdGhlIEFQSS4NCg0KU28sIElGIHdlIGRlY2lkZSB0byByZW1vdmUgU0RQIGFu ZCBPZmZlci9BbnN3ZXIsIHdlJ2xsIGVuZCB1cCBhcmd1aW5nIGFib3V0ICJQbGFuIEMoVSkgdnMg Tm8gUGxhbiI/IDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From pthatcher@google.com Wed Jun 19 12:50:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E99721F9F08 for ; Wed, 19 Jun 2013 12:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1B-SVuvScDq for ; Wed, 19 Jun 2013 12:50:54 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id BF60221F9F02 for ; Wed, 19 Jun 2013 12:50:54 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz11so5518678pad.2 for ; Wed, 19 Jun 2013 12:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ykxt2CxNoyfbo3sFAwhwZ2K4VGcuWnS/ehE9Tr6NUM0=; b=gfooYeKF2xpvhtly7XuPSl3QWEDj093E9U3ez37YFh2o+G6oFM+S4fcW06w3CHwFKW E0OMGdk1rYvkFv3CdjcGD1XGV/BZWm/kONajvUuQSfd5ahuuoiDdDjISPwJd1xOTkwrH Y7nTnG4HcNfbi6C9MQTwJppOcOpNte+xmNHZS8kypWy90G5gKRlR7qyByY6WISMBXMAu /bjT4vz+1jwsqCbqsdFLBlii/M/pMOzSv0Gw8pDIe5k4D69bn1ZIhcodOx7k0AgdQ1rJ CdkeWy2IIv+KsdGQ+mYK3Hug7ye8WeRrt17z224Ymgup3F1Oc+f0MIMusjNcwUWfqaqm AmFQ== 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=Ykxt2CxNoyfbo3sFAwhwZ2K4VGcuWnS/ehE9Tr6NUM0=; b=KGz8X8I2HUuoGKRnE+JbcvDTmn0y9X9aQFEIF0+LtHD3cw/fYEMyVTYYvuaODVYkLC iL39Rx11RQCgMd4gkmesuhY7ktFZQk/1Zt+Kwj6hVC0cvRgflnt70FE7inl01W+UJEwQ mdbCsiJYOH+BsK3uzY3PevSv5cYeELwqYHtyl8yNtyIrpRgJ3SJp6JyvTGmSgI59NUWm lwxIpl+/2ohZz+HNK7cYfm9HFptkYdBYRH8bzcK0lDHnaxe2imP2EHn4vejJbmu996VX /xynntno/OJSkBHd3pX/+urI/rPOd1sV1nATQ9Q594Ye8Ss9p55oBM0C8JQ2SYU/Ty8x cVzQ== X-Received: by 10.66.120.164 with SMTP id ld4mr8223495pab.187.1371671454502; Wed, 19 Jun 2013 12:50:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 12:50:13 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B1680@ESESSMB209.ericsson.se> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <7594FB04B1934943A5C02806D1A2204B1C3B1680@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Wed, 19 Jun 2013 12:50:13 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b0721cecb683804df87250c X-Gm-Message-State: ALoCoQkldFuKS7+thUUA/J4D1ksns6Bv55ydMBVdRi9jj9GU9hmsy9tbFvIykPmbZyzwCOO0boORd1qMvo9z6blj6KNY/XZCxg4PWi+iE/H+0u5zc5hvJXi2awIMQlI9DGfH383VzxK/keIucrqgu/OckOGi67Q3SeEIXC9PVl/s5riNqFLlmStKne8YRihshLYfINl6YrDw Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 19:50:55 -0000 --047d7b0721cecb683804df87250c Content-Type: text/plain; charset=UTF-8 On Wed, Jun 19, 2013 at 12:47 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>> Why aren't we using the JavaScript object model for control of > components instead of serializing our control requests via SDP/whatever > format and hoping that it worked? > >>> > >> That's a great question. Have you read the CU-RTCWEB proposal? Is it > any closer to what you imagined the RTCWEB API might be? > > > > My "NoPlan JS API" proposal also allows control of components without > serialize control via a format, if the JS chooses to do so (SDP is still > there if JS wants). It only does so for media streams, not for transports, > but it allows incremental improvement to the API. > > So, IF we decide to remove SDP and Offer/Answer, we'll end up arguing > about "Plan C(U) vs No Plan"? :) > > I think we already are :). > Regards, > > Christer > > --047d7b0721cecb683804df87250c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Wed, Jun 19, 2013 at 12:47 PM, Christer Holmberg <= christer.holmberg@ericsson.com> wrote:
    Hi,

    >>> Why aren't we using the JavaScript object model for contro= l of components instead of serializing our control requests via SDP/whateve= r format and hoping that it worked?
    >>>
    >> That's a great question. Have you read the CU-RTCWEB proposal?= Is it any closer to what you imagined the RTCWEB API might be?
    >
    > My "NoPlan JS API" proposal also allows control of component= s without serialize control via a format, if the JS chooses to do so (SDP i= s still there if JS wants). =C2=A0It only does so for media streams, not fo= r transports, but it allows incremental improvement to the API.

    So, IF we decide to remove SDP and Offer/Answer, we'll end up arg= uing about "Plan C(U) vs No Plan"? :)


    I think we already are :).
    = =C2=A0
    Regards,

    Christer


    --047d7b0721cecb683804df87250c-- From robin@hookflash.com Wed Jun 19 13:08:25 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B3C21E8051 for ; Wed, 19 Jun 2013 13:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7Hnk9vh9v9o for ; Wed, 19 Jun 2013 13:08:22 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id B0D2F21F9FEA for ; Wed, 19 Jun 2013 13:08:17 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id 16so6470199obc.12 for ; Wed, 19 Jun 2013 13:08:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=PrFAzWiEVlfGfguUomuIc3UuA/y/SUfDhIQuK4hYXy0=; b=E+w3yaIHGs1EjVdOddcsFAF1QjlqbG1K5QKQ51mHkJM3ZG8s5nvX19qmdum6UgZU6/ NxRpTbP2pPHq2QnAIXnmh2oCD3aAiu8BtQaoJxmN6yopN1pAblVFU7rsgzjmeVYb9sfB cUFsHlNa0DLjcOz9dDYaM6CO6vhlNPqcToUDLRmmMBgW/N7vY88FNJRvHDRbSCVyo/4X 7fVr04bvrIE3YJG2/evqa0Vn14wwgZwolbJFK/r3M0/ZlZKCeMXg/KW4oMdizcPL1VRt 2yC2KMDN3p77yPhJ/a9Bp7OfE/9InzR+YRq5RHb4GUfbBEEzqgg8bJID9HDv5qv+aHtN y3lA== X-Received: by 10.60.46.225 with SMTP id y1mr2851026oem.17.1371672495852; Wed, 19 Jun 2013 13:08:15 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id c10sm26424241oej.1.2013.06.19.13.08.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 13:08:14 -0700 (PDT) Message-ID: <51C20FAA.4050701@hookflash.com> Date: Wed, 19 Jun 2013 16:08:10 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Matthew Kaufman References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> In-Reply-To: <51C1F5ED.9090308@matthew.at> Content-Type: multipart/alternative; boundary="------------060701040305070407010409" X-Gm-Message-State: ALoCoQnGTtkEJ5VQtCBEeD9wGriezhWfx6ofuyLoU1BpVWZ3w5GmkhweLDM5i0ZVpL2L+qzT86o7 Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 20:08:25 -0000 This is a multi-part message in MIME format. --------------060701040305070407010409 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Yes, I have looked at CU-RTCWeb. It is definitely closer and uses object models rather than serialization -- a definite step in the right direction. Should anyone take up the effort to propose another workable alternative to this current SDP situation (or an incremental improvement approach), I would recommend they read it for inspiration. One thing that is missing for CU-RTCWeb is the JavaScript shim that proves that the SDP / SIP folks can produce a reasonable implementation for the simple API they do need to interface with SIP/SDP based devices and infrastructure. I know it shouldn't be Skype job to produce that shim but I don't think anyone will adopt anything unless it's demonstrably easy for the SIP world (unless I misunderstand their objections). -Robin > Matthew Kaufman > 19 June, 2013 2:18 PM > On 6/19/2013 11:05 AM, Robin Raymond wrote: > That's a great question. Have you read the CU-RTCWEB proposal? Is it > any closer to what you imagined the RTCWEB API might be? > > Matthew Kaufman > Robin Raymond > 19 June, 2013 2:05 PM > > Why aren't we using the JavaScript object model for control of > components instead of serializing our control requests via > SDP/whatever format and hoping that it worked? > > -Robin > > > Peter Thatcher > 19 June, 2013 12:49 PM > I asked "is there something that can't be done without sufficient SDP > munging"? You answered "I have something that can be done with > sufficient SDP munging". OK. But do you have something that *can't* > be done with SDP munging? > > If there's nothing that can't be done with SDP munging, then this > whole thread boils down to "give us an API that has the same amount of > control as the current one, but without requiring SDP munging to do > advanced things". And if that's is what is desired, then at least it > can be clear and concise. > > > > > > Matthew Kaufman > 19 June, 2013 12:36 PM > I provided a use case that, unless one wants to write a bunch of > SDP-munging JS state machine cannot be done. > > The problem is that such use cases are either 1) ignored or 2) > dismissed because of course if one writes said JS, they are possible > with the current API > > Matthew Kaufman > > (Sent from my iPhone) > > On Jun 19, 2013, at 9:28 AM, Peter Thatcher > wrote: > >> I might be wrong, but I tried reading and understanding your whole >> email, and it seems to come down to "I don't want to use SDP or a >> different (JSON) form of SDP". That's a fine thing to request, but >> why don't you just say that? It would save everyone a lot of reading >> and confusion to be more concise. >> >> Or, if you have specific things you'd like to do but can't, what are >> they? I think that would help me, and others, understand more >> easily. Use cases would be helpful. >> >> On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond > > wrote: >> >> >> The trouble is not that we can choose to send whatever we want >> over the wire. I know we can. If the WebRTC API is left with SDP >> as it stands, I'll dissect the SDP from the browser, reinterpret >> and reconstruct on the SDP on the remote side. That is NOT the issue. >> >> The summary of what I want/believe: >> 1) I want as close to raw access to RTP/ICE streams, media, >> sources, outputs, codecs as viable. Obviously doing the actual >> transmission, encoding/decoding from JS is not feasible (yet), >> nor is secure [ICE must occur for mutual agreement to exchange >> data between peers], but having controls for how these components >> are wired together is extremely feasible from JS and would allow >> immensely powerful apps to be produced from JS. >> >> >> What would you like to do that you can't do via SDP right now? You >> said this isn't just about working through SDP. But I don't see >> anything concrete you can't do right now with sufficient SDP >> parsing/building/munging/hackery. >> >> 2) I don't want my primary interface to control media/RTP engines >> to be via obtaining or providing SDPs to the browser (or any >> alternative serialized format); especially given that SDP >> requires a round trip offer/answer to the remote party to affect >> change (e.g. it's entirely possible to do that stateless and >> one-sided). The SPD interface API is a monolithic do-everything >> serialized format to control an engine but extremely >> badly/poorly/short sighted (regardless if it is SDP or whatever >> instead), and it's wholly unneeded. >> >> >> Short summary: "I don't want to use SDP". Right? >> >> 3) I don't want a replacement for SDP with another more "pretty" >> format like JSON. >> >> >> Short summary: "I don't want to use SDP or a different syntax for >> SDP". Right? >> >> 4) I want no specified requirement from the browser to have any >> particular form of media negotiation API requirement what-so-ever >> (regardless if I can opt to substitute with my own format on the >> wire or not) >> >> >> Short summary: "I don't want to use SDP or a different syntax for >> SDP". Right? >> >> 5) Using SDP with offer/answer build into the browser binary is a >> horribly BAD technical choice (even for SIP folks) and must be >> stopped, see: >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html >> >> >> Short summary: "I don't want to use SDP". Right? >> >> >> >> I too want to understand the rational for keeping something as >> bad as SDP with offer/answer as the primary mechanism for >> controlling the media components and interaction to those >> component and more importantly, I'd too would like to open debate >> to agreeing or not to provide a lower layer API rather than a >> media negotiation API as a complete substitute alternative to SDP >> with offer/answer. >> >> If we can agree that it's far superior to have a lower level >> media/RTC component API rather than a media negotiation API, then >> we can propose what that API could look like (and there are >> people who have already have starting proposals). I'd throw my >> hat in the ring to propose such and API if necessary as I've >> written such engines from scratch before. But I don't want to >> waste time proposing ore reviewing such an API which will be >> summarily dismissed because people are so stuck on requiring a >> media negotiation API built into the browser binary, and >> specifically SDP with offer/answer in this case. >> >> >> >> The WG may dislike and reject your proposal, but there's a bit of >> truth to the old mathematically incorrect sports adage "you miss 100% >> of the shots you don't take". >> >> >> Anyone who argues that they need/want that simple SDP media >> negotiation API must understand that a lower level API would >> allow a wrapper API to produce the same WebRTC API the have today >> but be built entirely from JavaScript >> >> >> That depends on how low-level you go. If you go too low-level, it >> becomes infeasible to do things correctly and performantly in JavaScript. >> >> upon a lower level API. Thus they can have their "just add-milk" >> baking API. But those of us who need control of the raw >> ingredients beyond the "just add milk" can still innovate. >> >> -Robin >> >> >>> >>> Peter Thatcher >>> 19 June, 2013 2:49 AM >>> Correct my if I'm wrong, but the API already leaves what goes >>> over the wire completely up to the JS app. So we couldn't >>> re-open a debate of "SDP or not SDP" for the wire format, >>> because there's nothing to debate. We already decided it would >>> be left to the JS to decide. The only thing left to debate is >>> the API. >>> >>> Or am I wrong? >>> >>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> Christer Holmberg >>> 19 June, 2013 2:34 AM >>> Hi, >>> We need to be very clear what we talk about, or some people are >>> always going to be confused :) >>> So, AFAIK, the discussion is about SDP O/A usage in the API, >>> only in the API, and nowhere but the API. >>> Whatever people us on the wire is outside the scope. >>> Right? >>> Regards, >>> Christer >>> >>> >>> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com >>> ) >>> >>> -----Original Message----- >>> *From:* Peter Thatcher [pthatcher@google.com >>> ] >>> *To:* Martin Thomson [martin.thomson@gmail.com >>> ] >>> *CC:* rtcweb@ietf.org [rtcweb@ietf.org >>> ] >>> *Subject:* Re: [rtcweb] Requesting "SDP or not SDP" debate to be >>> re-opened >>> Martin, you're right; that was overly harsh of me. Adam, I >>> apologize. I'll be civil in the future. >>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> Peter Thatcher >>> 19 June, 2013 1:36 AM >>> Martin, you're right; that was overly harsh of me. Adam, I >>> apologize. I'll be civil in the future. >>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> Martin Thomson >>> 18 June, 2013 6:25 PM >>> I agree with Peter, except for this bit: >>> >>> Adam is much harder to confuse than you think, or than he professes. >>> >>> Speaking of burning it all down and starting over. If you want a >>> house-related analogy, that's not quite correct. It's refusing to >>> build an extension because the old house, while legally fit for >>> habitation, is falling down around your ears. Since you only need >>> foundations, it's not that big a job (though I'll grant you that >>> it's >>> bigger than many people realize, even with that smaller scope). >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> Peter Thatcher >>> 18 June, 2013 6:16 PM >>> Adam, I think you're confused. As Ted pointed out, there are >>> two different uses of SDP: 1. as a control surface, 2. as a >>> message format for signalling. SDPNG was trying to replace SDP >>> for #2. While I believe this thread was started entirely >>> focused on #1. So you're talking about different things. >>> >>> So far the only time spent on trying to replace or avoid SDP for >>> #1 has been "comment 22", and to a lesser extent the proposal I >>> just made for adding 2 methods to PeerConnection >>> (createLocalStream and createRemoteStream). I think it's >>> incorrect to conclude that we should never try to improve #1 >>> just because other in the past failed to replace #2. They're >>> very different. >>> >>> I also don't think we should burn down WebRTC and start over, >>> but despite what some seem to think, we don't have to choose >>> between "burn it down" and "never improve it". There are many >>> options other than the two extremes. >>> >>> >>> >>> By the way, a gentle reminder: SDP is not the only way to do #2. >>> I work on a rather large system almost entirely build around >>> Jingle, without a hint of SDP, and it works just fine. Much >>> better than SDP would have, I think. Just because SDPNG didn't >>> work out doesn't mean there will never be any way other to do >>> signalling than SDP. >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > Peter Thatcher > 19 June, 2013 12:28 PM > I might be wrong, but I tried reading and understanding your whole > email, and it seems to come down to "I don't want to use SDP or a > different (JSON) form of SDP". That's a fine thing to request, but > why don't you just say that? It would save everyone a lot of reading > and confusion to be more concise. > > Or, if you have specific things you'd like to do but can't, what are > they? I think that would help me, and others, understand more easily. > Use cases would be helpful. > > On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond > wrote: > > > The trouble is not that we can choose to send whatever we want > over the wire. I know we can. If the WebRTC API is left with SDP > as it stands, I'll dissect the SDP from the browser, reinterpret > and reconstruct on the SDP on the remote side. That is NOT the issue. > > The summary of what I want/believe: > 1) I want as close to raw access to RTP/ICE streams, media, > sources, outputs, codecs as viable. Obviously doing the actual > transmission, encoding/decoding from JS is not feasible (yet), nor > is secure [ICE must occur for mutual agreement to exchange data > between peers], but having controls for how these components are > wired together is extremely feasible from JS and would allow > immensely powerful apps to be produced from JS. > > > What would you like to do that you can't do via SDP right now? You > said this isn't just about working through SDP. But I don't see > anything concrete you can't do right now with sufficient SDP > parsing/building/munging/hackery. > > 2) I don't want my primary interface to control media/RTP engines > to be via obtaining or providing SDPs to the browser (or any > alternative serialized format); especially given that SDP requires > a round trip offer/answer to the remote party to affect change > (e.g. it's entirely possible to do that stateless and one-sided). > The SPD interface API is a monolithic do-everything serialized > format to control an engine but extremely badly/poorly/short > sighted (regardless if it is SDP or whatever instead), and it's > wholly unneeded. > > > Short summary: "I don't want to use SDP". Right? > > 3) I don't want a replacement for SDP with another more "pretty" > format like JSON. > > > Short summary: "I don't want to use SDP or a different syntax for > SDP". Right? > > 4) I want no specified requirement from the browser to have any > particular form of media negotiation API requirement what-so-ever > (regardless if I can opt to substitute with my own format on the > wire or not) > > > Short summary: "I don't want to use SDP or a different syntax for > SDP". Right? > > 5) Using SDP with offer/answer build into the browser binary is a > horribly BAD technical choice (even for SIP folks) and must be > stopped, see: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html > > > Short summary: "I don't want to use SDP". Right? > > > > I too want to understand the rational for keeping something as bad > as SDP with offer/answer as the primary mechanism for controlling > the media components and interaction to those component and more > importantly, I'd too would like to open debate to agreeing or not > to provide a lower layer API rather than a media negotiation API > as a complete substitute alternative to SDP with offer/answer. > > If we can agree that it's far superior to have a lower level > media/RTC component API rather than a media negotiation API, then > we can propose what that API could look like (and there are people > who have already have starting proposals). I'd throw my hat in the > ring to propose such and API if necessary as I've written such > engines from scratch before. But I don't want to waste time > proposing ore reviewing such an API which will be summarily > dismissed because people are so stuck on requiring a media > negotiation API built into the browser binary, and specifically > SDP with offer/answer in this case. > > > > The WG may dislike and reject your proposal, but there's a bit of > truth to the old mathematically incorrect sports adage "you miss 100% > of the shots you don't take". > > > Anyone who argues that they need/want that simple SDP media > negotiation API must understand that a lower level API would allow > a wrapper API to produce the same WebRTC API the have today but be > built entirely from JavaScript > > > That depends on how low-level you go. If you go too low-level, it > becomes infeasible to do things correctly and performantly in JavaScript. > > upon a lower level API. Thus they can have their "just add-milk" > baking API. But those of us who need control of the raw > ingredients beyond the "just add milk" can still innovate. > > -Robin > > >> Peter Thatcher >> 19 June, 2013 2:49 AM >> Correct my if I'm wrong, but the API already leaves what goes >> over the wire completely up to the JS app. So we couldn't >> re-open a debate of "SDP or not SDP" for the wire format, because >> there's nothing to debate. We already decided it would be left >> to the JS to decide. The only thing left to debate is the API. >> >> Or am I wrong? >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> Christer Holmberg >> 19 June, 2013 2:34 AM >> Hi, >> We need to be very clear what we talk about, or some people are >> always going to be confused :) >> So, AFAIK, the discussion is about SDP O/A usage in the API, only >> in the API, and nowhere but the API. >> Whatever people us on the wire is outside the scope. >> Right? >> Regards, >> Christer >> >> >> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com >> ) >> >> -----Original Message----- >> *From:* Peter Thatcher [pthatcher@google.com >> ] >> *To:* Martin Thomson [martin.thomson@gmail.com >> ] >> *CC:* rtcweb@ietf.org [rtcweb@ietf.org >> ] >> *Subject:* Re: [rtcweb] Requesting "SDP or not SDP" debate to be >> re-opened >> Martin, you're right; that was overly harsh of me. Adam, I >> apologize. I'll be civil in the future. >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> Peter Thatcher >> 19 June, 2013 1:36 AM >> Martin, you're right; that was overly harsh of me. Adam, I >> apologize. I'll be civil in the future. >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> Martin Thomson >> 18 June, 2013 6:25 PM >> I agree with Peter, except for this bit: >> >> Adam is much harder to confuse than you think, or than he professes. >> >> Speaking of burning it all down and starting over. If you want a >> house-related analogy, that's not quite correct. It's refusing to >> build an extension because the old house, while legally fit for >> habitation, is falling down around your ears. Since you only need >> foundations, it's not that big a job (though I'll grant you that it's >> bigger than many people realize, even with that smaller scope). >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> Peter Thatcher >> 18 June, 2013 6:16 PM >> Adam, I think you're confused. As Ted pointed out, there are two >> different uses of SDP: 1. as a control surface, 2. as a message >> format for signalling. SDPNG was trying to replace SDP for #2. >> While I believe this thread was started entirely focused on #1. >> So you're talking about different things. >> >> So far the only time spent on trying to replace or avoid SDP for >> #1 has been "comment 22", and to a lesser extent the proposal I >> just made for adding 2 methods to PeerConnection >> (createLocalStream and createRemoteStream). I think it's >> incorrect to conclude that we should never try to improve #1 just >> because other in the past failed to replace #2. They're very >> different. >> >> I also don't think we should burn down WebRTC and start over, but >> despite what some seem to think, we don't have to choose between >> "burn it down" and "never improve it". There are many options >> other than the two extremes. >> >> >> >> By the way, a gentle reminder: SDP is not the only way to do #2. >> I work on a rather large system almost entirely build around >> Jingle, without a hint of SDP, and it works just fine. Much >> better than SDP would have, I think. Just because SDPNG didn't >> work out doesn't mean there will never be any way other to do >> signalling than SDP. >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > --------------060701040305070407010409 Content-Type: multipart/related; boundary="------------020306040809030204030004" --------------020306040809030204030004 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
    Yes, I have looked at CU-RTCWeb. It is definitely closer and uses object models rather than serialization -- a definite step in the right direction. Should anyone take up the effort to propose another workable alternative to this current SDP situation (or an incremental improvement approach), I would recommend they read it for inspiration.

    One thing that is missing for CU-RTCWeb is the JavaScript shim that proves that the SDP / SIP folks can produce a reasonable implementation for the simple API they do need to interface with SIP/SDP based devices and infrastructure. I know it shouldn't be Skype job to produce that shim but I don't think anyone will adopt anything unless it's demonstrably easy for the SIP world (unless I misunderstand their objections).

    -Robin


    19 June, 2013 2:18 PM
    On 6/19/2013 11:05 AM, Robin Raymond wrote:
    That's a great question. Have you read the CU-RTCWEB proposal? Is it any closer to what you imagined the RTCWEB API might be?

    Matthew Kaufman
    19 June, 2013 2:05 PM

    Why aren't we using the JavaScript object model for control of components instead of serializing our control requests via SDP/whatever format and hoping that it worked?

    -Robin


    19 June, 2013 12:49 PM
    I asked "is there something that can't be done without sufficient SDP munging"?  You answered "I have something that can be done with sufficient SDP munging".   OK.  But do you have something that *can't* be done with SDP munging?

    If there's nothing that can't be done with SDP munging, then this whole thread boils down to "give us an API that has the same amount of control as the current one, but without requiring SDP munging to do advanced things".  And if that's is what is desired, then at least it can be clear and concise.





    19 June, 2013 12:36 PM
    I provided a use case that, unless one wants to write a bunch of SDP-munging JS state machine cannot be done.

    The problem is that such use cases are either 1) ignored or 2) dismissed because of course if one writes said JS, they are possible with the current API

    Matthew Kaufman

    (Sent from my iPhone)

    On Jun 19, 2013, at 9:28 AM, Peter Thatcher <pthatcher@google.com> wrote:

    I might be wrong, but I tried reading and understanding your whole email, and it seems to come down to "I don't want to use SDP or a different (JSON) form of SDP".  That's a fine thing to request, but why don't you just say that?  It would save everyone a lot of reading and confusion to be more concise.  

    Or, if you have specific things you'd like to do but can't, what are they?  I think that would help me, and others, understand more easily.  Use cases would be helpful.

    On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond <robin@hookflash.com> wrote:

    The trouble is not that we can choose to send whatever we want over the wire. I know we can. If the WebRTC API is left with SDP as it stands, I'll dissect the SDP from the browser, reinterpret and reconstruct on the SDP on the remote side. That is NOT the issue.

    The summary of what I want/believe:
    1) I want as close to raw access to RTP/ICE streams, media, sources, outputs, codecs as viable. Obviously doing the actual transmission, encoding/decoding from JS is not feasible (yet), nor is secure [ICE must occur for mutual agreement to exchange data between peers], but having controls for how these components are wired together is extremely feasible from JS and would allow immensely powerful apps to be produced from JS.

    What would you like to do that you can't do via SDP right now?  You said this isn't just about working through SDP.  But I don't see anything concrete you can't do right now with sufficient SDP parsing/building/munging/hackery.

     
    2) I don't want my primary interface to control media/RTP engines to be via obtaining or providing SDPs to the browser (or any alternative serialized format); especially given that SDP requires a round trip offer/answer to the remote party to affect change (e.g. it's entirely possible to do that stateless and one-sided). The SPD interface API is a monolithic do-everything serialized format to control an engine but extremely badly/poorly/short sighted (regardless if it is SDP or whatever instead), and it's wholly unneeded.

    Short summary: "I don't want to use SDP".  Right?

    3) I don't want a replacement for SDP with another more "pretty" format like JSON.

    Short summary: "I don't want to use SDP or a different syntax for SDP".  Right?

    4) I want no specified requirement from the browser to have any particular form of media negotiation API requirement what-so-ever (regardless if I can opt to substitute with my own format on the wire or not)

    Short summary: "I don't want to use SDP or a different syntax for SDP".  Right?
     
    5) Using SDP with offer/answer build into the browser binary is a horribly BAD technical choice (even for SIP folks) and must be stopped, see: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html

    Short summary: "I don't want to use SDP".  Right?
     


    I too want to understand the rational for keeping something as bad as SDP with offer/answer as the primary mechanism for controlling the media components and interaction to those component and more importantly, I'd too would like to open debate to agreeing or not to provide a lower layer API rather than a media negotiation API as a complete substitute alternative to SDP with offer/answer.

    If we can agree that it's far superior to have a lower level media/RTC component API rather than a media negotiation API, then we can propose what that API could look like (and there are people who have already have starting proposals). I'd throw my hat in the ring to propose such and API if necessary as I've written such engines from scratch before. But I don't want to waste time proposing ore reviewing such an API which will be summarily dismissed because people are so stuck on requiring a media negotiation API built into the browser binary, and specifically SDP with offer/answer in this case.


    The WG may dislike and reject your proposal, but there's a bit of truth to the old mathematically incorrect sports adage "you miss 100% of the shots you don't take".


    Anyone who argues that they need/want that simple SDP media negotiation API must understand that a lower level API would allow a wrapper API to produce the same WebRTC API the have today but be built entirely from JavaScript

    That depends on how low-level you go.  If you go too low-level, it becomes infeasible to do things correctly and performantly in JavaScript.
     
    upon a lower level API. Thus they can have their "just add-milk" baking API. But those of us who need control of the raw ingredients beyond the "just add milk" can still innovate.

    -Robin


    <compose-unknown-contact.jpg>
    19 June, 2013 2:49 AM
    Correct my if I'm wrong, but the API already leaves what goes over the wire completely up to the JS app.  So we couldn't re-open a debate of "SDP or not SDP" for the wire format, because there's nothing to debate.  We already decided it would be left to the JS to decide.  The only thing left to debate is the API.  

    Or am I wrong?




    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    <compose-unknown-contact.jpg>
    19 June, 2013 2:34 AM
    Hi,
     
    We need to be very clear what we talk about, or some people are always going to be confused :)
     
    So, AFAIK, the discussion is about SDP O/A usage in the API, only in the API, and nowhere but the API.
     
    Whatever people us on the wire is outside the scope.
     
    Right?
     
    Regards,
     
    Christer
     


    Sent from Windows using TouchDown (www.nitrodesk.com)
    -----Original Message-----
    From: Peter Thatcher [pthatcher@google.com]
    To: Martin Thomson [martin.thomson@gmail.com]
    CC: rtcweb@ietf.org [rtcweb@ietf.org]
    Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
    Martin, you're right; that was overly harsh of me.  Adam, I apologize.  I'll be civil in the future.



    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    <compose-unknown-contact.jpg>
    19 June, 2013 1:36 AM
    Martin, you're right; that was overly harsh of me.  Adam, I apologize.  I'll be civil in the future.



    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    <compose-unknown-contact.jpg>
    18 June, 2013 6:25 PM
    I agree with Peter, except for this bit:

    Adam is much harder to confuse than you think, or than he professes.

    Speaking of burning it all down and starting over. If you want a
    house-related analogy, that's not quite correct. It's refusing to
    build an extension because the old house, while legally fit for
    habitation, is falling down around your ears. Since you only need
    foundations, it's not that big a job (though I'll grant you that it's
    bigger than many people realize, even with that smaller scope).
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    <compose-unknown-contact.jpg>
    18 June, 2013 6:16 PM
    Adam, I think you're confused.  As Ted pointed out, there are two different uses of SDP: 1.  as a control surface, 2. as a message format for signalling.  SDPNG was trying to replace SDP for #2.  While I believe this thread was started entirely focused on #1.  So you're talking about different things.

    So far the only time spent on trying to replace or avoid SDP for #1 has been "comment 22", and to a lesser extent the proposal I just made for adding 2 methods to PeerConnection (createLocalStream and createRemoteStream).   I think it's incorrect to conclude that we should never try to improve #1 just because other in the past failed to replace #2.  They're very different.

    I also don't think we should burn down WebRTC and start over, but despite what some seem to think, we don't have to choose between "burn it down" and "never improve it".  There are many options other than the two extremes.



    By the way, a gentle reminder: SDP is not the only way to do #2.  I work on a rather large system almost entirely build around Jingle, without a hint of SDP, and it works just fine.  Much better than SDP would have, I think.  Just because SDPNG didn't work out doesn't mean there will never be any way other to do signalling than SDP.




    _______________________________________________
    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
    19 June, 2013 12:28 PM
    I might be wrong, but I tried reading and understanding your whole email, and it seems to come down to "I don't want to use SDP or a different (JSON) form of SDP".  That's a fine thing to request, but why don't you just say that?  It would save everyone a lot of reading and confusion to be more concise.  

    Or, if you have specific things you'd like to do but can't, what are they?  I think that would help me, and others, understand more easily.  Use cases would be helpful.

    On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond <robin@hookflash.com> wrote:

    The trouble is not that we can choose to send whatever we want over the wire. I know we can. If the WebRTC API is left with SDP as it stands, I'll dissect the SDP from the browser, reinterpret and reconstruct on the SDP on the remote side. That is NOT the issue.

    The summary of what I want/believe:
    1) I want as close to raw access to RTP/ICE streams, media, sources, outputs, codecs as viable. Obviously doing the actual transmission, encoding/decoding from JS is not feasible (yet), nor is secure [ICE must occur for mutual agreement to exchange data between peers], but having controls for how these components are wired together is extremely feasible from JS and would allow immensely powerful apps to be produced from JS.

    What would you like to do that you can't do via SDP right now?  You said this isn't just about working through SDP.  But I don't see anything concrete you can't do right now with sufficient SDP parsing/building/munging/hackery.

     
    2) I don't want my primary interface to control media/RTP engines to be via obtaining or providing SDPs to the browser (or any alternative serialized format); especially given that SDP requires a round trip offer/answer to the remote party to affect change (e.g. it's entirely possible to do that stateless and one-sided). The SPD interface API is a monolithic do-everything serialized format to control an engine but extremely badly/poorly/short sighted (regardless if it is SDP or whatever instead), and it's wholly unneeded.

    Short summary: "I don't want to use SDP".  Right?

    3) I don't want a replacement for SDP with another more "pretty" format like JSON.

    Short summary: "I don't want to use SDP or a different syntax for SDP".  Right?

    4) I want no specified requirement from the browser to have any particular form of media negotiation API requirement what-so-ever (regardless if I can opt to substitute with my own format on the wire or not)

    Short summary: "I don't want to use SDP or a different syntax for SDP".  Right?
     
    5) Using SDP with offer/answer build into the browser binary is a horribly BAD technical choice (even for SIP folks) and must be stopped, see: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html

    Short summary: "I don't want to use SDP".  Right?
     


    I too want to understand the rational for keeping something as bad as SDP with offer/answer as the primary mechanism for controlling the media components and interaction to those component and more importantly, I'd too would like to open debate to agreeing or not to provide a lower layer API rather than a media negotiation API as a complete substitute alternative to SDP with offer/answer.

    If we can agree that it's far superior to have a lower level media/RTC component API rather than a media negotiation API, then we can propose what that API could look like (and there are people who have already have starting proposals). I'd throw my hat in the ring to propose such and API if necessary as I've written such engines from scratch before. But I don't want to waste time proposing ore reviewing such an API which will be summarily dismissed because people are so stuck on requiring a media negotiation API built into the browser binary, and specifically SDP with offer/answer in this case.


    The WG may dislike and reject your proposal, but there's a bit of truth to the old mathematically incorrect sports adage "you miss 100% of the shots you don't take".


    Anyone who argues that they need/want that simple SDP media negotiation API must understand that a lower level API would allow a wrapper API to produce the same WebRTC API the have today but be built entirely from JavaScript

    That depends on how low-level you go.  If you go too low-level, it becomes infeasible to do things correctly and performantly in JavaScript.
     
    upon a lower level API. Thus they can have their "just add-milk" baking API. But those of us who need control of the raw ingredients beyond the "just add milk" can still innovate.

    -Robin


    19 June, 2013 2:49 AM
    Correct my if I'm wrong, but the API already leaves what goes over the wire completely up to the JS app.  So we couldn't re-open a debate of "SDP or not SDP" for the wire format, because there's nothing to debate.  We already decided it would be left to the JS to decide.  The only thing left to debate is the API.  

    Or am I wrong?




    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    19 June, 2013 2:34 AM
    Hi,
     
    We need to be very clear what we talk about, or some people are always going to be confused :)
     
    So, AFAIK, the discussion is about SDP O/A usage in the API, only in the API, and nowhere but the API.
     
    Whatever people us on the wire is outside the scope.
     
    Right?
     
    Regards,
     
    Christer
     


    Sent from Windows using TouchDown (www.nitrodesk.com)
    -----Original Message-----
    From: Peter Thatcher [pthatcher@google.com]
    To: Martin Thomson [martin.thomson@gmail.com]
    CC: rtcweb@ietf.org [rtcweb@ietf.org]
    Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
    Martin, you're right; that was overly harsh of me.  Adam, I apologize.  I'll be civil in the future.



    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    19 June, 2013 1:36 AM
    Martin, you're right; that was overly harsh of me.  Adam, I apologize.  I'll be civil in the future.



    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    18 June, 2013 6:25 PM
    I agree with Peter, except for this bit:

    Adam is much harder to confuse than you think, or than he professes.

    Speaking of burning it all down and starting over. If you want a
    house-related analogy, that's not quite correct. It's refusing to
    build an extension because the old house, while legally fit for
    habitation, is falling down around your ears. Since you only need
    foundations, it's not that big a job (though I'll grant you that it's
    bigger than many people realize, even with that smaller scope).
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    18 June, 2013 6:16 PM
    Adam, I think you're confused.  As Ted pointed out, there are two different uses of SDP: 1.  as a control surface, 2. as a message format for signalling.  SDPNG was trying to replace SDP for #2.  While I believe this thread was started entirely focused on #1.  So you're talking about different things.

    So far the only time spent on trying to replace or avoid SDP for #1 has been "comment 22", and to a lesser extent the proposal I just made for adding 2 methods to PeerConnection (createLocalStream and createRemoteStream).   I think it's incorrect to conclude that we should never try to improve #1 just because other in the past failed to replace #2.  They're very different.

    I also don't think we should burn down WebRTC and start over, but despite what some seem to think, we don't have to choose between "burn it down" and "never improve it".  There are many options other than the two extremes.



    By the way, a gentle reminder: SDP is not the only way to do #2.  I work on a rather large system almost entirely build around Jingle, without a hint of SDP, and it works just fine.  Much better than SDP would have, I think.  Just because SDPNG didn't work out doesn't mean there will never be any way other to do signalling than SDP.




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

    --------------020306040809030204030004 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------020306040809030204030004 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD40+NOqawPi74pn1CS0v7tdS3yzXljbTyz M6q2WeRCxHzcDOAAAMAACqs2lZGdOKlZs9A+E3wA+LHxZ8N3Hi/wl4f0e5sImljKjTLJSk6R xsVYFOPvjHf5TXi18Yqc+Vo9zCYD2tP2jkkUNW0fxf8ACPxhZ6F8RPB2mW1217CYZFsIYZUT zQA8cqRqwI4IYYIIBGK9DLsZCo3BHBmmAq0EpMb/AMN0fHT/AKHzUv8AvuP/AOJr1rQ7Hjfv e52cHw40jx/+0lo2ta5Y20nh3xELE31v9qxJDvs4oc7wMFvMUOBnB6HGTXzqxc8ZRlUjFxS7 /ofSUsHDCV4QnJSufo/8F/h5oPwy+GGg+G/Cr3unG3txLJLbPsF0R/rJZF5BYtkt39a8eEpT bk9z6CvTpxmqas4rS3mfCn7etx/wlvxi8DWNtrYvb22gm1Fo0RVSOy84hc/xFyYiwBHTcc9q 9rJqXO5TR43Es/Y+zpvsfNv/AAzb4v8A+frTf+//AP8AWr2vaRPmrSPafDFw8b2VndxyQXcE EVu4kUpJFIigFSDyrBlIIPQis7RtY7W3e59ceB/2kheWOm/D9rjS21LUohFJLqF+bCOzuSdu RJtYOZQSwUY53DIyK+erYGVKcmtuh9JRx9KahUlZytqjzv45f8E9dR0s33x0Hxl1LxFrWn3E Wr3Vvqtukdrd2VsFc28Yj+aJVjQgfeUDg92rrw2LnQkqSj7r6o8bF04Yxuq5e/2f6Hjv/CwN a/6Ih4v/APBbJ/8AE17PsX3R5Ptn2Ob/AGsf+TlvGX/YUj/9EpWSOg8Y1P8A4/5Pqf5UpDju j7i0X/kYbT/rpbf+hivOW8Trj1+Z9tV6p5x//9k= --------------020306040809030204030004 Content-Type: image/jpeg; name="image.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="image.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9LNP0/T7jT7S4uNPtJpZbeKSSSSBHZ2KA kkkZJzVWIMqXVdDjuWjXw7ZPEjbTIII8nHUgbf61XKLmNyDTdFm8t00uxKSYIYWyDg9wcVLR R5v/AMJBrn/QWuv+/ppiPR9I/wCQRYf9esP/AKAKQHGzwSQXEluQWdHKDH8Rzx+dWSdzYwm2 t7eBiCYkRCfoAKllI8hoA7j+35oNPtLOyVQ0VtEryMM4OwZAH+NNITZluzyu0kjFndixbuSa Yja03xHcpMkN+VkR2C+ZgKVycc9sflSaHc4TyZv+eT/98mkM5n4gf8jrrH/Xx/7KtNbCe5z9 MRb0j/kLWH/X1D/6GKHsB9QVkan/2Q== --------------020306040809030204030004-- --------------060701040305070407010409-- From martin.thomson@gmail.com Wed Jun 19 13:15:56 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7009721F9C02 for ; Wed, 19 Jun 2013 13:15: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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPlWicejO5m6 for ; Wed, 19 Jun 2013 13:15:53 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 91F1721F8476 for ; Wed, 19 Jun 2013 13:15:52 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so4810875wes.17 for ; Wed, 19 Jun 2013 13:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ir3QprhUMkQJfMSKoSje/OyEEnDGRy39yH0T1Jdg2kQ=; b=bHB1GKzENHMNwXfLVTrLo7lFKpzq8Q+4s7bokDf1v0LjasrlACm6SHBXfgAoS6eFaP J8JSro4Yh0+/AUyRledNWJb3dSev7CJ+PkwQ83XIpQ+UZD929t2CghdIzbP3K7PpzPA0 cjlS7Fm3zTtJNXy60pRIbQGaZKYAXPdUTaNOXmv4Pp9VTzh+M2wXPPPTXbDbxJNChMgW kIH01WiRnJ1NITEJ1ukgkTSbM5pcxRLFKNwoSSdkuOuZrZ2gAVOs5LQp5ms9o9GdoUTE 5q6V79upK2NEth2Nhd7CaRsADhjevFwPtasnxHk+Ax9A4qwbphpbTrRpzQB2WNnhxCix 2Obw== MIME-Version: 1.0 X-Received: by 10.194.216.41 with SMTP id on9mr3604647wjc.3.1371672950008; Wed, 19 Jun 2013 13:15:50 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 19 Jun 2013 13:15:49 -0700 (PDT) In-Reply-To: <51C20FAA.4050701@hookflash.com> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> Date: Wed, 19 Jun 2013 13:15:49 -0700 Message-ID: From: Martin Thomson To: Robin Raymond Content-Type: multipart/alternative; boundary=089e01419e92eef1e804df877ef5 Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 20:15:56 -0000 --089e01419e92eef1e804df877ef5 Content-Type: text/plain; charset=UTF-8 On 19 June 2013 13:08, Robin Raymond wrote: > One thing that is missing for CU-RTCWeb is the JavaScript shim that proves > that the SDP / SIP folks can produce a reasonable implementation for the > simple API they do need to interface with SIP/SDP based devices and > infrastructure. I know it shouldn't be Skype job to produce that shim but I > don't think anyone will adopt anything unless it's demonstrably easy for > the SIP world (unless I misunderstand their objections). We sketched out some designs for this that indicated that it is at least feasible. It's not that easy though - prancer in particular complicates things considerably - and we managed to find more important things to spend time on before we could do anything significant. Full compliance with the specification, rather than just an SDP implementation, is not something that is easily replicated. --089e01419e92eef1e804df877ef5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On 1= 9 June 2013 13:08, Robin Raymond <robin@hookflash.com> wro= te:
    One thing that is missing for CU-RTCWeb is the JavaScript shim that=20 proves that the SDP / SIP folks can produce a reasonable implementation=20 for the simple API they do need to interface with SIP/SDP based devices=20 and infrastructure. I know it shouldn't be Skype job to produce that=20 shim but I don't think anyone will adopt anything unless it's=20 demonstrably easy for the SIP world (unless I misunderstand their=20 objections).

    We sket= ched out some designs for this that indicated that it is at least feasible.= =C2=A0 It's not that easy though - prancer in particular complicates th= ings considerably - and we managed to find more important things to spend t= ime on before we could do anything significant.=C2=A0 Full compliance with = the specification, rather than just an SDP implementation, is not something= that is easily replicated.
    --089e01419e92eef1e804df877ef5-- From ibc@aliax.net Wed Jun 19 14:23:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659BC21E80AC for ; Wed, 19 Jun 2013 14:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpFz-83NdKuy for ; Wed, 19 Jun 2013 14:23:06 -0700 (PDT) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2D06711E80DF for ; Wed, 19 Jun 2013 14:23:05 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id b4so3593485qen.0 for ; Wed, 19 Jun 2013 14:23:05 -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=3wwaZ2MrSS+SXsa/DTynWMjdGpavHytl5JluMo0tC+s=; b=mrJbsdJM+E5Ebkfav5fgSEE8dCi23vRd6BRTlOHSK43zcgYcU8SbyTaA0aGF9iK7UP plYgEUcsh5mvyCsvWoYeUwpVOO+xB3ADNkWl+dN0Nv0YxTuuhyd/vxSfzy8Pzk70uGYe dM1xqIi2mjvt7MPj2Lp0f2X/BxRH4pKPxBfPza7YoTB+E7TCtTqFoFSbQ2t/Ke7LHf9q X4U4Jg8Py9o5RD2mBNwqmZ1SuJ56T7mj2aqwujDsKLH2AZIil72tM5Z5lzMvsqvfYtNt jldK9rFLUcbVeS5Kx/xQ2otIUXrWDLO+iqQrJyFhSoeM/A5+wJaazBNL0oH0FG1QWbDO UHoA== X-Received: by 10.224.187.129 with SMTP id cw1mr5871723qab.68.1371676985451; Wed, 19 Jun 2013 14:23:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 14:22:44 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1EE64.1010109@matthew.at> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 19 Jun 2013 23:22:44 +0200 Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlKXuhZ5nAIscrF27tL0WqXEXyCZ3YHLra/k3oqj38OTaVpYfuJFl33ldgrfCATGL1YHTI+ Cc: "" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 21:23:10 -0000 2013/6/19 Peter Thatcher : > With my recent proposal (NoPlan JS API), you don't have to, at least not = for > media streams. You just tell the browser what to send with on the send > side, and then what to receive with on the receive side. My proposal doe= s > not cover transports, however. It's an incremental improvement that > relieves some of the pain, but not all. Hi Peter, may you could reply to my mail about NoPlan: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07871.html :) -- I=C3=B1aki Baz Castillo From ted.ietf@gmail.com Wed Jun 19 14:37:26 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05EC21F9F34 for ; Wed, 19 Jun 2013 14:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruytATlpexgI for ; Wed, 19 Jun 2013 14:37:26 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6F021F9F77 for ; Wed, 19 Jun 2013 14:37:25 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id ar20so14734103iec.21 for ; Wed, 19 Jun 2013 14:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HHttMPQt8RMaSWUtwwsUn5ae0SH2eqHsl3EG4OWePl8=; b=DgBiylgAC4aiP7EBM/gWt7RRLgdk9PnsXEyHeJ36LnKxr6p0OkBNK/SyN/v7VKW1nv vNvfIXQLdAj8C4UNKCwA+kzvo+X8I7hG5X+31OCjPgkYKRewYWItu5bHIdH/x3cC1hX8 WG4s1Xhyfoe3/XNZikaXUiTIIkv+G4eaccBfVQLbWPdG52MZ5ioIR0TMl9GuhaZaSXQo a/dUpI77kv3KSytyrt4mGqirwEZwr413+TmdOBpX2z5Yn0r3vMHqGbCaPxquIdfYnwQC qLo6DaIpP7pOgcFoEQoOD1Yzcgka4koSG/QKdvxJnnEXL9oiBNL9MxEmwh7gjGO9t0jN v9RA== MIME-Version: 1.0 X-Received: by 10.50.23.8 with SMTP id i8mr11055977igf.42.1371677835454; Wed, 19 Jun 2013 14:37:15 -0700 (PDT) Received: by 10.42.49.7 with HTTP; Wed, 19 Jun 2013 14:37:15 -0700 (PDT) In-Reply-To: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> Date: Wed, 19 Jun 2013 14:37:15 -0700 Message-ID: From: Ted Hardie To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=089e0153879420ef6104df88a239 Cc: rtcweb@ietf.org, "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Agenda time request for IETF 87 Berlin X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 21:37:27 -0000 --089e0153879420ef6104df88a239 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the request and for volunteering to provide input to the discussion. If there are others who would like to contribute to the discussion with presentations, it would be good to let the chairs/working group know now. thanks, Ted Hardie On Wed, Jun 19, 2013 at 12:23 PM, Hadriel Kaplan wrote: > > Howdy, > per the email below, I formally request agenda time to discuss - and reach > a conclusive vote on - whether to make SDES an MTI key exchange mechanism, > or not. > > I plan to present both sides of the argument with a set of pro/con slides. > I used to favor making SDES mandatory, but over time I've become less sure > if its benefits outweigh its drawbacks. Mostly though what I care about is > making a *decision* one way or the other, and moving on. > > I do *not* plan to present on DTLS-EKT at all, not even as a potential > alternative. I only plan to present on whether SDES should be MTI or not > for WebRTC implementations. > > I think this will take an hour at least, possibly longer. I can pretend > to claim it will take 15 minutes, but we all know that simply isn't true > unless someone disconnects the microphones in the room. I also expect two > or more other folks to want time to present on the same topic, so it'll > likely take even longer in total time. > > Lastly, I beg the chairs to make this agenda item topic (not necessarily > my presentation, but the general topic) the *first* agenda topic for > whichever meeting session it gets put in, so that we don't run out of time > on other topics and delay an SDES decision once again. > > -hadriel > > > On Jun 18, 2013, at 5:56 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > > Please request agenda time for > > Berlin and ensure to update any drafts or other material to actually > > take into account what actually has happened in the last 15 months. > > > --089e0153879420ef6104df88a239 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the request and for volunteering to provide input to the discuss= ion.=A0 If there are others who would like to contribute to the discussion = with presentations, it would be good to let the chairs/working group know n= ow.

    thanks,

    Ted Hardie

    On Wed, Jun= 19, 2013 at 12:23 PM, Hadriel Kaplan <hadriel.kaplan@oracle.com> wrote:

    Howdy,
    per the email below, I formally request agenda time to discuss - and reach = a conclusive vote on - whether to make SDES an MTI key exchange mechanism, = or not.

    I plan to present both sides of the argument with a set of pro/con slides. = =A0I used to favor making SDES mandatory, but over time I've become les= s sure if its benefits outweigh its drawbacks. =A0Mostly though what I care= about is making a *decision* one way or the other, and moving on.

    I do *not* plan to present on DTLS-EKT at all, not even as a potential alte= rnative. =A0I only plan to present on whether SDES should be MTI or not for= WebRTC implementations.

    I think this will take an hour at least, possibly longer. =A0I can pretend = to claim it will take 15 minutes, but we all know that simply isn't tru= e unless someone disconnects the microphones in the room. =A0I also expect = two or more other folks to want time to present on the same topic, so it= 9;ll likely take even longer in total time.

    Lastly, I beg the chairs to make this agenda item topic (not necessarily my= presentation, but the general topic) the *first* agenda topic for whicheve= r meeting session it gets put in, so that we don't run out of time on o= ther topics and delay an SDES decision once again.

    -hadriel


    On Jun 18, 2013, at 5:56 AM, Magnus Westerlund <    magnus.westerlund@ericsson.com> wrote:
    > Please request agenda time for
    > Berlin and ensure to update any drafts or other material to actually > take into account what actually has happened in the last 15 months.


    --089e0153879420ef6104df88a239-- From ibc@aliax.net Wed Jun 19 15:37:49 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D2621F9E83 for ; Wed, 19 Jun 2013 15:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.658 X-Spam-Level: X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7chRai23iCX for ; Wed, 19 Jun 2013 15:37:48 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7310721F9D52 for ; Wed, 19 Jun 2013 15:37:48 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id j10so3422507qcx.3 for ; Wed, 19 Jun 2013 15:37: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=V33hULdt/JMrAtqiseXXDm5l26wGpmgu0vKlQJk+bH8=; b=NH3ruISrtD/US4y/Bz4/vPpNNMWQKJamSsnZEJjtK8+eCcmni7RMUUG29Y5VQWlWyX pN6A2RJz4WfSfWpu2TiJ72jSUwxC7spOTAQl03Jndw3ouQoKR+7x1GGXolch4+d1MbS+ iJWvuMCuEM0ja85yKou91BSJGNfhdAmiPKTJVraM5jdPBop0gPX5wWC+09lGz21n2Bsl OSU5cxeNLwx7dF4vYHJ9Co32z+lVYr9PPsoE+/3qZ3YqBGV0ut5moJ+YwzhPx73KWCr5 g4jvsGM5mjqC5dtcmRujAnfZc5Tz4Oj5SsWlW5/EHyfkqlIjDz5+y+ic0a6bgeGTo8zo 6stw== X-Received: by 10.49.14.161 with SMTP id q1mr6233792qec.50.1371681466969; Wed, 19 Jun 2013 15:37:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 15:37:26 -0700 (PDT) In-Reply-To: References: <51C1D55D.6040905@hookflash.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 20 Jun 2013 00:37:26 +0200 Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlreN1g6n1GiQJABhvumj1wdPUgHA/wn9HAhbqk6vqNEGy3OX9YHlLH2VwNuGnDhq+rlyc5 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 22:37:49 -0000 2013/6/19 Peter Thatcher : > I won't disagree, but I don't think it's realistic with the WG to remove = SDP > from the API That would sound ever better if there was a real SDP based proposal rather than a debate about how to deal with SDP (which is what we have after two years). -- I=C3=B1aki Baz Castillo From rlb@ipv.sx Wed Jun 19 17:58:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193AF21F9EDA for ; Wed, 19 Jun 2013 17:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.657 X-Spam-Level: * X-Spam-Status: No, score=1.657 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UmNso3vPRwY for ; Wed, 19 Jun 2013 17:58:34 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E1FBB21F9EBC for ; Wed, 19 Jun 2013 17:58:33 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id b10so4586690vea.2 for ; Wed, 19 Jun 2013 17:58:32 -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:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Q7wQrWWilhIcnl9OtR4OcT3LE05W+UlurDD+U5ak0C4=; b=J36GRQoG1zuHyhogQdx3T1oICzYjPF0W/1lInxeAyX9RoHZXqBoXW4q9wKybwoTRqO vA4jh4NRZLmq6FoYTJ0zcjxilOet1vz/94GcEh8unURcS4bqT3gNgbDPpYqrJ0TZLQSq 8DdeJx4t0rwNb2Z1ZEPTDUzU2vvGJWxWWk3bCgvp8hez5xSmJYEojvZJ9/YMaXs4vZB9 o4U4p5ITCNGlD1NkNssE95B+bBqtgYZiFjTPaJ8dZYoCEET7DgGxL1EyOKXAQoZqQdjs KegQoblBgNnAkCCSbCDWqYaZWqnhvKPiExTJ6nOkB1qlQ5kiQ4se5ICm1Wl49LCFoFaf kwBg== MIME-Version: 1.0 X-Received: by 10.52.35.17 with SMTP id d17mr1538634vdj.74.1371689912507; Wed, 19 Jun 2013 17:58:32 -0700 (PDT) Received: by 10.58.73.195 with HTTP; Wed, 19 Jun 2013 17:58:32 -0700 (PDT) X-Originating-IP: [108.18.40.68] In-Reply-To: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> Date: Wed, 19 Jun 2013 20:58:32 -0400 Message-ID: From: Richard Barnes To: "Matthew Kaufman (SKYPE)" Content-Type: multipart/alternative; boundary=20cf307cfc40fa331e04df8b7173 X-Gm-Message-State: ALoCoQl6q7G/HJZKzP/iFB6+arfgSff7/VDjhKHqJHiukHLUl+fKWsq2UKLzFshxPm2q3eD1Ebkr Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 00:58:38 -0000 --20cf307cfc40fa331e04df8b7173 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think we still disagree on the scenario. I've tried to sketch out the full sequence of operations to be clear. (WebSequenceDiagrams source below.) ISTM that there are two major differences: -- In the SDES case, the JS and the Web Server both have access to the media keys. In the EKT case, the browser handles the keying update directly. -- In the EKT case, the PBX/gateway has to be in the media path to do EKT. After EKT, it just switches packets (it's basically a TURN server). So it seems like a security benefit for EKT and a performance benefit for SDES. Your quantitative valuation of these benefits / costs may vary. -----BEGIN-WSD----- alt SDES Scenario App->Browser: Create offer Browser->App: SDP+SDES (with key) App->WebServer: SDP+SDES WebServer->PBX: SDP+SDES PBX->Callee: SDP+SDES Callee->PBX: SDP+SDES PBX->WebServer: SDP+SDES WebServer->App: SDP+SDES App->Browser: Set remote answer (with key) Browser->Callee: SRTP else DTLS-SRTP Scenario App->Browser: Create offer Browser->App: SDP+DTLS-SRTP (no key) App->WebServer: SDP+DTLS-SRTP WebServer->PBX: SDP+DTLS-SRTP PBX->Callee: SDP+SDES/SIP Callee->PBX: SDP+SDES/SIP PBX->WebServer: SDP+DTLS-SRTP WebServer->App: SDP+DTLS-SRTP App->Browser: Set remote answer (no key) Browser->PBX: DTLS PBX->Browser: EKT Browser->PBX: SRTP PBX->Callee: SRTP end -----END-WSD----- On Tue, Jun 18, 2013 at 5:16 PM, Matthew Kaufman (SKYPE) < matthew.kaufman@skype.net> wrote: > So lets assume the case where I have a web server that is talking to my > browser *and* generating SIP traffic to talk to your SDES-capable (and > ICE-capable) PBX. > > And assume that your PBX initiated the call and picked the keying. > > So in the EKT case we have (for key flow): > your PBX -(SDES in SIP)-> my server -(SDES in JSON in HTTPS)-> browser > -(EKT)-> a media relay i now need to run > (for media): > browser <--(key that was received over HTTPS and then sent using EKT)--> > media relay <--(key that was received via SDES)--> your pbx > > but in the SDES case we have (for key flow): > your PBX -(SDES in SIP)-> my server -(SDES in SDP in HTTPS)-> browser > (and that's it, because I don't need a media relay in path any more) > (for media): > browser <--(key that was received over HTTPS at the browser, SDES in SDP > on SIP side)--> your pbx > > > Your diagram is missing the part where the browser either learns the key > that it is supposed to ask EKT to set or tells your SIP/SDES side what ke= y > it set using EKT. Either way, those keys go over HTTPS to/from the browse= r, > yes? > > Matthew Kaufman > > ------------------------------ > *From:* Richard Barnes [rlb@ipv.sx] > *Sent:* Tuesday, June 18, 2013 12:32 PM > *To:* Matthew Kaufman (SKYPE) > *Cc:* Magnus Westerlund; Hadriel Kaplan; rtcweb@ietf.org > > *Subject:* Re: [rtcweb] No Interim on SDES at this juncture > > On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman (SKYPE) < > matthew.kaufman@skype.net> wrote: > >> Back on April 25th, I made some claims. I still believe these are true: >> >> 1. DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it is >> just a different encrypted channel over which the key is set. >> > > Could you explain this in a little more detail? I agree that the COMSEC > properties are the same, but it seems like the communicating parties are > different. > > DTLS-SRTP+EKT: Browser ---(EKT)---> Gateway ---(SDES)---> Endpoint > SDES+HTTPS: Browser ---(HTTPS)---> Server ---(???)---> Gateway > ---(SDES)---> Endpoint > > That is, in the DTLS-SRTP+EKT case, the key never traverses the server. > Does your argument require that the server and the gateway be equally > trusted? (For example, because the server can choose the gateway.) It > doesn't seem like this is necessarily true in the general case. > > --Richard > > > >> 2. DTLS-SRTP w/EKT requires a more complex media gateway relationship fo= r >> interworking (as it needs to be in-path for the keying on that side, >> despite the use of SDES on the other side). >> >> 3. DTLS-SRTP w/EKT for interworking exposes the key via SDES on the othe= r >> side of the interworking relationship anyway, so even though there isn't >> SDES to the browser there's SDES on the other (likely SIP) side. >> >> 4. And DTLS-SRTP without EKT fails completely for the cases where the ke= y >> needs to be set for interworking. >> >> 5. And finally, to get the browser-to-browser security guarantees you >> would need to be A) sure that you're really talking browser to browser a= nd >> not via something else in path (like a mixer) and B) would really prefer >> that there be no way that the in-path device be able to force a key (thu= s >> you'd want to NOT allow EKT in the browser-to-browser case, even though >> there's no way for a browser to know for sure what it is talking to... I >> suppose that *if* you trusted your browser and the browser at the other = end >> (which you need to do anyway, because they could just leak keys or media= ), >> you could mandate that browsers set some bit that disallows EKT and hope >> that the other end respects it) >> >> >> Since we can't get interworking at all without either DTLS-SRTP + EKT or >> SDES, and since the security guarantees of DTLS-SRTP + EKT are the same = as >> those of SDES, and since the interworking gateway is made more complex >> (because the keying must be in-path), I believe the only possible >> conclusions are A) We accept that interworking with other SRTP systems i= s >> desirable and therefore SDES is the best way to achieve that or B) We >> prevent any interworking with other RTP or SRTP systems. >> >> As someone who could make some money sending traffic to/from non-RTCWEB >> networks, I'm a fan of "A". >> >> And no, I'm not planning on writing a draft that says to just do what we >> should be doing anyway. >> >> Matthew Kaufman >> >> >> ________________________________________ >> From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of >> Magnus Westerlund [magnus.westerlund@ericsson.com] >> Sent: Tuesday, June 18, 2013 2:56 AM >> To: Hadriel Kaplan >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] No Interim on SDES at this juncture >> >> Hadirel and WG, >> >> Please see my response inline. >> >> On 2013-06-14 18:58, Hadriel Kaplan wrote: >> > You can't be serious. There was exactly ONE email asking for agenda >> > items, here: >> > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html It >> > was sent on May 30th. It gave a generous 6 days to respond. Luckily >> > no one ever goes on vacation for longer than 5 days. Instead, two >> > people sent a response on June 10th, a tremendous 11 days after the >> > request. Outrageous! That's a almost twice as long as they were >> > given! >> > >> > Thank goodness the chairs detected this monstrous breach of >> > procedure, and thwarted the attempts of anarchy! I mean if people >> > are allowed to respond to emails so tardily, how can we be expected >> > to get things accomplished as quickly as they've so far been in this >> > WG?!? >> >> Yes, we have only sent a single email this time, being the second round >> in a short time we tried to schedule this meeting. >> >> > >> > Sure, an interim for this topic has been waiting for many months if >> > not a whole year, and now that people didn't respond in 6 days but >> > took instead 11 days the topic will be delayed indefinitely yet >> > again... but that's no excuse for blatantly flaunting the rules! >> >> Yes, there has been difficult finding a time could work for this >> meeting. That was why the agenda request time was short. >> >> > >> > Personally I saw the email on May 30th, and assumed Oscar and Dan >> > would respond to you for agenda time. I assumed that if no one had >> > submitted agenda items to you, that the WG Chairs would send out an >> > email warning about that, or perhaps even directly email the people >> > who they expected to submit agenda items. >> > >> >> Yes, you assumed that someone would respond. Rather than you reaching >> out to verify that others would drive the question for you. Hadriel you >> are apparently very interested in this topic. Why don't you ensure that >> an agenda topic is on the agenda for Berlin? The WG chairs are happy to >> receive agenda requests already now. >> >> > >> >> If you want to discuss this, write a draft describing how how your >> >> additional keying is to be integrated, what the pro and cons of it. >> >> That will enable direct discussion of a proposal. The WG clearly >> >> are opinionated on this matter, but apparently don't have energy to >> >> produce proposals. >> > >> > There *are* drafts. >> > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00 >> > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 There >> > are even powerpoint slides, sent to the chairs the last time this >> > meeting almost happened but didn't. >> >> One of those drafts has been expired since February I would like to >> point out. >> >> The looking at these drafts, they are neither a proposal for what to >> actually do. Dan Wing's draft is argument in general why SDES would be >> bad for security. Oscar Ohlsson's is an argument for why a number of >> potential risks are not a serious issue and what the other gains of >> using security descriptions are. >> >> From my perspective I really would like to see some progress in at least >> the proposal for actually adding additional keying to ensure that the >> raised issues in drafts or earlier WG meetings and email discussions are >> meet. Additionally I would really like to see some more details for how >> the actual integration of an additional keying mechanism is supposed to >> work. >> >> >> > >> > I think the problem must be that those things weren't signed in >> > triplicate, sent in, sent back, queried, lost, found, subjected to >> > public enquiry, lost again, and finally buried in soft peat for three >> > months and recycled as firelighters. >> >> No, that is not it. This topic has dragged on for various reasons. Yes >> we chairs are clearly to blame for some of them, like being slow to >> attempt to schedule a meeting. However, after that there has been issues >> finding a suitable time where sufficient mass of people could >> participate. There has been time conflicts with other meetings resulting >> in a cancellation, which in hind sight was unnecessary. Then a >> rescheduling, lurk warm response from the WG, limited agenda items and >> another almost collision resulting another cancellation. >> >> I am sorry that this makes you frustrated. Well, it makes also me >> frustrated. I wished this topic was dealt with and out of the way, but >> it is not. So, if you want it dealt with. Please request agenda time for >> Berlin and ensure to update any drafts or other material to actually >> take into account what actually has happened in the last 15 months. >> >> Regards >> >> 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 >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > --20cf307cfc40fa331e04df8b7173 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    I think we still disagree on the scenario. =A0I've tri= ed to sketch out the full sequence of operations to be clear. =A0(WebSequen= ceDiagrams source below.)

    ISTM that there are two major differences:
    --= In the SDES case, the JS and the Web Server both have access to the media = keys. =A0In the EKT case, the browser handles the keying update directly.
    -- In the EKT case, the PBX/gateway has to be in the media path to do = EKT. =A0After EKT, it just switches packets (it's basically a TURN serv= er).

    So it seems like a security benefit for EKT a= nd a performance benefit for SDES. =A0Your quantitative valuation of these = benefits / costs may vary.


    -----BEGIN-WSD-----
    alt S= DES Scenario

    App->Browser: Create offer
    Browser->App: SDP+SDES (with key)
    App->WebServer: SDP+SD= ES
    WebServer->PBX: SDP+SDES
    PBX->Callee: SDP+SDES
    Callee->PBX: SDP+SDES
    PBX->WebServer: SDP+SDES
    WebServer->App: SDP+SDES
    App->Browser: Set remote answer (= with key)
    Browser->Callee: SRTP

    else DTLS-SRTP Scena= rio

    App->Browser: Create offer
    Browse= r->App: SDP+DTLS-SRTP (no key)
    App->WebServer: SDP+DTLS-SRT= P
    WebServer->PBX: SDP+DTLS-SRTP
    PBX->Callee: SDP+SDES/SI= P
    Callee->PBX: SDP+SDES/SIP
    PBX->WebServer: SDP+D= TLS-SRTP
    WebServer->App: SDP+DTLS-SRTP
    App->Brows= er: Set remote answer (no key)
    Browser->PBX: DTLS
    PBX->Browser: EKT
    Browser= ->PBX: SRTP
    PBX->Callee: SRTP

    end<= /div>
    -----END-WSD-----

    On Tue, Jun 18, 2013 at 5:16 PM, Matthew Kau= fman (SKYPE) <matthew.kaufman@skype.net> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
    So lets assu= me the case where I have a web server that is talking to my browser *and* g= enerating SIP traffic to talk to your SDES-capable (and ICE-capable) PBX.

    And assume that your PBX initiated the call and picked the keying.

    So in the EKT case we have (for key flow):
    =A0your PBX -(SDES in SIP)-> my server -(SDES in JSON in HTTPS)->= ; browser -(EKT)-> a media relay i now need to run
    (for media):
    =A0browser <--(key that was received over HTTPS and then sent using= EKT)--> media relay <--(key that was received via SDES)--> your p= bx

    but in the SDES case we have (for key flow):
    =A0your PBX -(SDES in SIP)-> my server -(SDES in SDP in HTTPS)->= browser (and that's it, because I don't need a media relay in path= any more)
    (for media):
    =A0browser <--(key that was received over HTTPS at the browser, SDE= S in SDP on SIP side)--> your pbx


    Your diagram is missing the part where the browser either learns the k= ey that it is supposed to ask EKT to set or tells your SIP/SDES side what k= ey it set using EKT. Either way, those keys go over HTTPS to/from the brows= er, yes?

    Matthew Kaufman
    =A0=A0
    Fro= m: Richard Barnes [rlb@ipv.sx]
    Sent: Tuesday, June 18, 2013 12:32 PM
    To: Matthew Kaufman (SKYPE)
    Cc: Magnus Westerlund; Hadriel Kaplan; rtcweb@ietf.org

    Subject: Re: [rtcweb] No Interim on SDES at this juncture

    On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman (SKYPE) <= span dir=3D"ltr"> <matthew.= kaufman@skype.net> wrote:
    Back on April 25th, I made some claims. I still believe these are true:

    1. DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it is ju= st a different encrypted channel over which the key is set.

    Could you explain this in a little more detail? =A0I agree that the CO= MSEC properties are the same, but it seems like the communicating parties a= re different.

    DTLS-SRTP+EKT: =A0Browser ---(EKT)---> Gateway ---(SDES)---> End= point
    SDES+HTTPS: Browser ---(HTTPS)---> Server ---(???)---> Gateway -= --(SDES)---> Endpoint

    That is, in the DTLS-SRTP+EKT case, the key never traverses the server= . =A0Does your argument require that the server and the gateway be equally = trusted? =A0(For example, because the server can choose the gateway.) =A0It= doesn't seem like this is necessarily true in the general case. =A0

    --Richard

    =A0
    2. DTLS-SRTP w/EKT requires a more complex media gateway relationship for i= nterworking (as it needs to be in-path for the keying on that side, despite= the use of SDES on the other side).

    3. DTLS-SRTP w/EKT for interworking exposes the key via SDES on the other s= ide of the interworking relationship anyway, so even though there isn't= SDES to the browser there's SDES on the other (likely SIP) side.

    4. And DTLS-SRTP without EKT fails completely for the cases where the key n= eeds to be set for interworking.

    5. And finally, to get the browser-to-browser security guarantees you would= need to be A) sure that you're really talking browser to browser and n= ot via something else in path (like a mixer) and B) would really prefer tha= t there be no way that the in-path device be able to force a key (thus you'd want to NOT allow EKT in the browse= r-to-browser case, even though there's no way for a browser to know for= sure what it is talking to... I suppose that *if* you trusted your browser= and the browser at the other end (which you need to do anyway, because they could just leak keys or media), you co= uld mandate that browsers set some bit that disallows EKT and hope that the= other end respects it)


    Since we can't get interworking at all without either DTLS-SRTP + EKT o= r SDES, and since the security guarantees of DTLS-SRTP + EKT are the same a= s those of SDES, and since the interworking gateway is made more complex (b= ecause the keying must be in-path), I believe the only possible conclusions are A) We accept that interworking= with other SRTP systems is desirable and therefore SDES is the best way to= achieve that or B) We prevent any interworking with other RTP or SRTP syst= ems.

    As someone who could make some money sending traffic to/from non-RTCWEB net= works, I'm a fan of "A".

    And no, I'm not planning on writing a draft that says to just do what w= e should be doing anyway.

    Matthew Kaufman


    ________________________________________
    From: rtcweb-b= ounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Magnus Westerlund [magnus.westerl= und@ericsson.com]
    Sent: Tuesday, June 18, 2013 2:56 AM
    To: Hadriel Kaplan
    Cc: rtcweb@ietf.o= rg
    Subject: Re: [rtcweb] No Interim on SDES at this juncture

    Hadirel and WG,

    Please see my response inline.

    On 2013-06-14 18:58, Hadriel Kaplan wrote:
    > You can't be serious. There was exactly ONE email asking for agend= a
    > items, here:
    > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html It > was sent on May 30th. =A0It gave a generous 6 days to respond. =A0Luck= ily
    > no one ever goes on vacation for longer than 5 days. Instead, two
    > people sent a response on June 10th, a tremendous 11 days after the > request. =A0Outrageous! =A0That's a almost twice as long as they w= ere
    > given!
    >
    > Thank goodness the chairs detected this monstrous breach of
    > procedure, and thwarted the attempts of anarchy! =A0I mean if people > are allowed to respond to emails so tardily, how can we be expected > to get things accomplished as quickly as they've so far been in th= is
    > WG?!?

    Yes, we have only sent a single email this time, being the second round
    in a short time we tried to schedule this meeting.

    >
    > Sure, an interim for this topic has been waiting for many months if > not a whole year, and now that people didn't respond in 6 days but=
    > took instead 11 days the topic will be delayed indefinitely yet
    > again... but that's no excuse for blatantly flaunting the rules!
    Yes, there has been difficult finding a time could work for this
    meeting. That was why the agenda request time was short.

    >
    > Personally I saw the email on May 30th, and assumed Oscar and Dan
    > would respond to you for agenda time. =A0I assumed that if no one had<= br> > submitted agenda items to you, that the WG Chairs would send out an > email warning about that, or perhaps even directly email the people > who they expected to submit agenda items.
    >

    Yes, you assumed that someone would respond. Rather than you reaching
    out to verify that others would drive the question for you. Hadriel you
    are apparently very interested in this topic. Why don't you ensure that=
    an agenda topic is on the agenda for Berlin? The WG chairs are happy to
    receive agenda requests already now.

    >
    >> If you want to discuss this, write a draft describing how how your=
    >> additional keying is to be integrated, what the pro and cons of it= .
    >> That will enable direct discussion of a proposal. The WG clearly >> are opinionated on this matter, but apparently don't have ener= gy to
    >> produce proposals.
    >
    > There *are* drafts.
    > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00
    > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 There > are even powerpoint slides, sent to the chairs the last time this
    > meeting almost happened but didn't.

    One of those drafts has been expired since February I would like to
    point out.

    The looking at these drafts, they are neither a proposal for what to
    actually do. Dan Wing's draft is argument in general why SDES would be<= br> bad for security. Oscar Ohlsson's is an argument for why a number of potential risks are not a serious issue and what the other gains of
    using security descriptions are.

    >From my perspective I really would like to see some progress in at least the proposal for actually adding additional keying to ensure that the
    raised issues in drafts or earlier WG meetings and email discussions are meet. Additionally I would really like to see some more details for how
    the actual integration of an additional keying mechanism is supposed to
    work.


    >
    > I think the problem must be that those things weren't signed in > triplicate, sent in, sent back, queried, lost, found, subjected to
    > public enquiry, lost again, and finally buried in soft peat for three<= br> > months and recycled as firelighters.

    No, that is not it. This topic has dragged on for various reasons. Yes
    we chairs are clearly to blame for some of them, like being slow to
    attempt to schedule a meeting. However, after that there has been issues finding a suitable time where sufficient mass of people could
    participate. There has been time conflicts with other meetings resulting in a cancellation, which in hind sight was unnecessary. Then a
    rescheduling, lurk warm response from the WG, limited agenda items and
    another almost collision resulting another cancellation.

    I am sorry that this makes you frustrated. Well, it makes also me
    frustrated. I wished this topic was dealt with and out of the way, but
    it is not. So, if you want it dealt with. Please request agenda time for Berlin and ensure to update any drafts or other material to actually
    take into account what actually has happened in the last 15 months.

    Regards

    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

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


    --20cf307cfc40fa331e04df8b7173-- From matthew.kaufman@skype.net Wed Jun 19 18:08:41 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D27B21F9ED2 for ; Wed, 19 Jun 2013 18:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEAdhCsdSa94 for ; Wed, 19 Jun 2013 18:08:34 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9112921F9EF0 for ; Wed, 19 Jun 2013 18:08:34 -0700 (PDT) Received: from BN1AFFO11FD005.protection.gbl (10.58.52.200) by BN1BFFO11HUB017.protection.gbl (10.58.53.127) with Microsoft SMTP Server (TLS) id 15.0.707.0; Thu, 20 Jun 2013 01:02:03 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD005.mail.protection.outlook.com (10.58.52.65) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Thu, 20 Jun 2013 01:02:02 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.171]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Thu, 20 Jun 2013 01:02:02 +0000 From: "Matthew Kaufman (SKYPE)" To: Richard Barnes Thread-Topic: [rtcweb] No Interim on SDES at this juncture Thread-Index: AQHOZrw6CQcaVcHO7ESUEcTH2Hsm5ZkxWrGAgADdvYCAAA4GAIACkewAgACbDYCABdNvAIAAlhWIgAAKmICAABtrwIAB0iQAgAAA+qo= Date: Thu, 20 Jun 2013 01:02:00 +0000 Message-ID: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_BCF25A57AB814DD4A6EE7FF36333A389skypenet_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(52314003)(51704005)(189002)(24454002)(199002)(377454003)(377424004)(47976001)(59766001)(4396001)(31966008)(74706001)(81542001)(512934002)(76786001)(6806003)(56776001)(54316002)(16236675002)(63696002)(74876001)(81342001)(76796001)(69226001)(76482001)(74366001)(49866001)(80022001)(36756003)(51856001)(79102001)(16406001)(47736001)(561944002)(20776003)(77096001)(47446002)(65816001)(15395725003)(50986001)(33656001)(74662001)(15202345003)(30436002)(15198665003)(74502001)(16297215004)(53806001)(71186001)(54356001)(77982001)(56816003)(46102001)(9984715005)(4068875010); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB017; H:TK5EX14HUBC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 08831F51DC Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 01:08:41 -0000 --_000_BCF25A57AB814DD4A6EE7FF36333A389skypenet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please consider the case where the PBX does SDES only and cannot be upgrade= d to do EKT (common situation around here) Matthew Kaufman (Sent from my iPhone) On Jun 19, 2013, at 5:58 PM, "Richard Barnes" > wrote: I think we still disagree on the scenario. I've tried to sketch out the fu= ll sequence of operations to be clear. (WebSequenceDiagrams source below.) ISTM that there are two major differences: -- In the SDES case, the JS and the Web Server both have access to the medi= a keys. In the EKT case, the browser handles the keying update directly. -- In the EKT case, the PBX/gateway has to be in the media path to do EKT. = After EKT, it just switches packets (it's basically a TURN server). So it seems like a security benefit for EKT and a performance benefit for S= DES. Your quantitative valuation of these benefits / costs may vary. -----BEGIN-WSD----- alt SDES Scenario App->Browser: Create offer Browser->App: SDP+SDES (with key) App->WebServer: SDP+SDES WebServer->PBX: SDP+SDES PBX->Callee: SDP+SDES Callee->PBX: SDP+SDES PBX->WebServer: SDP+SDES WebServer->App: SDP+SDES App->Browser: Set remote answer (with key) Browser->Callee: SRTP else DTLS-SRTP Scenario App->Browser: Create offer Browser->App: SDP+DTLS-SRTP (no key) App->WebServer: SDP+DTLS-SRTP WebServer->PBX: SDP+DTLS-SRTP PBX->Callee: SDP+SDES/SIP Callee->PBX: SDP+SDES/SIP PBX->WebServer: SDP+DTLS-SRTP WebServer->App: SDP+DTLS-SRTP App->Browser: Set remote answer (no key) Browser->PBX: DTLS PBX->Browser: EKT Browser->PBX: SRTP PBX->Callee: SRTP end -----END-WSD----- On Tue, Jun 18, 2013 at 5:16 PM, Matthew Kaufman (SKYPE) > wrote: So lets assume the case where I have a web server that is talking to my bro= wser *and* generating SIP traffic to talk to your SDES-capable (and ICE-cap= able) PBX. And assume that your PBX initiated the call and picked the keying. So in the EKT case we have (for key flow): your PBX -(SDES in SIP)-> my server -(SDES in JSON in HTTPS)-> browser -(E= KT)-> a media relay i now need to run (for media): browser <--(key that was received over HTTPS and then sent using EKT)--> m= edia relay <--(key that was received via SDES)--> your pbx but in the SDES case we have (for key flow): your PBX -(SDES in SIP)-> my server -(SDES in SDP in HTTPS)-> browser (and= that's it, because I don't need a media relay in path any more) (for media): browser <--(key that was received over HTTPS at the browser, SDES in SDP o= n SIP side)--> your pbx Your diagram is missing the part where the browser either learns the key th= at it is supposed to ask EKT to set or tells your SIP/SDES side what key it= set using EKT. Either way, those keys go over HTTPS to/from the browser, y= es? Matthew Kaufman ________________________________ From: Richard Barnes [rlb@ipv.sx] Sent: Tuesday, June 18, 2013 12:32 PM To: Matthew Kaufman (SKYPE) Cc: Magnus Westerlund; Hadriel Kaplan; rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman (SKYPE) > wrote: Back on April 25th, I made some claims. I still believe these are true: 1. DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it is ju= st a different encrypted channel over which the key is set. Could you explain this in a little more detail? I agree that the COMSEC pr= operties are the same, but it seems like the communicating parties are diff= erent. DTLS-SRTP+EKT: Browser ---(EKT)---> Gateway ---(SDES)---> Endpoint SDES+HTTPS: Browser ---(HTTPS)---> Server ---(???)---> Gateway ---(SDES)---= > Endpoint That is, in the DTLS-SRTP+EKT case, the key never traverses the server. Do= es your argument require that the server and the gateway be equally trusted= ? (For example, because the server can choose the gateway.) It doesn't se= em like this is necessarily true in the general case. --Richard 2. DTLS-SRTP w/EKT requires a more complex media gateway relationship for i= nterworking (as it needs to be in-path for the keying on that side, despite= the use of SDES on the other side). 3. DTLS-SRTP w/EKT for interworking exposes the key via SDES on the other s= ide of the interworking relationship anyway, so even though there isn't SDE= S to the browser there's SDES on the other (likely SIP) side. 4. And DTLS-SRTP without EKT fails completely for the cases where the key n= eeds to be set for interworking. 5. And finally, to get the browser-to-browser security guarantees you would= need to be A) sure that you're really talking browser to browser and not v= ia something else in path (like a mixer) and B) would really prefer that th= ere be no way that the in-path device be able to force a key (thus you'd wa= nt to NOT allow EKT in the browser-to-browser case, even though there's no = way for a browser to know for sure what it is talking to... I suppose that = *if* you trusted your browser and the browser at the other end (which you n= eed to do anyway, because they could just leak keys or media), you could ma= ndate that browsers set some bit that disallows EKT and hope that the other= end respects it) Since we can't get interworking at all without either DTLS-SRTP + EKT or SD= ES, and since the security guarantees of DTLS-SRTP + EKT are the same as th= ose of SDES, and since the interworking gateway is made more complex (becau= se the keying must be in-path), I believe the only possible conclusions are= A) We accept that interworking with other SRTP systems is desirable and th= erefore SDES is the best way to achieve that or B) We prevent any interwork= ing with other RTP or SRTP systems. As someone who could make some money sending traffic to/from non-RTCWEB net= works, I'm a fan of "A". And no, I'm not planning on writing a draft that says to just do what we sh= ould be doing anyway. Matthew Kaufman ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounc= es@ietf.org] on behalf of Magnus Westerlund= [magnus.westerlund@ericsson.com] Sent: Tuesday, June 18, 2013 2:56 AM To: Hadriel Kaplan Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture Hadirel and WG, Please see my response inline. On 2013-06-14 18:58, Hadriel Kaplan wrote: > You can't be serious. There was exactly ONE email asking for agenda > items, here: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html It > was sent on May 30th. It gave a generous 6 days to respond. Luckily > no one ever goes on vacation for longer than 5 days. Instead, two > people sent a response on June 10th, a tremendous 11 days after the > request. Outrageous! That's a almost twice as long as they were > given! > > Thank goodness the chairs detected this monstrous breach of > procedure, and thwarted the attempts of anarchy! I mean if people > are allowed to respond to emails so tardily, how can we be expected > to get things accomplished as quickly as they've so far been in this > WG?!? Yes, we have only sent a single email this time, being the second round in a short time we tried to schedule this meeting. > > Sure, an interim for this topic has been waiting for many months if > not a whole year, and now that people didn't respond in 6 days but > took instead 11 days the topic will be delayed indefinitely yet > again... but that's no excuse for blatantly flaunting the rules! Yes, there has been difficult finding a time could work for this meeting. That was why the agenda request time was short. > > Personally I saw the email on May 30th, and assumed Oscar and Dan > would respond to you for agenda time. I assumed that if no one had > submitted agenda items to you, that the WG Chairs would send out an > email warning about that, or perhaps even directly email the people > who they expected to submit agenda items. > Yes, you assumed that someone would respond. Rather than you reaching out to verify that others would drive the question for you. Hadriel you are apparently very interested in this topic. Why don't you ensure that an agenda topic is on the agenda for Berlin? The WG chairs are happy to receive agenda requests already now. > >> If you want to discuss this, write a draft describing how how your >> additional keying is to be integrated, what the pro and cons of it. >> That will enable direct discussion of a proposal. The WG clearly >> are opinionated on this matter, but apparently don't have energy to >> produce proposals. > > There *are* drafts. > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00 > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 There > are even powerpoint slides, sent to the chairs the last time this > meeting almost happened but didn't. One of those drafts has been expired since February I would like to point out. The looking at these drafts, they are neither a proposal for what to actually do. Dan Wing's draft is argument in general why SDES would be bad for security. Oscar Ohlsson's is an argument for why a number of potential risks are not a serious issue and what the other gains of using security descriptions are. >From my perspective I really would like to see some progress in at least the proposal for actually adding additional keying to ensure that the raised issues in drafts or earlier WG meetings and email discussions are meet. Additionally I would really like to see some more details for how the actual integration of an additional keying mechanism is supposed to work. > > I think the problem must be that those things weren't signed in > triplicate, sent in, sent back, queried, lost, found, subjected to > public enquiry, lost again, and finally buried in soft peat for three > months and recycled as firelighters. No, that is not it. This topic has dragged on for various reasons. Yes we chairs are clearly to blame for some of them, like being slow to attempt to schedule a meeting. However, after that there has been issues finding a suitable time where sufficient mass of people could participate. There has been time conflicts with other meetings resulting in a cancellation, which in hind sight was unnecessary. Then a rescheduling, lurk warm response from the WG, limited agenda items and another almost collision resulting another cancellation. I am sorry that this makes you frustrated. Well, it makes also me frustrated. I wished this topic was dealt with and out of the way, but it is not. So, if you want it dealt with. Please request agenda time for Berlin and ensure to update any drafts or other material to actually take into account what actually has happened in the last 15 months. Regards 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 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_BCF25A57AB814DD4A6EE7FF36333A389skypenet_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Please consider the case where the PBX does SDES only and cannot be up= graded to do EKT (common situation around here)

    Matthew Kaufman

    (Sent from my iPhone)

    On Jun 19, 2013, at 5:58 PM, "Richard Barnes" <rlb@ipv.sx> wrote:

    I think we still disagree on the scenario.  I've trie= d to sketch out the full sequence of operations to be clear.  (WebSequ= enceDiagrams source below.)

    ISTM that there are two major differences:
    -- In the SDES case, the JS and the Web Server both have access to the= media keys.  In the EKT case, the browser handles the keying update d= irectly.
    -- In the EKT case, the PBX/gateway has to be in the media path to do = EKT.  After EKT, it just switches packets (it's basically a TURN serve= r).

    So it seems like a security benefit for EKT and a performance benefit = for SDES.  Your quantitative valuation of these benefits / costs may v= ary.


    -----BEGIN-WSD-----
    alt SDES Scenario

    App->Browser: Create offer
    Browser->App: SDP+SDES (with key)
    App->WebServer: SDP+SDES
    WebServer->PBX: SDP+SDES
    PBX->Callee: SDP+SDES
    Callee->PBX: SDP+SDES
    PBX->WebServer: SDP+SDES
    WebServer->App: SDP+SDES
    App->Browser: Set remote answer (with key)
    Browser->Callee: SRTP

    else DTLS-SRTP Scenario

    App->Browser: Create offer
    Browser->App: SDP+DTLS-SRTP (no key)
    App->WebServer: SDP+DTLS-SRTP
    WebServer->PBX: SDP+DTLS-SRTP
    PBX->Callee: SDP+SDES/SIP
    Callee->PBX: SDP+SDES/SIP
    PBX->WebServer: SDP+DTLS-SRTP
    WebServer->App: SDP+DTLS-SRTP
    App->Browser: Set remote answer (no key)
    Browser->PBX: DTLS
    PBX->Browser: EKT
    Browser->PBX: SRTP
    PBX->Callee: SRTP

    end
    -----END-WSD-----


    On Tue, Jun 18, 2013 at 5:16 PM, Matthew Kaufman= (SKYPE) <matthew.kaufman@skype.net> wrote:
    So lets assu= me the case where I have a web server that is talking to my browser *and* g= enerating SIP traffic to talk to your SDES-capable (and ICE-capable) PBX.

    And assume that your PBX initiated the call and picked the keying.

    So in the EKT case we have (for key flow):
     your PBX -(SDES in SIP)-> my server -(SDES in JSON in HTTPS)-= > browser -(EKT)-> a media relay i now need to run
    (for media):
     browser <--(key that was received over HTTPS and then sent us= ing EKT)--> media relay <--(key that was received via SDES)--> you= r pbx

    but in the SDES case we have (for key flow):
     your PBX -(SDES in SIP)-> my server -(SDES in SDP in HTTPS)-&= gt; browser (and that's it, because I don't need a media relay in path any = more)
    (for media):
     browser <--(key that was received over HTTPS at the browser, = SDES in SDP on SIP side)--> your pbx


    Your diagram is missing the part where the browser either learns the k= ey that it is supposed to ask EKT to set or tells your SIP/SDES side what k= ey it set using EKT. Either way, those keys go over HTTPS to/from the brows= er, yes?

    Matthew Kaufman
      
    Fro= m: Richard Barnes [rlb@ipv.sx]
    Sent: Tuesday, June 18, 2013 12:32 PM
    To: Matthew Kaufman (SKYPE)
    Cc: Magnus Westerlund; Hadriel Kaplan; rtcweb@ietf.org

    Subject: Re: [rtcweb] No Interim on SDES at this juncture

    On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman (SKYPE) <= span dir=3D"ltr"> <matthew.= kaufman@skype.net> wrote:
    Back on April 25th, I made some claims. I still believe these are true:

    1. DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it is ju= st a different encrypted channel over which the key is set.

    Could you explain this in a little more detail?  I agree that the= COMSEC properties are the same, but it seems like the communicating partie= s are different.

    DTLS-SRTP+EKT:  Browser ---(EKT)---> Gateway ---(SDES)---&= gt; Endpoint
    SDES+HTTPS: Browser ---(HTTPS)---> Server ---(???)---> Gatew= ay ---(SDES)---> Endpoint

    That is, in the DTLS-SRTP+EKT case, the key never traverses the se= rver.  Does your argument require that the server and the gateway be e= qually trusted?  (For example, because the server can choose the gatew= ay.)  It doesn't seem like this is necessarily true in the general case.  

    --Richard

     
    2. DTLS-SRTP w/EKT requires a more complex media gateway relationship for i= nterworking (as it needs to be in-path for the keying on that side, despite= the use of SDES on the other side).

    3. DTLS-SRTP w/EKT for interworking exposes the key via SDES on the other s= ide of the interworking relationship anyway, so even though there isn't SDE= S to the browser there's SDES on the other (likely SIP) side.

    4. And DTLS-SRTP without EKT fails completely for the cases where the key n= eeds to be set for interworking.

    5. And finally, to get the browser-to-browser security guarantees you would= need to be A) sure that you're really talking browser to browser and not v= ia something else in path (like a mixer) and B) would really prefer that th= ere be no way that the in-path device be able to force a key (thus you'd want to NOT allow EKT in the browser-to= -browser case, even though there's no way for a browser to know for sure wh= at it is talking to... I suppose that *if* you trusted your browser and the= browser at the other end (which you need to do anyway, because they could just leak keys or media), you co= uld mandate that browsers set some bit that disallows EKT and hope that the= other end respects it)


    Since we can't get interworking at all without either DTLS-SRTP + EKT o= r SDES, and since the security guarantees of DTLS-SRTP + EKT are the sa= me as those of SDES, and since the interworking gateway is made more comple= x (because the keying must be in-path), I believe the only possible conclusions are A) We accept that interworking= with other SRTP systems is desirable and therefore SDES is the best way to= achieve that or B) We prevent any interworking with other RTP or SRTP syst= ems.

    As someone who could make some money sending traffic to/from non-RTCWEB net= works, I'm a fan of "A".

    And no, I'm not planning on writing a draft that says to just do what we sh= ould be doing anyway.

    Matthew Kaufman


    ________________________________________
    From: rtcweb-b= ounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Magnus Westerlund [magnus.westerl= und@ericsson.com]
    Sent: Tuesday, June 18, 2013 2:56 AM
    To: Hadriel Kaplan
    Cc: rtcweb@ietf.o= rg
    Subject: Re: [rtcweb] No Interim on SDES at this juncture

    Hadirel and WG,

    Please see my response inline.

    On 2013-06-14 18:58, Hadriel Kaplan wrote:
    > You can't be serious. There was exactly ONE email asking for agenda > items, here:
    > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html It > was sent on May 30th.  It gave a generous 6 days to respond. &nbs= p;Luckily
    > no one ever goes on vacation for longer than 5 days. Instead, two
    > people sent a response on June 10th, a tremendous 11 days after the > request.  Outrageous!  That's a almost twice as long as they= were
    > given!
    >
    > Thank goodness the chairs detected this monstrous breach of
    > procedure, and thwarted the attempts of anarchy!  I mean if peopl= e
    > are allowed to respond to emails so tardily, how can we be expected > to get things accomplished as quickly as they've so far been in this > WG?!?

    Yes, we have only sent a single email this time, being the second round
    in a short time we tried to schedule this meeting.

    >
    > Sure, an interim for this topic has been waiting for many months if > not a whole year, and now that people didn't respond in 6 days but
    > took instead 11 days the topic will be delayed indefinitely yet
    > again... but that's no excuse for blatantly flaunting the rules!

    Yes, there has been difficult finding a time could work for this
    meeting. That was why the agenda request time was short.

    >
    > Personally I saw the email on May 30th, and assumed Oscar and Dan
    > would respond to you for agenda time.  I assumed that if no one h= ad
    > submitted agenda items to you, that the WG Chairs would send out an > email warning about that, or perhaps even directly email the people > who they expected to submit agenda items.
    >

    Yes, you assumed that someone would respond. Rather than you reaching
    out to verify that others would drive the question for you. Hadriel you
    are apparently very interested in this topic. Why don't you ensure that
    an agenda topic is on the agenda for Berlin? The WG chairs are happy to
    receive agenda requests already now.

    >
    >> If you want to discuss this, write a draft describing how how your=
    >> additional keying is to be integrated, what the pro and cons of it= .
    >> That will enable direct discussion of a proposal. The WG clearly >> are opinionated on this matter, but apparently don't have energy t= o
    >> produce proposals.
    >
    > There *are* drafts.
    > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00
    > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 There > are even powerpoint slides, sent to the chairs the last time this
    > meeting almost happened but didn't.

    One of those drafts has been expired since February I would like to
    point out.

    The looking at these drafts, they are neither a proposal for what to
    actually do. Dan Wing's draft is argument in general why SDES would be
    bad for security. Oscar Ohlsson's is an argument for why a number of
    potential risks are not a serious issue and what the other gains of
    using security descriptions are.

    >From my perspective I really would like to see some progress in at least the proposal for actually adding additional keying to ensure that the
    raised issues in drafts or earlier WG meetings and email discussions are meet. Additionally I would really like to see some more details for how
    the actual integration of an additional keying mechanism is supposed to
    work.


    >
    > I think the problem must be that those things weren't signed in
    > triplicate, sent in, sent back, queried, lost, found, subjected to
    > public enquiry, lost again, and finally buried in soft peat for three<= br> > months and recycled as firelighters.

    No, that is not it. This topic has dragged on for various reasons. Yes
    we chairs are clearly to blame for some of them, like being slow to
    attempt to schedule a meeting. However, after that there has been issues finding a suitable time where sufficient mass of people could
    participate. There has been time conflicts with other meetings resulting in a cancellation, which in hind sight was unnecessary. Then a
    rescheduling, lurk warm response from the WG, limited agenda items and
    another almost collision resulting another cancellation.

    I am sorry that this makes you frustrated. Well, it makes also me
    frustrated. I wished this topic was dealt with and out of the way, but
    it is not. So, if you want it dealt with. Please request agenda time for Berlin and ensure to update any drafts or other material to actually
    take into account what actually has happened in the last 15 months.

    Regards

    Magnus Westerlund

    ----------------------------------------------------------------------
    Multimedia Technologies, Ericsson Research EAB/TVM
    ----------------------------------------------------------------------
    Ericsson AB                | Phone =  +46 10 7148287
    F=E4r=F6gatan 6                | Mo= bile +46 73 0949079
    SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
    ----------------------------------------------------------------------

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

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


    --_000_BCF25A57AB814DD4A6EE7FF36333A389skypenet_-- From dwing@cisco.com Wed Jun 19 20:06:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800B121F9CB3 for ; Wed, 19 Jun 2013 20:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.561 X-Spam-Level: X-Spam-Status: No, score=-110.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJ3CYw2wPrnL for ; Wed, 19 Jun 2013 20:06:05 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D80FA21F9CDB for ; Wed, 19 Jun 2013 20:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9112; q=dns/txt; s=iport; t=1371697566; x=1372907166; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=sAp0KTRwra8zP2SlgKjpZZbM2LS5UIeAn7cXuylm0o8=; b=U//85aw4/DUOTU/Yu046FCPDJKUaYQMuRxOmqWAiU5i4RCwrfPqvmvK8 MqqFjKNswjHtOVn+igTRSIW2DREreuKg36ezslS6bENMJ0HwWGz1w/Uvf yUHUBhRNouRi6kOmygYJpVqJRRMlGnnBYXjLaW3+0yr1GFEm+99m16e/k k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0FAPtwwlGrRDoH/2dsb2JhbABRCYMJMbwGg1x9FnSCIwEBAQMBAQEBCWACBAcFCQILEQQBAQEVBAIMBxsMHwkIBhMJh38FDbwOBI18BwMGfzMHCh0CgldhA4kgjiGBKZAbgy8cgRAcAgIFFw X-IronPort-AV: E=Sophos;i="4.87,901,1363132800"; d="scan'208";a="83942449" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 20 Jun 2013 03:05:52 +0000 Received: from sjc-vpn3-98.cisco.com (sjc-vpn3-98.cisco.com [10.21.64.98]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5K35obV021758; Thu, 20 Jun 2013 03:05:50 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Wed, 19 Jun 2013 20:05:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com>, <51C02EE8.5070809@ericsson.com> To: Matthew Kaufman (SKYPE) X-Mailer: Apple Mail (2.1508) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 03:06:10 -0000 On Jun 18, 2013, at 12:02 PM, Matthew Kaufman (SKYPE) = wrote: > Back on April 25th, I made some claims. I still believe these are = true: >=20 > 1. DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it = is just a different encrypted channel over which the key is set. It is not exactly as secure. SDES requires giving the SRTP key to the = web server; DTLS-SRTP (with EKT) does not. In your later emails, you combined the web server's functionality with = gatewaying to an SDES-only IP PBX. This complicates the analysis and = makes a fruitful discussion impossible. > 2. DTLS-SRTP w/EKT requires a more complex media gateway relationship = for interworking (as it needs to be in-path for the keying on that side, = despite the use of SDES on the other side). Yes, because DTLS-SRTP is purposefully on the media path, which is what = requires the media gateway be on path. >=20 > 3. DTLS-SRTP w/EKT for interworking exposes the key via SDES on the = other side of the interworking relationship anyway, so even though there = isn't SDES to the browser there's SDES on the other (likely SIP) side. Yes, I agree that wherever SDES is used, those weaknesses of SDES = remain. >=20 > 4. And DTLS-SRTP without EKT fails completely for the cases where the = key needs to be set for interworking. No, it doesn't completely fail. It requires a decrypt/re-encrypt = operation in one direction of the SRTP traffic (from the SDES side to = the DTLS-SRTP side). Perhaps that is what you mean by "fails = completely", I don't know. >=20 > 5. And finally, to get the browser-to-browser security guarantees you = would need to be A) sure that you're really talking browser to browser = and not via something else in path (like a mixer) and B) would really = prefer that there be no way that the in-path device be able to force a = key (thus you'd want to NOT allow EKT in the browser-to-browser case, = even though there's no way for a browser to know for sure what it is = talking to... I suppose that *if* you trusted your browser and the = browser at the other end (which you need to do anyway, because they = could just leak keys or media), you could mandate that browsers set some = bit that disallows EKT and hope that the other end respects it) You're saying identity is not desirable, because of audio mixers? -d >=20 > Since we can't get interworking at all without either DTLS-SRTP + EKT = or SDES, and since the security guarantees of DTLS-SRTP + EKT are the = same as those of SDES, and since the interworking gateway is made more = complex (because the keying must be in-path), I believe the only = possible conclusions are A) We accept that interworking with other SRTP = systems is desirable and therefore SDES is the best way to achieve that = or B) We prevent any interworking with other RTP or SRTP systems. >=20 > As someone who could make some money sending traffic to/from = non-RTCWEB networks, I'm a fan of "A". >=20 > And no, I'm not planning on writing a draft that says to just do what = we should be doing anyway. >=20 > Matthew Kaufman >=20 >=20 > ________________________________________ > From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of = Magnus Westerlund [magnus.westerlund@ericsson.com] > Sent: Tuesday, June 18, 2013 2:56 AM > To: Hadriel Kaplan > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] No Interim on SDES at this juncture >=20 > Hadirel and WG, >=20 > Please see my response inline. >=20 > On 2013-06-14 18:58, Hadriel Kaplan wrote: >> You can't be serious. There was exactly ONE email asking for agenda >> items, here: >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html It >> was sent on May 30th. It gave a generous 6 days to respond. Luckily >> no one ever goes on vacation for longer than 5 days. Instead, two >> people sent a response on June 10th, a tremendous 11 days after the >> request. Outrageous! That's a almost twice as long as they were >> given! >>=20 >> Thank goodness the chairs detected this monstrous breach of >> procedure, and thwarted the attempts of anarchy! I mean if people >> are allowed to respond to emails so tardily, how can we be expected >> to get things accomplished as quickly as they've so far been in this >> WG?!? >=20 > Yes, we have only sent a single email this time, being the second = round > in a short time we tried to schedule this meeting. >=20 >>=20 >> Sure, an interim for this topic has been waiting for many months if >> not a whole year, and now that people didn't respond in 6 days but >> took instead 11 days the topic will be delayed indefinitely yet >> again... but that's no excuse for blatantly flaunting the rules! >=20 > Yes, there has been difficult finding a time could work for this > meeting. That was why the agenda request time was short. >=20 >>=20 >> Personally I saw the email on May 30th, and assumed Oscar and Dan >> would respond to you for agenda time. I assumed that if no one had >> submitted agenda items to you, that the WG Chairs would send out an >> email warning about that, or perhaps even directly email the people >> who they expected to submit agenda items. >>=20 >=20 > Yes, you assumed that someone would respond. Rather than you reaching > out to verify that others would drive the question for you. Hadriel = you > are apparently very interested in this topic. Why don't you ensure = that > an agenda topic is on the agenda for Berlin? The WG chairs are happy = to > receive agenda requests already now. >=20 >>=20 >>> If you want to discuss this, write a draft describing how how your >>> additional keying is to be integrated, what the pro and cons of it. >>> That will enable direct discussion of a proposal. The WG clearly >>> are opinionated on this matter, but apparently don't have energy to >>> produce proposals. >>=20 >> There *are* drafts. >> http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00 >> http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 There >> are even powerpoint slides, sent to the chairs the last time this >> meeting almost happened but didn't. >=20 > One of those drafts has been expired since February I would like to > point out. >=20 > The looking at these drafts, they are neither a proposal for what to > actually do. Dan Wing's draft is argument in general why SDES would be > bad for security. Oscar Ohlsson's is an argument for why a number of > potential risks are not a serious issue and what the other gains of > using security descriptions are. >=20 > =46rom my perspective I really would like to see some progress in at = least > the proposal for actually adding additional keying to ensure that the > raised issues in drafts or earlier WG meetings and email discussions = are > meet. Additionally I would really like to see some more details for = how > the actual integration of an additional keying mechanism is supposed = to > work. >=20 >=20 >>=20 >> I think the problem must be that those things weren't signed in >> triplicate, sent in, sent back, queried, lost, found, subjected to >> public enquiry, lost again, and finally buried in soft peat for three >> months and recycled as firelighters. >=20 > No, that is not it. This topic has dragged on for various reasons. Yes > we chairs are clearly to blame for some of them, like being slow to > attempt to schedule a meeting. However, after that there has been = issues > finding a suitable time where sufficient mass of people could > participate. There has been time conflicts with other meetings = resulting > in a cancellation, which in hind sight was unnecessary. Then a > rescheduling, lurk warm response from the WG, limited agenda items and > another almost collision resulting another cancellation. >=20 > I am sorry that this makes you frustrated. Well, it makes also me > frustrated. I wished this topic was dealt with and out of the way, but > it is not. So, if you want it dealt with. Please request agenda time = for > Berlin and ensure to update any drafts or other material to actually > take into account what actually has happened in the last 15 months. >=20 > Regards >=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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dwing@cisco.com Wed Jun 19 20:07:32 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0706211E80A5 for ; Wed, 19 Jun 2013 20:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.565 X-Spam-Level: X-Spam-Status: No, score=-110.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MskO61vIMpom for ; Wed, 19 Jun 2013 20:07:27 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9FF21F9FD6 for ; Wed, 19 Jun 2013 20:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27639; q=dns/txt; s=iport; t=1371697647; x=1372907247; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=EQ3yEZljPUiPP5ndLdl1Cvq1gULErldHEVe+uP1s7ls=; b=HU2BX//pTSxzPPLJV+t8Mk/3FTUHRmQhIitP+++925D2mZ1GDaEtRkFl zSzPkcXAeDf8qqBbJqPvTEWdvOKM4AZF16HIWe7FLuqgIQ5RGD1h3wq1S 9BhpD09md38ys1rDsPkbOE+qnYJ6GRnUBN5cFcOGlfK6vumE+lDSjGCOm Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggGAPtwwlGrRDoH/2dsb2JhbABagkVEMbcohF6DXH0WdIIjAQEBAwEBAQEJG0UCBAcFCQILEQQBAQEVBAIFBwcbDB8JCAYTCRKHbQUNvA4EjXwKBoEGGg4EBgEKHQKCV2EDiSCOIYEpkBuDLxyBEBwCAgUX X-IronPort-AV: E=Sophos;i="4.87,901,1363132800"; d="scan'208,217";a="83942593" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 20 Jun 2013 03:07:26 +0000 Received: from sjc-vpn3-98.cisco.com (sjc-vpn3-98.cisco.com [10.21.64.98]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5K37OfH023098; Thu, 20 Jun 2013 03:07:25 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_7D531F8E-D828-4380-8E10-B759DB1654A8" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Wed, 19 Jun 2013 20:07:24 -0700 Message-Id: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> , To: Matthew Kaufman (SKYPE) X-Mailer: Apple Mail (2.1508) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 03:07:32 -0000 --Apple-Mail=_7D531F8E-D828-4380-8E10-B759DB1654A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jun 18, 2013, at 2:16 PM, Matthew Kaufman (SKYPE) = wrote: > So lets assume the case where I have a web server that is talking to = my browser *and* generating SIP traffic to talk to your SDES-capable = (and ICE-capable) PBX. Let's not. Combining those two functions confuses SDES interworking = with the security of everything else. Yes, it is true that when doing = SDES interworking that the security vulnerabilities of SDES are exposed = on the SDES portion of the network. The solution is to quit doing SDES, = not more. -d >=20 > And assume that your PBX initiated the call and picked the keying. >=20 > So in the EKT case we have (for key flow): > your PBX -(SDES in SIP)-> my server -(SDES in JSON in HTTPS)-> = browser -(EKT)-> a media relay i now need to run > (for media): > browser <--(key that was received over HTTPS and then sent using = EKT)--> media relay <--(key that was received via SDES)--> your pbx >=20 > but in the SDES case we have (for key flow): > your PBX -(SDES in SIP)-> my server -(SDES in SDP in HTTPS)-> browser = (and that's it, because I don't need a media relay in path any more) > (for media): > browser <--(key that was received over HTTPS at the browser, SDES in = SDP on SIP side)--> your pbx >=20 >=20 > Your diagram is missing the part where the browser either learns the = key that it is supposed to ask EKT to set or tells your SIP/SDES side = what key it set using EKT. Either way, those keys go over HTTPS to/from = the browser, yes? >=20 > Matthew Kaufman > =20 > From: Richard Barnes [rlb@ipv.sx] > Sent: Tuesday, June 18, 2013 12:32 PM > To: Matthew Kaufman (SKYPE) > Cc: Magnus Westerlund; Hadriel Kaplan; rtcweb@ietf.org > Subject: Re: [rtcweb] No Interim on SDES at this juncture >=20 > On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman = (SKYPE) wrote: > Back on April 25th, I made some claims. I still believe these are = true: >=20 > 1. DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it = is just a different encrypted channel over which the key is set. >=20 > Could you explain this in a little more detail? I agree that the = COMSEC properties are the same, but it seems like the communicating = parties are different. >=20 > DTLS-SRTP+EKT: Browser ---(EKT)---> Gateway ---(SDES)---> Endpoint > SDES+HTTPS: Browser ---(HTTPS)---> Server ---(???)---> Gateway = ---(SDES)---> Endpoint >=20 > That is, in the DTLS-SRTP+EKT case, the key never traverses the = server. Does your argument require that the server and the gateway be = equally trusted? (For example, because the server can choose the = gateway.) It doesn't seem like this is necessarily true in the general = case. =20 >=20 > --Richard >=20 > =20 > 2. DTLS-SRTP w/EKT requires a more complex media gateway relationship = for interworking (as it needs to be in-path for the keying on that side, = despite the use of SDES on the other side). >=20 > 3. DTLS-SRTP w/EKT for interworking exposes the key via SDES on the = other side of the interworking relationship anyway, so even though there = isn't SDES to the browser there's SDES on the other (likely SIP) side. >=20 > 4. And DTLS-SRTP without EKT fails completely for the cases where the = key needs to be set for interworking. >=20 > 5. And finally, to get the browser-to-browser security guarantees you = would need to be A) sure that you're really talking browser to browser = and not via something else in path (like a mixer) and B) would really = prefer that there be no way that the in-path device be able to force a = key (thus you'd want to NOT allow EKT in the browser-to-browser case, = even though there's no way for a browser to know for sure what it is = talking to... I suppose that *if* you trusted your browser and the = browser at the other end (which you need to do anyway, because they = could just leak keys or media), you could mandate that browsers set some = bit that disallows EKT and hope that the other end respects it) >=20 >=20 > Since we can't get interworking at all without either DTLS-SRTP + EKT = or SDES, and since the security guarantees of DTLS-SRTP + EKT are the = same as those of SDES, and since the interworking gateway is made more = complex (because the keying must be in-path), I believe the only = possible conclusions are A) We accept that interworking with other SRTP = systems is desirable and therefore SDES is the best way to achieve that = or B) We prevent any interworking with other RTP or SRTP systems. >=20 > As someone who could make some money sending traffic to/from = non-RTCWEB networks, I'm a fan of "A". >=20 > And no, I'm not planning on writing a draft that says to just do what = we should be doing anyway. >=20 > Matthew Kaufman >=20 >=20 > ________________________________________ > From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of = Magnus Westerlund [magnus.westerlund@ericsson.com] > Sent: Tuesday, June 18, 2013 2:56 AM > To: Hadriel Kaplan > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] No Interim on SDES at this juncture >=20 > Hadirel and WG, >=20 > Please see my response inline. >=20 > On 2013-06-14 18:58, Hadriel Kaplan wrote: > > You can't be serious. There was exactly ONE email asking for agenda > > items, here: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html It > > was sent on May 30th. It gave a generous 6 days to respond. = Luckily > > no one ever goes on vacation for longer than 5 days. Instead, two > > people sent a response on June 10th, a tremendous 11 days after the > > request. Outrageous! That's a almost twice as long as they were > > given! > > > > Thank goodness the chairs detected this monstrous breach of > > procedure, and thwarted the attempts of anarchy! I mean if people > > are allowed to respond to emails so tardily, how can we be expected > > to get things accomplished as quickly as they've so far been in this > > WG?!? >=20 > Yes, we have only sent a single email this time, being the second = round > in a short time we tried to schedule this meeting. >=20 > > > > Sure, an interim for this topic has been waiting for many months if > > not a whole year, and now that people didn't respond in 6 days but > > took instead 11 days the topic will be delayed indefinitely yet > > again... but that's no excuse for blatantly flaunting the rules! >=20 > Yes, there has been difficult finding a time could work for this > meeting. That was why the agenda request time was short. >=20 > > > > Personally I saw the email on May 30th, and assumed Oscar and Dan > > would respond to you for agenda time. I assumed that if no one had > > submitted agenda items to you, that the WG Chairs would send out an > > email warning about that, or perhaps even directly email the people > > who they expected to submit agenda items. > > >=20 > Yes, you assumed that someone would respond. Rather than you reaching > out to verify that others would drive the question for you. Hadriel = you > are apparently very interested in this topic. Why don't you ensure = that > an agenda topic is on the agenda for Berlin? The WG chairs are happy = to > receive agenda requests already now. >=20 > > > >> If you want to discuss this, write a draft describing how how your > >> additional keying is to be integrated, what the pro and cons of it. > >> That will enable direct discussion of a proposal. The WG clearly > >> are opinionated on this matter, but apparently don't have energy to > >> produce proposals. > > > > There *are* drafts. > > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00 > > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 = There > > are even powerpoint slides, sent to the chairs the last time this > > meeting almost happened but didn't. >=20 > One of those drafts has been expired since February I would like to > point out. >=20 > The looking at these drafts, they are neither a proposal for what to > actually do. Dan Wing's draft is argument in general why SDES would be > bad for security. Oscar Ohlsson's is an argument for why a number of > potential risks are not a serious issue and what the other gains of > using security descriptions are. >=20 > =46rom my perspective I really would like to see some progress in at = least > the proposal for actually adding additional keying to ensure that the > raised issues in drafts or earlier WG meetings and email discussions = are > meet. Additionally I would really like to see some more details for = how > the actual integration of an additional keying mechanism is supposed = to > work. >=20 >=20 > > > > I think the problem must be that those things weren't signed in > > triplicate, sent in, sent back, queried, lost, found, subjected to > > public enquiry, lost again, and finally buried in soft peat for = three > > months and recycled as firelighters. >=20 > No, that is not it. This topic has dragged on for various reasons. Yes > we chairs are clearly to blame for some of them, like being slow to > attempt to schedule a meeting. However, after that there has been = issues > finding a suitable time where sufficient mass of people could > participate. There has been time conflicts with other meetings = resulting > in a cancellation, which in hind sight was unnecessary. Then a > rescheduling, lurk warm response from the WG, limited agenda items and > another almost collision resulting another cancellation. >=20 > I am sorry that this makes you frustrated. Well, it makes also me > frustrated. I wished this topic was dealt with and out of the way, but > it is not. So, if you want it dealt with. Please request agenda time = for > Berlin and ensure to update any drafts or other material to actually > take into account what actually has happened in the last 15 months. >=20 > Regards >=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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_7D531F8E-D828-4380-8E10-B759DB1654A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 matthew.kaufman@skype.net>= ; wrote:

    So lets = assume the case where I have a web server that is talking to my browser = *and* generating SIP traffic to talk to your SDES-capable (and = ICE-capable) PBX.

    Let's not. =  Combining those two functions confuses SDES interworking with the = security of everything else.  Yes, it is true that when doing SDES = interworking that the security vulnerabilities of SDES are exposed on = the SDES portion of the network.  The solution is to quit doing = SDES, not = more.

    -d


    From: Richard Barnes [rlb@ipv.sx]
    Sent: Tuesday, June 18, 2013 = 12:32 PM
    To: Matthew Kaufman = (SKYPE)
    Cc: Magnus Westerlund; Hadriel = Kaplan; rtcweb@ietf.org
    Subject: Re: [rtcweb] No Interim = on SDES at this juncture

    On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman = (SKYPE)<matthew.kaufman@skype.net> wrote:
    Back on April 25th, I = made some claims. I still believe these are true:

    1. DTLS-SRTP = w/EKT is exactly as secure as SDES sent over HTTPS... it is just a = different encrypted channel over which the key is = set.

    Could you explain this in a = little more detail?  I agree that the COMSEC properties are the = same, but it seems like the communicating parties are = different.

    DTLS-SRTP+EKT:  Browser = ---(EKT)---> Gateway ---(SDES)---> Endpoint
    SDES+HTTPS: = Browser ---(HTTPS)---> Server ---(???)---> Gateway = ---(SDES)---> Endpoint

    That is, in the = DTLS-SRTP+EKT case, the key never traverses the server.  Does your = argument require that the server and the gateway be equally trusted? =  (For example, because the server can choose the gateway.)  It = doesn't seem like this is necessarily true in the general case. =  

    --Richard

     <= /div>
    2. DTLS-SRTP w/EKT = requires a more complex media gateway relationship for interworking (as = it needs to be in-path for the keying on that side, despite the use of = SDES on the other side).

    3. DTLS-SRTP w/EKT for interworking = exposes the key via SDES on the other side of the interworking = relationship anyway, so even though there isn't SDES to the browser = there's SDES on the other (likely SIP) side.

    4. And DTLS-SRTP = without EKT fails completely for the cases where the key needs to be set = for interworking.

    5. And finally, to get the browser-to-browser = security guarantees you would need to be A) sure that you're really = talking browser to browser and not via something else in path (like a = mixer) and B) would really prefer that there be no way that the in-path = device be able to force a key (thus you'd want to NOT allow EKT in the = browser-to-browser case, even though there's no way for a browser to = know for sure what it is talking to... I suppose that *if* you trusted = your browser and the browser at the other end (which you need to do = anyway, because they could just leak keys or media), you could mandate = that browsers set some bit that disallows EKT and hope that the other = end respects it)


    Since we can't get interworking at all = without either DTLS-SRTP + EKT or SDES, and since the security = guarantees of DTLS-SRTP + EKT are the same as those of SDES, and since = the interworking gateway is made more complex (because the keying must = be in-path), I believe the only possible conclusions are A) We accept = that interworking with other SRTP systems is desirable and therefore = SDES is the best way to achieve that or B) We prevent any interworking = with other RTP or SRTP systems.

    As someone who could make some = money sending traffic to/from non-RTCWEB networks, I'm a fan of = "A".

    And no, I'm not planning on writing a draft that says to = just do what we should be doing anyway.

    Matthew = Kaufman


    ________________________________________
    From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Magnus = Westerlund [magnus.westerlund@ericsson.com]
    Sent: Tuesday, = June 18, 2013 2:56 AM
    To: Hadriel Kaplan
    Cc: rtcweb@ietf.org
    Subject: Re: [rtcweb] No = Interim on SDES at this juncture

    Hadirel and WG,

    Please see my response = inline.

    On 2013-06-14 18:58, Hadriel Kaplan wrote:
    > You = can't be serious. There was exactly ONE email asking for agenda
    > = items, here:
    > http://www.ietf.org/mail-archive/web/rtcweb/current/msg0= 7668.html It
    >= was sent on May 30th.  It gave a generous 6 days to respond. =  Luckily
    > no one ever goes on vacation for longer than 5 = days. Instead, two
    > people sent a response on June 10th, a = tremendous 11 days after the
    > request.  Outrageous! =  That's a almost twice as long as they were
    > = given!
    >
    > Thank goodness the chairs detected this monstrous = breach of
    > procedure, and thwarted the attempts of anarchy! =  I mean if people
    > are allowed to respond to emails so = tardily, how can we be expected
    > to get things accomplished as = quickly as they've so far been in this
    > WG?!?

    Yes, we have = only sent a single email this time, being the second round
    in a short = time we tried to schedule this meeting.

    >
    > Sure, an = interim for this topic has been waiting for many months if
    > not a = whole year, and now that people didn't respond in 6 days but
    > = took instead 11 days the topic will be delayed indefinitely yet
    > = again... but that's no excuse for blatantly flaunting the = rules!

    Yes, there has been difficult finding a time could work = for this
    meeting. That was why the agenda request time was = short.

    >
    > Personally I saw the email on May 30th, and = assumed Oscar and Dan
    > would respond to you for agenda time. =  I assumed that if no one had
    > submitted agenda items to = you, that the WG Chairs would send out an
    > email warning about = that, or perhaps even directly email the people
    > who they = expected to submit agenda items.
    >

    Yes, you assumed that = someone would respond. Rather than you reaching
    out to verify that = others would drive the question for you. Hadriel you
    are apparently = very interested in this topic. Why don't you ensure that
    an agenda = topic is on the agenda for Berlin? The WG chairs are happy to
    receive = agenda requests already now.

    >
    >> If you want to = discuss this, write a draft describing how how your
    >> = additional keying is to be integrated, what the pro and cons of = it.
    >> That will enable direct discussion of a proposal. The WG = clearly
    >> are opinionated on this matter, but apparently don't = have energy to
    >> produce proposals.
    >
    > There = *are* drafts.
    > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-proble= ms-00
    > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-sup= port-01 There
    > are even = powerpoint slides, sent to the chairs the last time this
    > meeting = almost happened but didn't.

    One of those drafts has been expired = since February I would like to
    point out.

    The looking at these = drafts, they are neither a proposal for what to
    actually do. Dan = Wing's draft is argument in general why SDES would be
    bad for = security. Oscar Ohlsson's is an argument for why a number = of
    potential risks are not a serious issue and what the other gains = of
    using security descriptions are.

    =46rom my perspective I = really would like to see some progress in at least
    the proposal for = actually adding additional keying to ensure that the
    raised issues in = drafts or earlier WG meetings and email discussions are
    meet. = Additionally I would really like to see some more details for how
    the = actual integration of an additional keying mechanism is supposed = to
    work.


    >
    > I think the problem must be that = those things weren't signed in
    > triplicate, sent in, sent back, = queried, lost, found, subjected to
    > public enquiry, lost again, = and finally buried in soft peat for three
    > months and recycled as = firelighters.

    No, that is not it. This topic has dragged on for = various reasons. Yes
    we chairs are clearly to blame for some of them, = like being slow to
    attempt to schedule a meeting. However, after that = there has been issues
    finding a suitable time where sufficient mass = of people could
    participate. There has been time conflicts with other = meetings resulting
    in a cancellation, which in hind sight was = unnecessary. Then a
    rescheduling, lurk warm response from the WG, = limited agenda items and
    another almost collision resulting another = cancellation.

    I am sorry that this makes you frustrated. Well, it = makes also me
    frustrated. I wished this topic was dealt with and out = of the way, but
    it is not. So, if you want it dealt with. Please = request agenda time for
    Berlin and ensure to update any drafts or = other material to actually
    take into account what actually has = happened in the last 15 months.

    Regards

    Magnus = Westerlund

    --------------------------------------------------------= --------------
    Multimedia Technologies, Ericsson Research = EAB/TVM
    ---------------------------------------------------------------= -------
    Ericsson AB               =  | Phone  +46 10 7148287
    F=E4r=F6gat= an 6                | = Mobile +46 73 0949079
    SE-164 80 Stockholm, Sweden| = mailto: magnus.westerlund@ericsson.com
    ------------------= ----------------------------------------------------

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

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

    _______= ________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.or= g/mailman/listinfo/rtcweb

    = --Apple-Mail=_7D531F8E-D828-4380-8E10-B759DB1654A8-- From prvs=88837ccfb6=christer.holmberg@ericsson.com Wed Jun 19 21:56:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B5021F9BDB for ; Wed, 19 Jun 2013 21:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.841 X-Spam-Level: X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6b43qory8i3 for ; Wed, 19 Jun 2013 21:56:01 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 978C221F9BEE for ; Wed, 19 Jun 2013 21:56:00 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-19-51c28b5f2d7b Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A4.81.15700.F5B82C15; Thu, 20 Jun 2013 06:55:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Thu, 20 Jun 2013 06:55:59 +0200 From: Christer Holmberg To: Peter Thatcher Thread-Topic: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Thread-Index: AQHObEI/LKM23biSMEicZL6ip01H1Jk7xwcAgAACKQCAAB+igIAAApYAgAB4ZYCAADHZMP//4oGAgAB39oCAACnpgIAAAi8AgAADwwCAABUmgIAAA5iAgAAH5oCAADG2IP//4A+AgAC5dzA= Date: Thu, 20 Jun 2013 04:55:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B1A1C@ESESSMB209.ericsson.se> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <7594FB04B1934943A5C02806D1A2204B1C3B1680@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.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+JvrW5896FAg+WzdS3aZh9hsbi2/DWr xdp/7ewOzB4LNpV6LFnyk8njVKdXAHMUt01SYklZcGZ6nr5dAnfGhTN/WAuauCtaPh9mbmC8 w9XFyMkhIWAi8fZAExOELSZx4d56ti5GLg4hgcOMEk9+XGeHcBYxSkzYcR7I4eBgE7CQ6P6n DdIgIqApMXlyMyuIzSzgLfHkzm52EFtYwEPi9rO9LCDlIgKeEsvPVoGMERGYxyix8uxfZpAa FgFViVm9nSwgNq+Ar8SH958YIXb1cUjc2zCbDSTBKRAocWniHbDrGIGu+35qDRPEMnGJW0/m Q10tILFkz3lmCFtU4uXjf6wgiyUEFCWW98uBmMxAd67fpQ/RqSgxpfshO8RaQYmTM5+wTGAU m4Vk6CyEjllIOmYh6VjAyLKKkT03MTMnvdxwEyMwYg5u+a27g/HUOZFDjNIcLErivB9O7QoU EkhPLEnNTk0tSC2KLyrNSS0+xMjEwQkiuKQaGLm7Ly56JG/yWaAxY/Ym2aYPD+sy/8yWaXNr OPCYYXI3g/JpJUEmCdbsYmX7mhnNDyZcrPRkE0z7ejskf0J1JO+B79/mrgu79fmemDnTx7VN U+KN5vmwZbBWyRycvV/KvKG2vMHsw9b2Ce3+znJ3nSsFPS97Luq5Ljg1M8kj6Mm6j71lcvvW KrEUZyQaajEXFScCAMtguEtrAgAA Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 04:56:07 -0000 SGksDQoNCj4+Pj4gV2h5IGFyZW4ndCB3ZSB1c2luZyB0aGUgSmF2YVNjcmlwdCBvYmplY3QgbW9k ZWwgZm9yIGNvbnRyb2wgb2YgY29tcG9uZW50cyBpbnN0ZWFkIG9mIHNlcmlhbGl6aW5nIG91ciBj b250cm9sIHJlcXVlc3RzIHZpYSBTRFAvd2hhdGV2ZXIgZm9ybWF0IGFuZCBob3BpbmcgdGhhdCBp dCB3b3JrZWQ/DQo+Pj4+DQo+Pj4gVGhhdCdzIGEgZ3JlYXQgcXVlc3Rpb24uIEhhdmUgeW91IHJl YWQgdGhlIENVLVJUQ1dFQiBwcm9wb3NhbD8gSXMgaXQgYW55IGNsb3NlciB0byB3aGF0IHlvdSBp bWFnaW5lZCB0aGUgUlRDV0VCIEFQSSBtaWdodCBiZT8NCj4+Pg0KPj4+IE15ICJOb1BsYW4gSlMg QVBJIiBwcm9wb3NhbCBhbHNvIGFsbG93cyBjb250cm9sIG9mIGNvbXBvbmVudHMgd2l0aG91dCBz ZXJpYWxpemUgY29udHJvbCB2aWEgYSBmb3JtYXQsIGlmIHRoZSBKUyBjaG9vc2VzIHRvIA0KPj4+ IGRvIHNvIChTRFAgaXMgc3RpbGwgdGhlcmUgaWYgSlMgd2FudHMpLiDCoEl0IG9ubHkgZG9lcyBz byBmb3IgbWVkaWEgc3RyZWFtcywgbm90IGZvciB0cmFuc3BvcnRzLCBidXQgaXQgYWxsb3dzIGlu Y3JlbWVudGFsIGltcHJvdmVtZW50IHRvIHRoZSBBUEkuDQo+PiBTbywgSUYgd2UgZGVjaWRlIHRv IHJlbW92ZSBTRFAgYW5kIE9mZmVyL0Fuc3dlciwgd2UnbGwgZW5kIHVwIGFyZ3VpbmcgYWJvdXQg IlBsYW4gQyhVKSB2cyBObyBQbGFuIj8gOikNCj4NCj4gSSB0aGluayB3ZSBhbHJlYWR5IGFyZSA6 KS4NCg0KQXQgdGhlIHZpcnR1YWwgaW50ZXJpbSwgdGhlIFBsYW4gQSBhbmQgUGxhbiBCIGZvbGtz IHdlcmUgYXNrZWQgdG8gc2l0IGRvd24gYW5kIHRyeSB0byBjb21lIHVwIHdpdGggYSBjb21wcm9t aXNlICJQbGFuIEFCIiBzb2x1dGlvbi4NCg0KSSBndWVzcyBpdCB3b3VsZCBiZSBnb29kIGlmIHBl b3BsZSB0aGF0IGRvbid0IHdhbnQgU0RQIGNvdWxkIHRyeSB0byBjb21lIHVwIHdpdGggYSBjb21w cm9taXNlICJDVSBObyBQbGFuIiBzb2x1dGlvbiA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQo= From hadriel.kaplan@oracle.com Thu Jun 20 00:11:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212C721F9EB6 for ; Thu, 20 Jun 2013 00:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJ1c4g52T3AA for ; Thu, 20 Jun 2013 00:11:16 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 76A8F21F9C58 for ; Thu, 20 Jun 2013 00:11:16 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5K7BCYQ028381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jun 2013 07:11:13 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5K7BBm1021879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 07:11:12 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5K7BBNt011616; Thu, 20 Jun 2013 07:11:11 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-166-124.vpn.oracle.com (/10.154.166.124) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jun 2013 00:11:11 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Thu, 20 Jun 2013 03:11:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> To: Richard Barnes X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 07:11:22 -0000 On Jun 19, 2013, at 8:58 PM, Richard Barnes wrote: > I think we still disagree on the scenario. I've tried to sketch out = the full sequence of operations to be clear. (WebSequenceDiagrams = source below.) > >=20 > ISTM that there are two major differences: > -- In the SDES case, the JS and the Web Server both have access to the = media keys. In the EKT case, the browser handles the keying update = directly. > -- In the EKT case, the PBX/gateway has to be in the media path to do = EKT. After EKT, it just switches packets (it's basically a TURN = server). >=20 > So it seems like a security benefit for EKT and a performance benefit = for SDES. Your quantitative valuation of these benefits / costs may = vary. I'm confused. EKT has "a security benefit" for whom, exactly? It's not more secure for the browser user, since a malicious web server = can simply *be* the PBX, terminate DTLS-EKT and get the key and the = browser user would never know it. It's not more secure for the SIP user, since the SIP user is only doing = SDES and has no idea what's happening on the far-end. Who are you saying is being better protected from what? I suppose we could claim the owner of the PBX feels more secure, if = they're not the same as the owner of the web-server and don't trust the = web-server. But again, if the web-server owner is malicious it will = just terminate the media pretending to be the PBX on one side, and = pretending to be the browser to the real PBX on the other side. And why = would a PBX owner accept calls from a web-server it doesn't trust to = begin with? Afaict, the main security benefit of DTLS-EKT is the same as that of = DTLS-SRTP: the keys aren't sent in the JSON/SDP/whatever, so they can't = be sniffed even if cleartext HTTP is used. So in a weird way, the = security benefit of it is it let's us use an insecure HTTP transport for = the JSON/SDP/HTML/whatever. Luckily the ability to see and modify what = goes on there is no big deal... like for example be able to insert a = malicious DTLS-SRTP B2BUA that records everything. Oh, wait... -hadriel From prvs=5883fdf784=magnus.westerlund@ericsson.com Thu Jun 20 00:30:56 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45F521F9CD9 for ; Thu, 20 Jun 2013 00:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.109 X-Spam-Level: X-Spam-Status: No, score=-106.109 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tgv2ZvMS9C3o for ; Thu, 20 Jun 2013 00:30:51 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1941221F9BF8 for ; Thu, 20 Jun 2013 00:30:50 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-ee-51c2afa929b4 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 9A.76.18006.9AFA2C15; Thu, 20 Jun 2013 09:30:49 +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; Thu, 20 Jun 2013 09:30:49 +0200 Message-ID: <51C2AFB3.30405@ericsson.com> Date: Thu, 20 Jun 2013 09:30:59 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+Jvre7K9YcCDdrmmVh82vSJ2WLtv3Z2 ByaPJUt+Mnl8fHqLJYApitsmKbGkLDgzPU/fLoE748PpJUwF2wUr9p1YwtzAOJevi5GTQ0LA ROL843MsELaYxIV769m6GLk4hAROMUosebKKESQhJLCcUeLs5SgQm1dAU+Ls+utMIDaLgKrE ukuNYDabgIXEzR+NbCC2qECwxJHtm1kg6gUlTs58AmRzcIgI6EkcvccJEmYWEJbYcLENrERY wFKip/sNM8TeucwS2379Zwap5xSwkzgzH+o2SYktL9rZIXr1JKZcbWGEsOUlmrfOZoY4U1ui oamDdQKj0Cwkm2chaZmFpGUBI/MqRvbcxMyc9HKjTYzAUD245bfqDsY750QOMUpzsCiJ8348 tStQSCA9sSQ1OzW1ILUovqg0J7X4ECMTByeI4JJqYJwaz7fYIevdqYe35kesV+F2M5gpxtT8 OGh98lHTuZL3X5aaH+KtTGx98MnAtO3/viei7xbt4Vu5Q+mkzDkO301/nV715PbM2xP5pdzC 40Xk01tiM4XyZUze3w3O4xRUXpJ7df53QfMzetzLOP/dWifbKvA27/+Me9tZezb/juKefvRN g7GBtYYSS3FGoqEWc1FxIgDxbUx2KAIAAA== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 07:30:56 -0000 On 2013-06-19 20:27, Hadriel Kaplan wrote: > > On Jun 18, 2013, at 5:56 AM, Magnus Westerlund > wrote: > >>>> If you want to discuss this, write a draft describing how how >>>> your additional keying is to be integrated, what the pro and >>>> cons of it. That will enable direct discussion of a proposal. >>>> The WG clearly are opinionated on this matter, but apparently >>>> don't have energy to produce proposals. >>> >>> There *are* drafts. >>> http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00 >>> http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 >>> There are even powerpoint slides, sent to the chairs the last >>> time this meeting almost happened but didn't. >> >> One of those drafts has been expired since February I would like >> to point out. > > You're just messing with me right? You're pointing out the drafts > are old, in response to a complaint the meeting's been delayed > multiple times?? Might it be the drafts are old because the > meeting's been delayed multiple times?!? That is not my complaint. Yes, the meeting has been delayed. That has caused the draft to expire. Thus, I personally would expect that proponents that are interested in the topic at least re-submits the draft so that it is available and easily findable for people. Thus, I took that as part of the indications of uncertain interest. That weighted in with several other factors that made us cancel the interim. I can only state my personal view of factors that influenced my position resulting in the chairs decision. To be clear, I am also not happy with how this has developed. I definitely hope this issue can be settled with the Berlin meeting. 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 ---------------------------------------------------------------------- From harald@alvestrand.no Thu Jun 20 04:24:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D042821F9BFF for ; Thu, 20 Jun 2013 04:24:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmGKZDemxJon for ; Thu, 20 Jun 2013 04:24:00 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CD82B21F9ADC for ; Thu, 20 Jun 2013 04:23:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 27D1539E173 for ; Thu, 20 Jun 2013 13: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 xQWnxSop1brr for ; Thu, 20 Jun 2013 13:23:55 +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 04AC239E09F for ; Thu, 20 Jun 2013 13:23:54 +0200 (CEST) Message-ID: <51C2E64A.3070306@alvestrand.no> Date: Thu, 20 Jun 2013 13:23:54 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com>, <51C02EE8.5070809@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 11:24:04 -0000 On 06/18/2013 09:02 PM, Matthew Kaufman (SKYPE) wrote: > Back on April 25th, I made some claims. I still believe these are true: And I still believe enough of them are false that I don't have much faith in a conclusion drawn from those premises. > > 1. DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it is just a different encrypted channel over which the key is set. I believe this is false. "Exactly as secure" doesn't hold when the holders of the keys for the two encrypted channels are different. > > 2. DTLS-SRTP w/EKT requires a more complex media gateway relationship for interworking (as it needs to be in-path for the keying on that side, despite the use of SDES on the other side). > > 3. DTLS-SRTP w/EKT for interworking exposes the key via SDES on the other side of the interworking relationship anyway, so even though there isn't SDES to the browser there's SDES on the other (likely SIP) side. Interworking with SDES requires that the key is carried in SDES, so this seems like a truism. > > 4. And DTLS-SRTP without EKT fails completely for the cases where the key needs to be set for interworking. If you had said "requires decrypt/reencrypt at the gateway" rather than "fails completely", I would hold this statement to be true. As written, I believe this is false. > > 5. And finally, to get the browser-to-browser security guarantees you would need to be A) sure that you're really talking browser to browser and not via something else in path (like a mixer) and B) would really prefer that there be no way that the in-path device be able to force a key (thus you'd want to NOT allow EKT in the browser-to-browser case, even though there's no way for a browser to know for sure what it is talking to... I suppose that *if* you trusted your browser and the browser at the other end (which you need to do anyway, because they could just leak keys or media), you could mandate that browsers set some bit that disallows EKT and hope that the other end respects it) > > > Since we can't get interworking at all without either DTLS-SRTP + EKT or SDES, and since the security guarantees of DTLS-SRTP + EKT are the same as those of SDES, and since the interworking gateway is made more complex (because the keying must be in-path), I believe the only possible conclusions are A) We accept that interworking with other SRTP systems is desirable and therefore SDES is the best way to achieve that or B) We prevent any interworking with other RTP or SRTP systems. > > As someone who could make some money sending traffic to/from non-RTCWEB networks, I'm a fan of "A". > > And no, I'm not planning on writing a draft that says to just do what we should be doing anyway. > > Matthew Kaufman > > > ________________________________________ > From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Magnus Westerlund [magnus.westerlund@ericsson.com] > Sent: Tuesday, June 18, 2013 2:56 AM > To: Hadriel Kaplan > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] No Interim on SDES at this juncture > > Hadirel and WG, > > Please see my response inline. > > On 2013-06-14 18:58, Hadriel Kaplan wrote: >> You can't be serious. There was exactly ONE email asking for agenda >> items, here: >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html It >> was sent on May 30th. It gave a generous 6 days to respond. Luckily >> no one ever goes on vacation for longer than 5 days. Instead, two >> people sent a response on June 10th, a tremendous 11 days after the >> request. Outrageous! That's a almost twice as long as they were >> given! >> >> Thank goodness the chairs detected this monstrous breach of >> procedure, and thwarted the attempts of anarchy! I mean if people >> are allowed to respond to emails so tardily, how can we be expected >> to get things accomplished as quickly as they've so far been in this >> WG?!? > Yes, we have only sent a single email this time, being the second round > in a short time we tried to schedule this meeting. > >> Sure, an interim for this topic has been waiting for many months if >> not a whole year, and now that people didn't respond in 6 days but >> took instead 11 days the topic will be delayed indefinitely yet >> again... but that's no excuse for blatantly flaunting the rules! > Yes, there has been difficult finding a time could work for this > meeting. That was why the agenda request time was short. > >> Personally I saw the email on May 30th, and assumed Oscar and Dan >> would respond to you for agenda time. I assumed that if no one had >> submitted agenda items to you, that the WG Chairs would send out an >> email warning about that, or perhaps even directly email the people >> who they expected to submit agenda items. >> > Yes, you assumed that someone would respond. Rather than you reaching > out to verify that others would drive the question for you. Hadriel you > are apparently very interested in this topic. Why don't you ensure that > an agenda topic is on the agenda for Berlin? The WG chairs are happy to > receive agenda requests already now. > >>> If you want to discuss this, write a draft describing how how your >>> additional keying is to be integrated, what the pro and cons of it. >>> That will enable direct discussion of a proposal. The WG clearly >>> are opinionated on this matter, but apparently don't have energy to >>> produce proposals. >> There *are* drafts. >> http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00 >> http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 There >> are even powerpoint slides, sent to the chairs the last time this >> meeting almost happened but didn't. > One of those drafts has been expired since February I would like to > point out. > > The looking at these drafts, they are neither a proposal for what to > actually do. Dan Wing's draft is argument in general why SDES would be > bad for security. Oscar Ohlsson's is an argument for why a number of > potential risks are not a serious issue and what the other gains of > using security descriptions are. > > From my perspective I really would like to see some progress in at least > the proposal for actually adding additional keying to ensure that the > raised issues in drafts or earlier WG meetings and email discussions are > meet. Additionally I would really like to see some more details for how > the actual integration of an additional keying mechanism is supposed to > work. > > >> I think the problem must be that those things weren't signed in >> triplicate, sent in, sent back, queried, lost, found, subjected to >> public enquiry, lost again, and finally buried in soft peat for three >> months and recycled as firelighters. > No, that is not it. This topic has dragged on for various reasons. Yes > we chairs are clearly to blame for some of them, like being slow to > attempt to schedule a meeting. However, after that there has been issues > finding a suitable time where sufficient mass of people could > participate. There has been time conflicts with other meetings resulting > in a cancellation, which in hind sight was unnecessary. Then a > rescheduling, lurk warm response from the WG, limited agenda items and > another almost collision resulting another cancellation. > > I am sorry that this makes you frustrated. Well, it makes also me > frustrated. I wished this topic was dealt with and out of the way, but > it is not. So, if you want it dealt with. Please request agenda time for > Berlin and ensure to update any drafts or other material to actually > take into account what actually has happened in the last 15 months. > > Regards > > 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 > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From andrew.hutton@siemens-enterprise.com Thu Jun 20 08:26:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E8B21F9928 for ; Thu, 20 Jun 2013 08:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3v+75ZFLZevq for ; Thu, 20 Jun 2013 08:26:15 -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 802A221F9D9B for ; Thu, 20 Jun 2013 08:25:40 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 215A61EB8565 for ; Thu, 20 Jun 2013 17:25:38 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Thu, 20 Jun 2013 17:25:37 +0200 From: "Hutton, Andrew" To: "rtcweb@ietf.org" Thread-Topic: Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . Thread-Index: AQHObEJByY7ZqkO+CkSPIPqSfmn6rpk+jpkg Date: Thu, 20 Jun 2013 15:25:37 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115D2150@MCHP04MSX.global-ad.net> References: 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 Subject: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 15:26:31 -0000 DQpJTUhPIHRoZSByZS1vcGVuaW5nIG9mIHRoZSBkZWJhdGUgb24gIlNEUCBvciBub3QgU0RQIiBp cyBub3QgdGhlIHJpZ2h0IGFwcHJvYWNoIHRvIG1ha2luZyBwcm9ncmVzcyBhdCB0aGlzIG1vbWVu dCBpbiB0aW1lIGFzIGl0IHdvdWxkIG9ubHkgc2VydmUgdG8gc2xvdyB0aGUgcHJvY2VzcyBldmVu IGZ1cnRoZXIgYW5kIHJlb3BlbiBhbGwgdGhlIG9sZCBhcmd1bWVudHMuDQoNClRoZSBhZ3JlZW1l bnQgYWxiZWl0IGEgVzNDIGFncmVlbWVudCB3YXMgdG8gYXNzZXNzIHRoZSByZXF1aXJlbWVudHMg Zm9yIGEgbG93ZXIgbGV2ZWwgQVBJIChXaXRob3V0IFNEUCkgb25jZSBhIGZpcnN0IHJlbGVhc2Ug b2YgV2ViUlRDIGlzIGFjaGlldmVkIGFuZCBJIHRoaW5rIHdlIHNob3VsZCBub3QgcmV2ZXJzZSB0 aGF0IGFncmVlbWVudCB0aGVyZSB3YXMgc3Ryb25nIGNvbnNlbnN1cyBvbiB0aGF0IGF0IHRoZSB0 aW1lLg0KDQpIb3dldmVyIEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgYSBjbG9zZSBsb29rIGF0IG91 ciBwcmlvcml0aWVzIGFuZCB3aGF0IHdlIHJlYWxseSBuZWVkIHRvIGdldCB0byB3aGF0IHdvdWxk IGVmZmVjdGl2ZWx5IGJlIFdlYlJUQyAxLjAuIE15IGZlZWxpbmcgaXMgdGhhdCB3ZSBhcmUgdHJ5 aW5nIHRvIGRvIHRvbyBtdWNoLg0KDQpMZXQncyB0YWtlIGEgc2hvcnQgcGF1c2UgZm9yIGJyZWF0 aCBhbmQgdGhpbmsgYWJvdXQgd2hhdCB3ZSByZWFsbHkgbmVlZCBmb3IgYSBzdWNjZXNzZnVsIFdl YlJUQyAxLjAgYXMgSSB0aGluayB3ZSBhcmUgbWF5YmUgZm9jdXNlZCBvbiB0aGUgd3JvbmcgaXNz dWVzIGFuZCB3ZSBzZWVtIHRvIGhhdmUgZ290IGRpdmVydGVkIGZyb20gdGhlIHByaW9yaXRpZXMg c2V0IGluIHRoZSBjaGFydGVyIChodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvcnRjd2Vi L2NoYXJ0ZXIvKS4NCg0KRm9yIGV4YW1wbGUgdG8gbWFrZSBldmVuIGJhc2ljIFdlYlJUQyBhcHBs aWNhdGlvbnMgZWFzaWx5IGRlcGxveWFibGUgd2UgbmVlZCB0byByZXNvbHZlIHRoZSBmaXJld2Fs bCBpc3N1ZXMgYXMgc3RhdGVkIGluIHRoZSBjaGFydGVyIChidWxsZXQgMykuIFdlIGRvbid0IGV2 ZW4gaGF2ZSBhbiBhZG9wdGVkIGRyYWZ0IGZvciB0aGF0IHlldCBidXQgSSBob3BlIHRoYXQgY2Fu IGJlIGNoYW5nZWQgdmVyeSBzb29uLiAgSWYgV2ViUlRDIGFwcHMgd29yayBmcm9tIG15IGhvbWUg YnV0IG5vdCB3aGVuIEkgY2hlY2sgaW4gdG8gYSBob3RlbCBvciBnbyB0byBteSBvZmZpY2UgdGhl biB3ZSByZWFsbHkgaGF2ZSBhIHByb2JsZW0gZXZlbiB3aXRoIHRoZSBtb3N0IGJhc2ljIGF1ZGlv IG9ubHkgYXBwcy4NCg0KSW4gY29uY2x1c2lvbiwgbGV0J3MgZm9jdXMgb24gdGhlIHJlcXVpcmVt ZW50cyBzcGVjaWZpZWQgaW4gdGhlIGNoYXJ0ZXIsIGNvbmNlbnRyYXRlIG9uIG1vcmUgYmFzaWMg aXNzdWVzIHJlbGF0aW5nIHRvIHNlY3VyaXR5IGFuZCBkZXBsb3ltZW50IHRoYXQgcmVhbGx5IG5l ZWQgdG8gYmUgc29sdmVkIG5vdy4gU29tZSBvZiB0aGUgbW9yZSBzb3BoaXN0aWNhdGVkIGZlYXR1 cmVzIHN1Y2ggYXMgU1NSQyBzaWduYWxpbmcgYW5kIGJ1bmRsaW5nIGNvdWxkIGJlY29tZSBwYXJ0 IG9mIFdlYlJUQyAyLjAuDQoNCkxldCdzIG1ha2UgV2ViUlRDIDEuMCBzdWNjZXNzZnVsIGFzIHNv b24gYXMgcG9zc2libGUuDQoNClJlZ2FyZHMNCkFuZHkNCg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgScOxYWtpIEJheiBDYXN0aWxs bw0KPiBTZW50OiAxOCBKdW5lIDIwMTMgMTc6MzYNCj4gVG86IHJ0Y3dlYkBpZXRmLm9yZw0KPiBT dWJqZWN0OiBbcnRjd2ViXSBSZXF1ZXN0aW5nICJTRFAgb3Igbm90IFNEUCIgZGViYXRlIHRvIGJl IHJlLW9wZW5lZA0KPiANCj4gSGkgYWxsLCBJIHJlLXNlbmQgdGhpcyBtYWlsIGluIGEgbmV3IHRo cmVhZC4NCj4gDQo+IA0KPiBEZWFyIFdHIENoYWlycywNCj4gDQo+IFdpdGggYWxsIGR1ZSByZXNw ZWN0LCBJTUhPIHRoZXJlIGlzIHRvbyBtdWNoIGNvbnRyb3ZlcnN5IGFib3V0IFNEUA0KPiB1c2Fn ZSBpbiBXZWJSVEMgc28gSSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgdGhlIFdHIHRvIHJlb3BlbiB0 aGUgIlNEUA0KPiBvciBub3QgU0RQIiBkZWJhdGUuDQo+IA0KPiBJIHdvdWxkIGFsc28gYXBwcmVj aWF0ZSB0aGF0IHRob3NlIGluIGZhdm91ciBvZiBtYW5kYXRpbmcgU0RQIGFzIHRoZQ0KPiBjb3Jl IGNvbW11bmljYXRpb24gZm9yIFdlYlJUQyBleHBsYWluIHRoZWlyIHJhdGlvbmFsZSBhZ2FpbiAo Z2l2ZW4gdGhlDQo+IG51bWJlciBvZiBhcmd1bWVudHMgYWdhaW5zdCBTRFAgYW5kIHRoZSBmcnVz dHJhdGlvbiBTRFAgaXMgY2F1c2luZyksDQo+IGFuZCBhbHNvIHRoYXQgdGhleSBnaXZlIGFyZ3Vt ZW50cyBhbmQgcmVzcG9uc2VzIHRvIGFsbCB0aGUgU0RQIHJlbGF0ZWQNCj4gaXNzdWVzIG5pY2Vs eSBzdW1tYXJpemVkIGluIHRoaXMgbWFpbDoNCj4gDQo+ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50L21zZzA3ODczLmh0bWwNCj4gDQo+IA0KPiBU aGFua3MgYSBsb3QuDQo+IA0KPiANCj4gLS0NCj4gScOxYWtpIEJheiBDYXN0aWxsbw0KPiA8aWJj QGFsaWF4Lm5ldD4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== From harald@alvestrand.no Thu Jun 20 08:32:56 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B3321F9C99 for ; Thu, 20 Jun 2013 08:32:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6whBWiMS4fy for ; Thu, 20 Jun 2013 08:32:50 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA3721F94D3 for ; Thu, 20 Jun 2013 08:32:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 61BD739E1EE for ; Thu, 20 Jun 2013 17:32: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 HsDHOKpKQ4Q0 for ; Thu, 20 Jun 2013 17:32:44 +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 2A60F39E057 for ; Thu, 20 Jun 2013 17:32:44 +0200 (CEST) Message-ID: <51C3209B.1030501@alvestrand.no> Date: Thu, 20 Jun 2013 17:32:43 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040105080908080701020701" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 15:32:56 -0000 This is a multi-part message in MIME format. --------------040105080908080701020701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/19/2013 10:15 PM, Martin Thomson wrote: > On 19 June 2013 13:08, Robin Raymond > wrote: > > One thing that is missing for CU-RTCWeb is the JavaScript shim > that proves that the SDP / SIP folks can produce a reasonable > implementation for the simple API they do need to interface with > SIP/SDP based devices and infrastructure. I know it shouldn't be > Skype job to produce that shim but I don't think anyone will adopt > anything unless it's demonstrably easy for the SIP world (unless I > misunderstand their objections). > > > We sketched out some designs for this that indicated that it is at > least feasible. It's not that easy though - prancer in particular > complicates things considerably - and we managed to find more > important things to spend time on before we could do anything > significant. Full compliance with the specification, rather than just > an SDP implementation, is not something that is easily replicated. I think interoperability with an application written to the implementations that are based on the current specifications (that is - a Javascript application that you could load into both Chrome and your demo of CU-RTCWeb, using a JS shim in your demo, and have them talk to each other) would be a pretty compelling argument. If it didn't use PR-Answer, that would only detract a little bit from the compellingness. --------------040105080908080701020701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    On 06/19/2013 10:15 PM, Martin Thomson wrote:
    On 19 June 2013 13:08, Robin Raymond <robin@hookflash.com> wrote:
    One thing that is missing for CU-RTCWeb is the JavaScript shim that proves that the SDP / SIP folks can produce a reasonable implementation for the simple API they do need to interface with SIP/SDP based devices and infrastructure. I know it shouldn't be Skype job to produce that shim but I don't think anyone will adopt anything unless it's demonstrably easy for the SIP world (unless I misunderstand their objections).

    We sketched out some designs for this that indicated that it is at least feasible.  It's not that easy though - prancer in particular complicates things considerably - and we managed to find more important things to spend time on before we could do anything significant.  Full compliance with the specification, rather than just an SDP implementation, is not something that is easily replicated.

    I think interoperability with an application written to the implementations that are based on the current specifications (that is - a Javascript application that you could load into both Chrome and your demo of CU-RTCWeb, using a JS shim in your demo, and have them talk to each other) would be a pretty compelling argument.

    If it didn't use PR-Answer, that would only detract a little bit from the compellingness.


    --------------040105080908080701020701-- From roman@telurix.com Thu Jun 20 08:47:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD3721F9DE9 for ; Thu, 20 Jun 2013 08:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jvasvzp0gUuV for ; Thu, 20 Jun 2013 08:47:09 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 19FEB21F9DE8 for ; Thu, 20 Jun 2013 08:47:08 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so1847981wid.4 for ; Thu, 20 Jun 2013 08:47: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=vbVB/WNYIY4cZvV5cP/gRo+9UNWspe6HCYjRUfB0NE4=; b=asSuLAQmOJ85E10Bhy5yWYtxtQHmsjeAmDts+M4NnjFjHlcN4p80l/ua9X9+Am2AfA 0VMwmtH2YyC+01sYyucoCOLBCD70DxnOKNouXlhrjE9OsUxJN2wriv5zh5+rFi1Sku7/ Yg2ivXV5sUAAcVCnLQ6wRdxBbdHY9DUUr6Ivfxowi3iXLcmW36Nf09fAF0lTAjWChnWP DP4jiIPaIXtejCoHVtfPXuqSIzrnFmz9qfoLLMTiX9rcxd9cJSkHCIKQalB2M9UsVxW4 JgENW+EJApRGM05rpyr04EnZeZNn3HdjfwkPb2mivspCXynljN8biBoXhHq1QqmUY2TS oEBw== X-Received: by 10.180.185.133 with SMTP id fc5mr41633wic.8.1371743228242; Thu, 20 Jun 2013 08:47:08 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [2a00:1450:400c:c03::22d]) by mx.google.com with ESMTPSA id u9sm1336741wif.6.2013.06.20.08.47.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 08:47:07 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so5551722wes.18 for ; Thu, 20 Jun 2013 08:47:06 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.195.12.133 with SMTP id eq5mr6183089wjd.27.1371743226652; Thu, 20 Jun 2013 08:47:06 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Thu, 20 Jun 2013 08:47:06 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115D2150@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF115D2150@MCHP04MSX.global-ad.net> Date: Thu, 20 Jun 2013 11:47:06 -0400 Message-ID: From: Roman Shpount To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=047d7bb04c90bf6c6504df97dbc9 X-Gm-Message-State: ALoCoQl6YraCiRSCH3WMZ/MMoKvyWt1bnaO8MNfWyhCpg/zE45yqElSnhPvpGdVoAEoRHqXcB4V8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 15:47:10 -0000 --047d7bb04c90bf6c6504df97dbc9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My question is, would this WebRTC 1.0 API ever become a standard without SDP portion of it being well defined? Right not this is an opaque blob with little or no definition attached to it. It can be modified and extended in non-compatible way by an implementer with no changes to the actual external API surface. I do not think we are anywhere near the working API unless we specify exactly what SDP can be generated WebRTC compliant browser and what is an SDP acceptable to WebRTC compliant browser and lock it down. Ideally it should be defined in a way that can be extended in the future (ie forcing only certain features to be used via some sort of version based initialization). _____________ Roman Shpount On Thu, Jun 20, 2013 at 11:25 AM, Hutton, Andrew < andrew.hutton@siemens-enterprise.com> wrote: > > IMHO the re-opening of the debate on "SDP or not SDP" is not the right > approach to making progress at this moment in time as it would only serve > to slow the process even further and reopen all the old arguments. > > The agreement albeit a W3C agreement was to assess the requirements for a > lower level API (Without SDP) once a first release of WebRTC is achieved > and I think we should not reverse that agreement there was strong consens= us > on that at the time. > > However I think we should have a close look at our priorities and what we > really need to get to what would effectively be WebRTC 1.0. My feeling is > that we are trying to do too much. > > Let's take a short pause for breath and think about what we really need > for a successful WebRTC 1.0 as I think we are maybe focused on the wrong > issues and we seem to have got diverted from the priorities set in the > charter (http://datatracker.ietf.org/wg/rtcweb/charter/). > > For example to make even basic WebRTC applications easily deployable we > need to resolve the firewall issues as stated in the charter (bullet 3). = We > don't even have an adopted draft for that yet but I hope that can be > changed very soon. If WebRTC apps work from my home but not when I check > in to a hotel or go to my office then we really have a problem even with > the most basic audio only apps. > > In conclusion, let's focus on the requirements specified in the charter, > concentrate on more basic issues relating to security and deployment that > really need to be solved now. Some of the more sophisticated features suc= h > as SSRC signaling and bundling could become part of WebRTC 2.0. > > Let's make WebRTC 1.0 successful as soon as possible. > > Regards > Andy > > > > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of I=F1aki Baz Castillo > > Sent: 18 June 2013 17:36 > > To: rtcweb@ietf.org > > Subject: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened > > > > Hi all, I re-send this mail in a new thread. > > > > > > Dear WG Chairs, > > > > With all due respect, IMHO there is too much controversy about SDP > > usage in WebRTC so I would like to request the WG to reopen the "SDP > > or not SDP" debate. > > > > I would also appreciate that those in favour of mandating SDP as the > > core communication for WebRTC explain their rationale again (given the > > number of arguments against SDP and the frustration SDP is causing), > > and also that they give arguments and responses to all the SDP related > > issues nicely summarized in this mail: > > > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html > > > > > > Thanks a lot. > > > > > > -- > > I=F1aki Baz Castillo > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bb04c90bf6c6504df97dbc9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My question is, would this WebRTC 1.0 API ever become a standard without SD= P portion of it being well defined? Right not this is an opaque blob with l= ittle or no definition attached to it. It can be modified and extended in n= on-compatible way by an implementer with no changes to the actual external = API surface. I do not think we are anywhere near the working API unless we = specify exactly what SDP can be generated WebRTC compliant browser and what= is an SDP acceptable to WebRTC compliant browser and lock it down. Ideally= it should be defined in a way that can be extended in the future (ie forci= ng only certain features to be used via some sort of version based initiali= zation).
    _____________
    Roman Shpount


    On Thu, Jun 20, 2013 at 11:25 AM, Hutton= , Andrew <andrew.hutton@siemens-enterprise.com><= /span> wrote:

    IMHO the re-opening of the debate on "SDP or not SDP" is not the = right approach to making progress at this moment in time as it would only s= erve to slow the process even further and reopen all the old arguments.

    The agreement albeit a W3C agreement was to assess the requirements for a l= ower level API (Without SDP) once a first release of WebRTC is achieved and= I think we should not reverse that agreement there was strong consensus on= that at the time.

    However I think we should have a close look at our priorities and what we r= eally need to get to what would effectively be WebRTC 1.0. My feeling is th= at we are trying to do too much.

    Let's take a short pause for breath and think about what we really need= for a successful WebRTC 1.0 as I think we are maybe focused on the wrong i= ssues and we seem to have got diverted from the priorities set in the chart= er (http://datatracker.ietf.org/wg/rtcweb/charter/).

    For example to make even basic WebRTC applications easily deployable we nee= d to resolve the firewall issues as stated in the charter (bullet 3). We do= n't even have an adopted draft for that yet but I hope that can be chan= ged very soon. =A0If WebRTC apps work from my home but not when I check in = to a hotel or go to my office then we really have a problem even with the m= ost basic audio only apps.

    In conclusion, let's focus on the requirements specified in the charter= , concentrate on more basic issues relating to security and deployment that= really need to be solved now. Some of the more sophisticated features such= as SSRC signaling and bundling could become part of WebRTC 2.0.

    Let's make WebRTC 1.0 successful as soon as possible.

    Regards
    Andy




    > -----Original Message-----
    > From: rtcweb-bounces@ietf.o= rg [mailto:rtcweb-bounces@ie= tf.org] On
    > Behalf Of I=F1aki Baz Castillo
    > Sent: 18 June 2013 17:36
    > To: rtcweb@ietf.org
    > Subject: [rtcweb] Requesting "SDP or not SDP" debate to be r= e-opened
    >
    > Hi all, I re-send this mail in a new thread.
    >
    >
    > Dear WG Chairs,
    >
    > With all due respect, IMHO there is too much controversy about SDP
    > usage in WebRTC so I would like to request the WG to reopen the "= SDP
    > or not SDP" debate.
    >
    > I would also appreciate that those in favour of mandating SDP as the > core communication for WebRTC explain their rationale again (given the=
    > number of arguments against SDP and the frustration SDP is causing), > and also that they give arguments and responses to all the SDP related=
    > issues nicely summarized in this mail:
    >
    > =A0 http://www.ietf.org/mail-archive/web/rtcweb/c= urrent/msg07873.html
    >
    >
    > Thanks a lot.
    >
    >
    > --
    > I=F1aki Baz Castillo
    > <ibc@aliax.net>
    > _______________________________________________
    > rtcweb mailing list
    > rtcweb@ietf.org
    > https://www.ietf.org/mailman/listinfo/rtcweb
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    = https://www.ietf.org/mailman/listinfo/rtcweb

    --047d7bb04c90bf6c6504df97dbc9-- From matthew.kaufman@skype.net Thu Jun 20 08:57:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F45321F9CB2 for ; Thu, 20 Jun 2013 08:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1sneDfDOqRv for ; Thu, 20 Jun 2013 08:57:44 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id D8C8C21F9C9A for ; Thu, 20 Jun 2013 08:57:43 -0700 (PDT) Received: from BL2FFO11FD011.protection.gbl (10.173.161.202) by BL2FFO11HUB026.protection.gbl (10.173.161.50) with Microsoft SMTP Server (TLS) id 15.0.707.0; Thu, 20 Jun 2013 15:57:42 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Thu, 20 Jun 2013 15:57:41 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.171]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0136.001; Thu, 20 Jun 2013 15:57:21 +0000 From: "Matthew Kaufman (SKYPE)" To: Roman Shpount , "Hutton, Andrew" Thread-Topic: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . Thread-Index: AQHObcqPDuRfQhlNY0SczjQsZweh2pk+vz8AgAACnV0= Date: Thu, 20 Jun 2013 15:57:20 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF115D2150@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: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2DAE97TK5EX14MBXC273r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454003)(199002)(189002)(74706001)(66066001)(80022001)(69226001)(65816001)(56816003)(56776001)(31966008)(74876001)(63696002)(20776003)(59766001)(55846006)(74662001)(53806001)(44976003)(46102001)(76796001)(74366001)(33656001)(49866001)(50986001)(54356001)(16406001)(79102001)(6806003)(47976001)(16236675002)(74502001)(54316002)(71186001)(76482001)(512934002)(81342001)(47446002)(77982001)(47736001)(81542001)(76786001)(51856001)(4396001)(77096001)(132733001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB026; H:TK5EX14HUBC105.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 08831F51DC Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 15:57:50 -0000 --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2DAE97TK5EX14MBXC273r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It must be possible for a third party to implement a compatible browser wit= hout referring to anything but the chain of normative references. At the pr= esent time, this is not the case, and would be grounds for not ratifying th= e specification within W3C. Matthew Kaufman ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Roman = Shpount [roman@telurix.com] Sent: Thursday, June 20, 2013 8:47 AM To: Hutton, Andrew Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate = to be re-opened . My question is, would this WebRTC 1.0 API ever become a standard without SD= P portion of it being well defined? --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2DAE97TK5EX14MBXC273r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    It must be possible for a third party to implement a compatible brow= ser without referring to anything but the chain of normative references. At= the present time, this is not the case, and would be grounds for not ratifying the specification within W3C.

    Matthew Kaufman

    From: rtcweb-bounces@ietf.org [rtcweb-bou= nces@ietf.org] on behalf of Roman Shpount [roman@telurix.com]
    Sent: Thursday, June 20, 2013 8:47 AM
    To: Hutton, Andrew
    Cc: rtcweb@ietf.org
    Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not = SDP" debate to be re-opened .

    My question is, would this WebRTC 1.0 API ever become a standard witho= ut SDP portion of it being well defined? 
    --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2DAE97TK5EX14MBXC273r_-- From ibc@aliax.net Thu Jun 20 09:15:35 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82C621F9DF8 for ; Thu, 20 Jun 2013 09:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXlMkT-77wSq for ; Thu, 20 Jun 2013 09:15:35 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 55C1D21F9DED for ; Thu, 20 Jun 2013 09:15:34 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ci6so1071000qab.11 for ; Thu, 20 Jun 2013 09:15:33 -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=RN3h0LE4MRRtK+VA6Lw7yoEwSOWJINIxF8C1zeGzq9U=; b=P6r7y1rR0rKXVsBY2ZS7VHOVg+r9kI4XtH3RGwt00LNuwHfO94uBJPzMCYMuWnjBZQ MWnbe3aN0ZJAm7e/htRrSZwTy90I8UOtQvcYWrWhClkmq5roWrn1b7t1ujSimq/cv/mP /Udo1V56cEZU/AgcQUuEcmh8FAQUpnnMdneQOZhte4T6eEBpPbesVzLU1mklbExjA6rk 9DWSyTbntlCa1HyXWn8vVrKpZd3pVNVAKcygmbRd8FX3Je05p2+eOY/KXhcQYRuCCkOM KL1Xzxldi5o+VDEr5z8+YmUNX6fiAu9Z/I1gzIBL3rfHBAfs9hbJhXEwhg/X5kVmsUYe r9hw== X-Received: by 10.49.35.108 with SMTP id g12mr1188394qej.86.1371744933546; Thu, 20 Jun 2013 09:15:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Thu, 20 Jun 2013 09:15:13 -0700 (PDT) In-Reply-To: <51C3209B.1030501@alvestrand.no> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 20 Jun 2013 18:15:13 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmW0LX2gKaGd81sOFzOExIv2cnYZelpEpq7e1votjs2s8dVtIKBW+r15z1ndadTa4vuE4BU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:15:35 -0000 2013/6/20 Harald Alvestrand : > I think interoperability with an application written to the implementatio= ns > that are based on the current specifications (that is - a Javascript > application that you could load into both Chrome and your demo of CU-RTCW= eb, > using a JS shim in your demo, and have them talk to each other) would be = a > pretty compelling argument. Hi Harald, with all due respect: So, it seems that the current SDP-based spec is God, and if somebody wants to propose another alternative, it must be compatible with God, regardless that God is not yet a proven standard and what some of us are asserting is that God is bad, very bad. Am I right? IMHO it would be much more interesting a JS demo that takes the SDP generated by Chrome and "converts" it into a Jingle XML session description (I mean XEP-0167), and that can interoperate (via XMPP over WebSocket or whatever) with a XMPP/Jingle endpoint by incrementally sending/receiving transport (ICE stuff) and media capabilities (as XEP-0167 allows) in different XMPP messages. And it would also be interesting a JS demo that interoperates with a SIP gateway and is able to perform the "hold" / "unhold" feature so widely extended in SIP world (via reINVITE with a=3Dinactive/sendonly and 200 "OK" with a=3Dinactive/recvonly). It seems that we must prove how bad SDP is while the fact is that those in favour of the SDP-based model should demonstrate how "flexible" and powerful it is. As far as we can see in the spec development, SDP does not seem to be so good and hence it should be questionable IMHO. Just my opinion. Best regards. -- I=C3=B1aki Baz Castillo From andrew.hutton@siemens-enterprise.com Thu Jun 20 09:28:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3853B21F9DEA for ; Thu, 20 Jun 2013 09:28:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2uSw8+qYO89 for ; Thu, 20 Jun 2013 09:28:48 -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 87C6821F9E38 for ; Thu, 20 Jun 2013 09:28:44 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 6ACA41EB83F1; Thu, 20 Jun 2013 18:28:40 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Thu, 20 Jun 2013 18:28:40 +0200 From: "Hutton, Andrew" To: Roman Shpount Thread-Topic: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . Thread-Index: AQHObEJByY7ZqkO+CkSPIPqSfmn6rpk+jpkggAASMACAACdKMA== Date: Thu, 20 Jun 2013 16:28:40 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115D233F@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF115D2150@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:28:52 -0000 This has been debated many times in the working group and consensus in the = past was to move forward with an SDP based API so evidence suggests that th= e majority of the working groups (IETF & W3C) believe it is possible to hav= e a WebRTC 1.0 API which uses SDP. If we need to rigorously define an SDP profile for RTCWEB then that is what= we should be doing rather like we do for RTP in the rtp-usage draft. In fa= ct I think somebody started that work but there has been very little discus= sion in that direction. It seems to me we are making things more difficult than they need to be by = trying to make complex extensions to SDP as part of WebRTC 1.0 which means = we have a moving target with regards to SDP.=20 If we keep things simple there is more chance of success. Regards Andy > -----Original Message----- > From: Roman Shpount [mailto:roman@telurix.com] > Sent: 20 June 2013 16:47 > To: Hutton, Andrew > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" > debate to be re-opened . >=20 > My question is, would this WebRTC 1.0 API ever become a standard > without SDP portion of it being well defined? Right not this is an > opaque blob with little or no definition attached to it. It can be > modified and extended in non-compatible way by an implementer with no > changes to the actual external API surface. I do not think we are > anywhere near the working API unless we specify exactly what SDP can be > generated WebRTC compliant browser and what is an SDP acceptable to > WebRTC compliant browser and lock it down. Ideally it should be defined > in a way that can be extended in the future (ie forcing only certain > features to be used via some sort of version based initialization). >=20 > _____________ > Roman Shpount >=20 > On Thu, Jun 20, 2013 at 11:25 AM, Hutton, Andrew > wrote: >=20 > IMHO the re-opening of the debate on "SDP or not SDP" is not the right > approach to making progress at this moment in time as it would only > serve to slow the process even further and reopen all the old > arguments. >=20 > The agreement albeit a W3C agreement was to assess the requirements for > a lower level API (Without SDP) once a first release of WebRTC is > achieved and I think we should not reverse that agreement there was > strong consensus on that at the time. >=20 > However I think we should have a close look at our priorities and what > we really need to get to what would effectively be WebRTC 1.0. My > feeling is that we are trying to do too much. >=20 > Let's take a short pause for breath and think about what we really need > for a successful WebRTC 1.0 as I think we are maybe focused on the > wrong issues and we seem to have got diverted from the priorities set > in the charter (http://datatracker.ietf.org/wg/rtcweb/charter/). >=20 > For example to make even basic WebRTC applications easily deployable we > need to resolve the firewall issues as stated in the charter (bullet > 3). We don't even have an adopted draft for that yet but I hope that > can be changed very soon. =A0If WebRTC apps work from my home but not > when I check in to a hotel or go to my office then we really have a > problem even with the most basic audio only apps. >=20 > In conclusion, let's focus on the requirements specified in the > charter, concentrate on more basic issues relating to security and > deployment that really need to be solved now. Some of the more > sophisticated features such as SSRC signaling and bundling could become > part of WebRTC 2.0. >=20 > Let's make WebRTC 1.0 successful as soon as possible. >=20 > Regards > Andy >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of I=F1aki Baz Castillo > > Sent: 18 June 2013 17:36 > > To: rtcweb@ietf.org > > Subject: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened > > > > Hi all, I re-send this mail in a new thread. > > > > > > Dear WG Chairs, > > > > With all due respect, IMHO there is too much controversy about SDP > > usage in WebRTC so I would like to request the WG to reopen the "SDP > > or not SDP" debate. > > > > I would also appreciate that those in favour of mandating SDP as the > > core communication for WebRTC explain their rationale again (given > the > > number of arguments against SDP and the frustration SDP is causing), > > and also that they give arguments and responses to all the SDP > related > > issues nicely summarized in this mail: > > > > =A0 http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html > > > > > > Thanks a lot. > > > > > > -- > > I=F1aki Baz Castillo > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Thu Jun 20 09:42:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1136121F9DCA for ; Thu, 20 Jun 2013 09:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWlLDAmf+6VU for ; Thu, 20 Jun 2013 09:42:14 -0700 (PDT) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id D4F1721F9A58 for ; Thu, 20 Jun 2013 09:42:13 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id cz11so4093222qeb.22 for ; Thu, 20 Jun 2013 09:42:13 -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=3D9smgLRhDdP2FK7u8+ioDhUoKU6j9UMMUuaC+kkiFU=; b=Y7sqxIZJM/lKsMqO4etshU5uWWsKK7hVaL9GphftqLQSWJ3Y7MWm8AkGV06mUHZfo1 vJZtlQwQz4XyPy/SKO8q1zHtA0DNDETrfPwLQr422tIjW92ueV+LdQ3FdAXW2yR6fKdO tl7wf8beKqhJn7sK2yChijI6Bms2WVUhv9gjSqjYJ7zjY9FiuIMYB99S1XSbmE+jPcz+ 20efKcnQ55E8UyGeXkI8zTUqecUjlQN/Hfu7jLGS5Aw1Ld/B16xFhl2g6cYv7kAFqJVB bd3PhtJ1zmIukZksiOb/o/9D4jdJFli+rMqChhMd0VVWheRJjylu+N1Z5sNhxWomEHnz uWQQ== X-Received: by 10.224.177.201 with SMTP id bj9mr9911298qab.14.1371746533177; Thu, 20 Jun 2013 09:42:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Thu, 20 Jun 2013 09:41:53 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115D233F@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF115D2150@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF115D233F@MCHP04MSX.global-ad.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 20 Jun 2013 18:41:53 +0200 Message-ID: To: "Hutton, Andrew" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmmPXizAnavrZ8qNvtcLDjSIg7YTArdNZvXJUX7Q+iFqfq0PHH3bnOhHdcfxzKF+wSJu+/w Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:42:19 -0000 2013/6/20 Hutton, Andrew : > This has been debated many times in the working group and consensus in th= e past was to move forward with an SDP based API so evidence suggests that = the majority of the working groups (IETF & W3C) believe it is possible to h= ave a WebRTC 1.0 API which uses SDP. > > If we need to rigorously define an SDP profile for RTCWEB then that is wh= at we should be doing rather like we do for RTP in the rtp-usage draft. In = fact I think somebody started that work but there has been very little disc= ussion in that direction. > > It seems to me we are making things more difficult than they need to be b= y trying to make complex extensions to SDP as part of WebRTC 1.0 which mean= s we have a moving target with regards to SDP. > > If we keep things simple there is more chance of success. Hi Andrew, please don't take me wrong but: So the only arguments pro-SDP are "it was debated many times" (it seems it does not matter than many people that agreed then have changed their mind after getting experience), "let do something simple for now based on SDP, something that allows a simple PSTN call" (so SDP will be here forever and any future WebRTC app will have to deal with SDP nightmares and will be subject to its O/A model, forever and ever). -- I=C3=B1aki Baz Castillo From robin@hookflash.com Thu Jun 20 09:55:03 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE74121F9E8F for ; Thu, 20 Jun 2013 09:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.584, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2saRtkNIKrB4 for ; Thu, 20 Jun 2013 09:55:02 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C436821F9E8B for ; Thu, 20 Jun 2013 09:55:02 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e11so17489337iej.29 for ; Thu, 20 Jun 2013 09:55:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:x-gm-message-state; bh=E4hhg2EGA2u9cQTIijijpo5R0XCliSoIp6OV7pb28ZI=; b=lY49w59fFt+uR6WKMHZfbiFdoeYPocbDg/3eL3wWCf6bIMz387qj4qtxa88RwIIEVc mXcd/0qKya1lUBBTWPId8Xf3D3ShSdBzDFyAR5AhRm68AEA+1qA5t9fuCa2G4StItYCL w7vLFpD0aTu5Fs0loCDL6bWZAKbazWSJ1UxazbFfYosiIE4btXuWWTS4kdWIDdadvmXD aeDOCi+AHO/DciNsvFxAVIQurqGl2XFygFS0Q+m3jbX68YASRGgBjttWHprV2MrniIva v0ARLQ+KWayzthk/le2Mu+jcV5q5/ywHeM6fqIu3V9u+iSqG69LdJlyZCEXE4kO5Q9je lw8w== X-Received: by 10.50.176.228 with SMTP id cl4mr226504igc.7.1371747302385; Thu, 20 Jun 2013 09:55:02 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id ct8sm1053404igb.7.2013.06.20.09.55.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 09:55:01 -0700 (PDT) Message-ID: <51C333E1.1030709@hookflash.com> Date: Thu, 20 Jun 2013 12:54:57 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary="------------080301060004050607050305" X-Gm-Message-State: ALoCoQkD3O1tGtRqf3UilKF+XN4XVKuXp9Zb5beHR/G9gNRvWI/LOfqGEYoP1NEOv1ng9A0ND/+R Subject: [rtcweb] WebRTC JS object API with SDP shim option X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:55:03 -0000 This is a multi-part message in MIME format. --------------080301060004050607050305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit You are right. It's time for those of us who are begging for an alternative to SDP to come up with an alternative. I'm willing to lead such an effort. I just ask others to please have an open mind. I absolutely do understand the need for the SIP world to have an easy API they can use for SDP. But I also know SDP as an primary surface API is making anything beyond a basic calling a requirement to mangle SDP as a mechanism to control and obtain properties from an underlying media/RTC engine. I think there is a really good compromise. That is to provide an API that will adhere to the security policies needed (e.g. respects the need to require ICE establishment), but provides a simple shim API similar to what people already have with SDP but not be required to use for those who want to a more direct approach. There's no need to "burn" the entire thing to the ground and start over and that is _not_ my desire. This WebRTC thing must succeed but I can't imagine the W3C accepting our proposal for mangling SDP as a primary surface API to do common edge case scenarios. WIth an alternative proposal that satisfies both camps, I believe they could accept and we can stop the anit-SDP crowd grumblings once and for all. To that end I'm going to write two drafts: draft-raymond-webrtc-js-object-api-rationale-00 (to explain requirements, philosophy, methodology, benefits/pitfalls, use cases that are difficult/impossible with SDP+O/A) draft-raymond-webrtc-js-object-api-00 (to outline the actual API) Plus, I'll produce a shim on top of whatever API that will allow the SDP folks to have a simple SDP based API similar to what exists now but is entirely written in JavaScript to prove that this can be done. I really want a viable solutions for all interested in having a really good proposal API to ultimately become accepted by the W3C. If anyone has anything I should add to either of these drafts or wants to be involved, please contact me. -Robin Christer Holmberg 20 June, 2013 12:55 AM Hi, At the virtual interim, the Plan A and Plan B folks were asked to sit down and try to come up with a compromise "Plan AB" solution. I guess it would be good if people that don't want SDP could try to come up with a compromise "CU No Plan" solution :) Regards, Christer --------------080301060004050607050305 Content-Type: multipart/related; boundary="------------020901060301090407040902" --------------020901060301090407040902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    You are right. It's time for those of us who are begging for an alternative to SDP to come up with an alternative.

    I'm willing to lead such an effort. I just ask others to please have an open mind. I absolutely do understand the need for the SIP world to have an easy API they can use for SDP. But I also know SDP as an primary surface API is making anything beyond a basic calling a requirement to mangle SDP as a mechanism to control and obtain properties from an underlying media/RTC engine.

    I think there is a really good compromise. That is to provide an API that will adhere to the security policies needed (e.g. respects the need to require ICE establishment), but provides a simple shim API similar to what people already have with SDP but not be required to use for those who want to a more direct approach.

    There's no need to "burn" the entire thing to the ground and start over and that is _not_ my desire.

    This WebRTC thing must succeed but I can't imagine the W3C accepting our proposal for mangling SDP as a primary surface API to do common edge case scenarios. WIth an alternative proposal that satisfies both camps, I believe they could accept and we can stop the anit-SDP crowd grumblings once and for all.

    To that end I'm going to write two drafts:
    draft-raymond-webrtc-js-object-api-rationale-00 (to explain requirements, philosophy, methodology, benefits/pitfalls, use cases that are difficult/impossible with SDP+O/A)
    draft-raymond-webrtc-js-object-api-00 (to outline the actual API)

    Plus, I'll produce a shim on top of whatever API that will allow the SDP folks to have a simple SDP based API similar to what exists now but is entirely written in JavaScript to prove that this can be done.

    I really want a viable solutions for all interested in having a really good proposal API to ultimately become accepted by the W3C.

    If anyone has anything I should add to either of these drafts or wants to be involved, please contact me.

    -Robin


    20 June, 2013 12:55 AM
    Hi,


    At the virtual interim, the Plan A and Plan B folks were asked to sit down and try to come up with a compromise "Plan AB" solution.

    I guess it would be good if people that don't want SDP could try to come up with a compromise "CU No Plan" solution :)

    Regards,

    Christer

    --------------020901060301090407040902 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------020901060301090407040902-- --------------080301060004050607050305-- From pthatcher@google.com Thu Jun 20 09:58:58 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668BD21F9A3A for ; Thu, 20 Jun 2013 09:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpvgOpccqtRu for ; Thu, 20 Jun 2013 09:58:57 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9851321F9A31 for ; Thu, 20 Jun 2013 09:58:57 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp16so6453283pbb.0 for ; Thu, 20 Jun 2013 09:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ANWeHQ5E8PVmKrghBWPMm9VeP7s3Dm0tS0Tt0WlsGNU=; b=XrlwKBAXP2TM6WP6VCpi+3x2u/64Ili8gHEO2zZoBbuOhF9rDG7gnwVaS9+VgpnogO Gf4k27aZ/tbZVfC/mZ79U3/ZWv7o/xUvsDdU6iMengTB67FrYHjPAd4CctI3BKDp7qWh gaVPO9WqVg6QKybeL+6+Xb3iEW7g2XYuv98Uoxjjs/qJ0Ag+aO2Yth+IvAPdNMvBg88e +Er70/i8Zc19yBopZWaD/bTnqC4BLyNkdYl67DC1F3FgUEemTG5EuKafX/YfDjQ/aiYD mEu2eI91KRFHkUnY68/KkfHLOn4JD2nMU0mPuBaQBE5G5R2mKToCoof51iBL2GJl/Erj iaAQ== 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=ANWeHQ5E8PVmKrghBWPMm9VeP7s3Dm0tS0Tt0WlsGNU=; b=dY+inV+uXW9ibJWc5PSn4L5UYUPzIl4TT7wCu+P0YgHWrbsNU9AjJmS3j84kQOtpwm 5BBQjckOBwKBr6EiEp/7GrqC0X2a2CgTS4Xw7F8hQmOuIbl2/C2+aUvslK2ZuqWqNPU1 oJWLB/2Td5atnAX0NSNHL+7Zpxmxvu+fAuX++GSWNKGp+AxXynbFZ+OxTW2ArbsTVkie k12e1i2lRsWsEj2NuohCg5EaAUrMOFYBAN/4ii14jqS06+pDgWj0N/tD2Jh0vtWLccoy LqlKGV7zZ0BWpvExRs1o0Boa3D4D7AV9XmQFLrY42c23m7cjJoCz3n6bXNmLTYhqjloj JKpw== X-Received: by 10.66.122.163 with SMTP id lt3mr12275730pab.219.1371747537313; Thu, 20 Jun 2013 09:58:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Thu, 20 Jun 2013 09:58:16 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115D2150@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF115D2150@MCHP04MSX.global-ad.net> From: Peter Thatcher Date: Thu, 20 Jun 2013 09:58:16 -0700 Message-ID: To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=047d7bf16048aef73804df98dce4 X-Gm-Message-State: ALoCoQnkpF2oYb0X0Oi3+kN3qj1xfsskdZacWlmVuCvY7hLu8cSgAQXEGCM4tGVyLrrp0nq6wVcbQQ4S5H35dz8Dtet7rTnctVyD7FdbsKG3zA5l+EMCtn/4ly6/YsY3MReB9rBeH+72fon2eyn0EAWn/eez6CN8CB6F/AGNKX1/VpFroDDw5ykI1vmP/OhLLFHcoFqqQUv+ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:58:58 -0000 --047d7bf16048aef73804df98dce4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "Some of the more sophisticated features such as SSRC signaling and bundling could become part of WebRTC 2.0" That's tantamount to saying Plan A vs. Plan B vs. NoPlan is part of WebRTC 2.0. Is that what you're suggesting? On Thu, Jun 20, 2013 at 8:25 AM, Hutton, Andrew < andrew.hutton@siemens-enterprise.com> wrote: > > IMHO the re-opening of the debate on "SDP or not SDP" is not the right > approach to making progress at this moment in time as it would only serve > to slow the process even further and reopen all the old arguments. > > The agreement albeit a W3C agreement was to assess the requirements for a > lower level API (Without SDP) once a first release of WebRTC is achieved > and I think we should not reverse that agreement there was strong consens= us > on that at the time. > > However I think we should have a close look at our priorities and what we > really need to get to what would effectively be WebRTC 1.0. My feeling is > that we are trying to do too much. > > Let's take a short pause for breath and think about what we really need > for a successful WebRTC 1.0 as I think we are maybe focused on the wrong > issues and we seem to have got diverted from the priorities set in the > charter (http://datatracker.ietf.org/wg/rtcweb/charter/). > > For example to make even basic WebRTC applications easily deployable we > need to resolve the firewall issues as stated in the charter (bullet 3). = We > don't even have an adopted draft for that yet but I hope that can be > changed very soon. If WebRTC apps work from my home but not when I check > in to a hotel or go to my office then we really have a problem even with > the most basic audio only apps. > > In conclusion, let's focus on the requirements specified in the charter, > concentrate on more basic issues relating to security and deployment that > really need to be solved now. Some of the more sophisticated features suc= h > as SSRC signaling and bundling could become part of WebRTC 2.0. > > Let's make WebRTC 1.0 successful as soon as possible. > > Regards > Andy > > > > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of I=C3=B1aki Baz Castillo > > Sent: 18 June 2013 17:36 > > To: rtcweb@ietf.org > > Subject: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened > > > > Hi all, I re-send this mail in a new thread. > > > > > > Dear WG Chairs, > > > > With all due respect, IMHO there is too much controversy about SDP > > usage in WebRTC so I would like to request the WG to reopen the "SDP > > or not SDP" debate. > > > > I would also appreciate that those in favour of mandating SDP as the > > core communication for WebRTC explain their rationale again (given the > > number of arguments against SDP and the frustration SDP is causing), > > and also that they give arguments and responses to all the SDP related > > issues nicely summarized in this mail: > > > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html > > > > > > Thanks a lot. > > > > > > -- > > I=C3=B1aki Baz Castillo > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bf16048aef73804df98dce4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    "Some of the more sophisticated features such as SSR= C signaling and bundling could become part of WebRTC 2.0"

    That's tantamount to saying Plan A vs. Plan B v= s. NoPlan is part of WebRTC 2.0. =C2=A0Is that what you're suggesting?<= /span>



    On Thu, Jun 20, 2013 at 8:25 AM, Hutton, Andrew <andrew.hutton@siemens-enterprise.com> wrote:

    IMHO the re-opening of the debate on "SDP or not SDP" is not the = right approach to making progress at this moment in time as it would only s= erve to slow the process even further and reopen all the old arguments.

    The agreement albeit a W3C agreement was to assess the requirements for a l= ower level API (Without SDP) once a first release of WebRTC is achieved and= I think we should not reverse that agreement there was strong consensus on= that at the time.

    However I think we should have a close look at our priorities and what we r= eally need to get to what would effectively be WebRTC 1.0. My feeling is th= at we are trying to do too much.

    Let's take a short pause for breath and think about what we really need= for a successful WebRTC 1.0 as I think we are maybe focused on the wrong i= ssues and we seem to have got diverted from the priorities set in the chart= er (http://datatracker.ietf.org/wg/rtcweb/charter/).

    For example to make even basic WebRTC applications easily deployable we nee= d to resolve the firewall issues as stated in the charter (bullet 3). We do= n't even have an adopted draft for that yet but I hope that can be chan= ged very soon. =C2=A0If WebRTC apps work from my home but not when I check = in to a hotel or go to my office then we really have a problem even with th= e most basic audio only apps.

    In conclusion, let's focus on the requirements specified in the charter= , concentrate on more basic issues relating to security and deployment that= really need to be solved now. Some of the more sophisticated features such= as SSRC signaling and bundling could become part of WebRTC 2.0.

    Let's make WebRTC 1.0 successful as soon as possible.

    Regards
    Andy




    > -----Original Message-----
    > From: rtc= web-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
    > Behalf Of I=C3=B1aki Baz Castillo
    > Sent: 18 June 2013 17:36
    > To: rtcweb@ietf.o= rg
    > Subject: [rtcweb] Requesting "SDP or not SDP" debate to be r= e-opened
    >
    > Hi all, I re-send this mail in a new thread.
    >
    >
    > Dear WG Chairs,
    >
    > With all due respect, IMHO there is too much controversy about SDP
    > usage in WebRTC so I would like to request the WG to reopen the "= SDP
    > or not SDP" debate.
    >
    > I would also appreciate that those in favour of mandating SDP as the > core communication for WebRTC explain their rationale again (given the=
    > number of arguments against SDP and the frustration SDP is causing), > and also that they give arguments and responses to all the SDP related=
    > issues nicely summarized in this mail:
    >
    > =C2=A0 http://www.ietf.org/mail-archive/web/rtcwe= b/current/msg07873.html
    >
    >
    > Thanks a lot.
    >
    >
    > --
    > I=C3=B1aki Baz Castillo
    > <ibc@aliax.net>
    > _______________________________________________
    > rtcweb mailing list
    >     rtcweb@ietf.org
    >     https://www.ietf.org/mailman/listinfo/rtcweb
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

    --047d7bf16048aef73804df98dce4-- From andrew.hutton@siemens-enterprise.com Thu Jun 20 10:00:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DDA21F9E6E for ; Thu, 20 Jun 2013 10:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLvPsrJU-nVm for ; Thu, 20 Jun 2013 10:00: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 0BFF321F9EAD for ; Thu, 20 Jun 2013 10:00:17 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id A71E21EB851E; Thu, 20 Jun 2013 19:00:15 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Thu, 20 Jun 2013 19:00:15 +0200 From: "Hutton, Andrew" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . Thread-Index: AQHObEJByY7ZqkO+CkSPIPqSfmn6rpk+jpkggAASMACAACdKMP//6ASAgAAkEHA= Date: Thu, 20 Jun 2013 17:00:14 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115D2432@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF115D2150@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF115D233F@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:00:22 -0000 DQpPbjogMjAgSnVuZSAyMDEzIDE3OjQyIEnDsWFraSBCYXogQ2FzdGlsbG8gV3JvdGU6DQo+IA0K PiBTbyB0aGUgb25seSBhcmd1bWVudHMgcHJvLVNEUCBhcmUgIml0IHdhcyBkZWJhdGVkIG1hbnkg dGltZXMiIChpdA0KPiBzZWVtcyBpdCBkb2VzIG5vdCBtYXR0ZXIgdGhhbiBtYW55IHBlb3BsZSB0 aGF0IGFncmVlZCB0aGVuIGhhdmUNCj4gY2hhbmdlZCB0aGVpciBtaW5kIGFmdGVyIGdldHRpbmcg ZXhwZXJpZW5jZSksICJsZXQgZG8gc29tZXRoaW5nIHNpbXBsZQ0KPiBmb3Igbm93IGJhc2VkIG9u IFNEUCwgc29tZXRoaW5nIHRoYXQgYWxsb3dzIGEgc2ltcGxlIFBTVE4gY2FsbCIgKHNvDQo+IFNE UCB3aWxsIGJlIGhlcmUgZm9yZXZlciBhbmQgYW55IGZ1dHVyZSBXZWJSVEMgYXBwIHdpbGwgaGF2 ZSB0byBkZWFsDQo+IHdpdGggU0RQIG5pZ2h0bWFyZXMgYW5kIHdpbGwgYmUgc3ViamVjdCB0byBp dHMgTy9BIG1vZGVsLCBmb3JldmVyIGFuZA0KPiBldmVyKS4NCj4gDQoNCk5vIGl0IGlzIG5vdCB0 aGUgb25seSBhcmd1bWVudCBpdCBpcyBqdXN0IHN0YXRpbmcgdGhlIGZhY3QgdGhhdCB3ZSBoYWQg dGhlIGRlYmF0ZSBwcmV2aW91c2x5IGluIHdoaWNoIHRoZSBhcmd1bWVudHMgd2VyZSBtYWRlIGFu ZCB0aGUgYmFsYW5jZSB3YXMgaW4gZmF2b3Igb2YgU0RQLiAgQXMgSSBzYWlkIEkgZG9uJ3QgcmVh bGx5IHdhbnQgdG8gcmVvcGVuIGFsbCB0aGUgb2xkIGFyZ3VtZW50cy4NCg0KSSBhbSBzYXlpbmcg dGhhdCBwZW9wbGUgYXJlIGdldHRpbmcgZnJ1c3RyYXRlZCBhbmQgY29uc2lkZXJpbmcgYSBjaGFu Z2UgYmVjYXVzZSB3ZSBhcmUgY29uY2VudHJhdGluZyBvbiBleHRlbmRpbmcgU0RQIHJhdGhlciB0 aGFuIGtlZXBpbmcgdGhpbmdzIHNpbXBsZSBhbmQgZm9jdXNpbmcgb24gdGhlIGN1cnJlbnQgZGVs aXZlcmFibGVzIGFzIHNwZWNpZmllZCBpbiB0aGUgY2hhcnRlci4gIElmIHdlIGhhZCBub3QgZ29u ZSB0aGlzIHJvdXRlIHRoZW4gSSB0aGluayB3ZSB3b3VsZCBoYXZlIG1vcmUgc3VjY2VzcyBhbmQg cGVvcGxlIHdvdWxkIG5vdCBoYXZlIGJlY29tZSBzbyBmcnVzdHJhdGVkLg0KDQpDaGFuZ2luZyBm dW5kYW1lbnRhbCBkZWNpc2lvbnMgYXQgYSBsYXRlIHN0YWdlIGlzIG5vdCBhIG1ham9yIGRlYWwg YW5kIGNvbWVzIHdpdGggZ3JlYXQgY29zdHMgc28gbmVlZHMgZXZlbiBtb3JlIGp1c3RpZmljYXRp b24gdGhhbiB0aGUgb3JpZ2luYWwgZGVjaXNpb24gZGlkLg0KDQpBbmR5Lg0K From harald@alvestrand.no Thu Jun 20 10:04:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A1321F9EA0 for ; Thu, 20 Jun 2013 10:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.349 X-Spam-Level: X-Spam-Status: No, score=-110.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ3fITvFs1-i for ; Thu, 20 Jun 2013 10:04:00 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8F21021F9EB1 for ; Thu, 20 Jun 2013 10:03:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 97C0039E057; Thu, 20 Jun 2013 19:03:54 +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 sIFRETv7URlr; Thu, 20 Jun 2013 19:03:53 +0200 (CEST) Received: from [172.30.42.116] (c-e2fee555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.254.226]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5F97239E1BD; Thu, 20 Jun 2013 19:03:53 +0200 (CEST) Message-ID: <51C335F9.4000900@alvestrand.no> Date: Thu, 20 Jun 2013 19:03:53 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:04:06 -0000 On 06/20/2013 06:15 PM, Iñaki Baz Castillo wrote: > 2013/6/20 Harald Alvestrand : >> I think interoperability with an application written to the implementations >> that are based on the current specifications (that is - a Javascript >> application that you could load into both Chrome and your demo of CU-RTCWeb, >> using a JS shim in your demo, and have them talk to each other) would be a >> pretty compelling argument. > Hi Harald, with all due respect: > > So, it seems that the current SDP-based spec is God, and if somebody > wants to propose another alternative, it must be compatible with God, > regardless that God is not yet a proven standard and what some of us > are asserting is that God is bad, very bad. Am I right? Inaki, that's quite a bit below your usual standard of argument. > > IMHO it would be much more interesting a JS demo that takes the SDP > generated by Chrome and "converts" it into a Jingle XML session > description (I mean XEP-0167), and that can interoperate (via XMPP > over WebSocket or whatever) with a XMPP/Jingle endpoint by > incrementally sending/receiving transport (ICE stuff) and media > capabilities (as XEP-0167 allows) in different XMPP messages. You find it interesting. I'm sure you have a particular XMPP/Jingle endpoint in mind that you want to connect to. Create one. Or try, and share with us why it did not work. > > And it would also be interesting a JS demo that interoperates with a > SIP gateway and is able to perform the "hold" / "unhold" feature so > widely extended in SIP world (via reINVITE with a=inactive/sendonly > and 200 "OK" with a=inactive/recvonly). We have people who have demonstrated interoperability with SIP softphones. Some of them are on this list. Can they tell us what happened when they tried? > > It seems that we must prove how bad SDP is while the fact is that > those in favour of the SDP-based model should demonstrate how > "flexible" and powerful it is. As far as we can see in the spec > development, SDP does not seem to be so good and hence it should be > questionable IMHO. The purported value of SDP is interoperability (and the idea that specs defining what it's supposed to mean already exist). If you can show (by code) that this purported value can be achieved without SIP, you have an argument. If you cannot show anything, you have words. > > Just my opinion. > > Best regards. > > -- > Iñaki Baz Castillo > From bernard_aboba@hotmail.com Thu Jun 20 10:16:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB5121F9DBE for ; Thu, 20 Jun 2013 10:16:52 -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.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-V2BUM2DR2c for ; Thu, 20 Jun 2013 10:16:47 -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 D50B321F9A3A for ; Thu, 20 Jun 2013 10:16:46 -0700 (PDT) Received: from BLU169-W19 ([65.55.116.73]) by blu0-omc3-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jun 2013 10:16:46 -0700 X-TMN: [lIAKc5gyXmRs6/oVjWMmT6GjIUHoWs/7] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c9e37372-ee8f-4cf4-b4f2-9d1e43fb64c5_" From: Bernard Aboba To: Peter Thatcher , "Hutton, Andrew" Date: Thu, 20 Jun 2013 10:16:46 -0700 Importance: Normal In-Reply-To: References: , <9F33F40F6F2CD847824537F3C4E37DDF115D2150@MCHP04MSX.global-ad.net>, MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2013 17:16:46.0744 (UTC) FILETIME=[F1815980:01CE6DD9] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:16:52 -0000 --_c9e37372-ee8f-4cf4-b4f2-9d1e43fb64c5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Peter Thatcher said:=20 "Some of the more sophisticated features such as SSRC signaling and bundlin= g could become part of WebRTC 2.0" =0A= =0A= =0A= That's tantamount to saying Plan A vs. Plan B vs. NoPlan is part of WebRTC = 2.0. Is that what you're suggesting?=0A= =0A= =0A= [BA] If the "Plan A" vs. "Plan B" issue is not resolved=2C then WebRTC v1.0= would really only cover audio scenarios adequately. That might make sens= e if we believed that WebRTC API 2.0 would go in a different direction and = be concluded quickly. However=2C I'd observe that just because something is= n't specified in a standard doesn't mean it won't be widely implemented. = And once you have functionality widely implemented=2C you typically have to= deal with backward compatibility - and when the thing to be backward compa= tible with isn't specified=2C then it's a bit of a headache. = --_c9e37372-ee8f-4cf4-b4f2-9d1e43fb64c5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Peter Thatcher said: = =3B

    "Some of the more sophisticated = features such as SSRC signaling and bundling could become part of WebRTC 2.= 0"
    =0A= =0A= =0A=
    That's tantamount to saying Plan A vs= . Plan B vs. NoPlan is part of WebRTC 2.0.  =3BIs that what you're sugg= esting?
    =0A= =0A= =0A=

    [BA] If the "Pl= an A" vs. "Plan B" issue is not resolved=2C then WebRTC v1.0 would really o= nly cover audio scenarios adequately.  =3B That might make sense if we = believed that WebRTC API 2.0 would go in a different direction and be concl= uded quickly. However=2C I'd observe that just because something isn't spec= ified in a standard doesn't mean it won't be widely implemented.  =3B A= nd once you have functionality widely implemented=2C you typically have to = deal with backward compatibility - and when the thing to be backward compat= ible with isn't specified=2C then it's a bit of a headache.  =3B
    <= /div>
    = --_c9e37372-ee8f-4cf4-b4f2-9d1e43fb64c5_-- From pthatcher@google.com Thu Jun 20 10:18:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BF221F9E8F for ; Thu, 20 Jun 2013 10:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toei7L8jTCnm for ; Thu, 20 Jun 2013 10:18:54 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 106F221F9E6E for ; Thu, 20 Jun 2013 10:18:54 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un1so6471162pbc.1 for ; Thu, 20 Jun 2013 10:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0t6Nsy2mXw6onui11vlyVLLzkRi8ZhSWGdZ2X498fkw=; b=nB/MiI14zg/18c94XFGD69uRsM6G1MwiCuGHG9h7B0kKHwc6sFglYEa7usl+85MCpa HEYom3HKQzPpaJdxzFMf3DyrYwpyx0gE/2dOpKyCmaJUe8dgK3IMb14UMHnqpPvDnNPA nRachxY5KLa3FhT8cilVP7nWv4v7KgVtpWnwJhd3kQf8AE8aQA47bw3/DCQ9ukZsz4H9 k8hx5p03dzZUTR84v2W8dKnj8zdGtVIqsnvqXYCyfS0kq+NOrS+WC042q4wGy/Q4bn6O VBpolyvlQe6KNWDJmLAoJdp9CA2AOiN/DyabqcyfGc2lMFUAVG63BtotFf46+WGbPl8w 7ybg== 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=0t6Nsy2mXw6onui11vlyVLLzkRi8ZhSWGdZ2X498fkw=; b=Lk5fKKnbugsevNtam5yHLyT0ykzmtCexzCCUEa7IW0pTORttSvFmnidOiwf02LFgkZ N5/BDluH7jQKdwaheWcXFx9IBwf2xaiUGCe7dwCwxfkAPiak8ii2jpBwTbPFTP3OhZj5 cvzSRovmtIxarc8CLI74u7/xsddXZJLXhljCeeqg5Glt29Tr+kA+mA3/O5SwzJtR5Hc/ QD8aETXI8bK/Od22vT3ADvNj+juFuwSWcuoNsyYnmRr/MPTuHKr8qK9O5kK2Vl/yQFSd ux50bJANxRzYpWPX0GOddPz0WVTQFu2t3w+H2qjeUqydqkGq9xnhRQAWaWrOLBjZjojo pIgA== X-Received: by 10.68.69.108 with SMTP id d12mr8455859pbu.187.1371748733624; Thu, 20 Jun 2013 10:18:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Thu, 20 Jun 2013 10:18:13 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B1A1C@ESESSMB209.ericsson.se> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <7594FB04B1934943A5C02806D1A2204B1C3B1680@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3B1A1C@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Thu, 20 Jun 2013 10:18:13 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=0015174989eefd543404df99237d X-Gm-Message-State: ALoCoQkPz0RjCVb2+XGxb3c3XA6vCknpzhIjTllCo2NWr+vgmIYVqWhYMTFmq4/hDOEK9h97zYp2bd1y8D1I0kEaBfba9BIPuvZZ6X/vbuwAwGkiq/+6m+jqTkYj1FOHMnvEsOw8lnGJEWdXV0Y13+nsmvPeeUZizL5HI57EXhXlgs4qkXrUg39vgqOj/EP5017TV0g9cTxR Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:18:54 -0000 --0015174989eefd543404df99237d Content-Type: text/plain; charset=UTF-8 I think Plan A vs Plan B is very different than No Plan vs. CU. The first is "we both agree on a text blob; what goes in the text blob?". The second is "let's add a few methods" vs. "let's through out everything and start over". If the WG decided "Let's throw out everything and start over with WebRTC 2.0", I'd be happy to help work on a "CU NoPlan" in that context. On the other hand, if the WG said "Let's try adding methods in an incremental way that allow JS to avoid SDP in WebRTC 2.0", I'd be happy to work on that as well. But I don't think CU-RTC is going to work well in the latter, since the authors categorically reject incremental improvement. On Wed, Jun 19, 2013 at 9:55 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>>> Why aren't we using the JavaScript object model for control of > components instead of serializing our control requests via SDP/whatever > format and hoping that it worked? > >>>> > >>> That's a great question. Have you read the CU-RTCWEB proposal? Is it > any closer to what you imagined the RTCWEB API might be? > >>> > >>> My "NoPlan JS API" proposal also allows control of components without > serialize control via a format, if the JS chooses to > >>> do so (SDP is still there if JS wants). It only does so for media > streams, not for transports, but it allows incremental improvement to the > API. > >> So, IF we decide to remove SDP and Offer/Answer, we'll end up arguing > about "Plan C(U) vs No Plan"? :) > > > > I think we already are :). > > At the virtual interim, the Plan A and Plan B folks were asked to sit down > and try to come up with a compromise "Plan AB" solution. > > I guess it would be good if people that don't want SDP could try to come > up with a compromise "CU No Plan" solution :) > > Regards, > > Christer > > --0015174989eefd543404df99237d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I think Plan A vs Plan B is very different than No Plan vs= . =C2=A0CU. =C2=A0The first is "we both agree on a text blob; =C2=A0wh= at goes in the text blob?". =C2=A0The second is "let's add a = few methods" vs. =C2=A0"let's through out everything and star= t over". =C2=A0=C2=A0

    If the WG decided "Let's throw out everything and s= tart over with WebRTC 2.0", I'd be happy to help work on a "C= U NoPlan" in that context. =C2=A0On the other hand, if the WG said &qu= ot;Let's try adding methods in an incremental way that allow JS to avoi= d SDP in WebRTC 2.0", I'd be happy to work on that as well. =C2=A0= But I don't think CU-RTC is going to work well in the latter, since the= authors categorically reject incremental improvement.






    On Wed, Jun 19, 2013 at 9:55 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
    Hi,

    >>>> Why aren't we using the JavaScript object model for co= ntrol of components instead of serializing our control requests via SDP/wha= tever format and hoping that it worked?
    >>>>
    >>> That's a great question. Have you read the CU-RTCWEB propo= sal? Is it any closer to what you imagined the RTCWEB API might be?
    >>>
    >>> My "NoPlan JS API" proposal also allows control of c= omponents without serialize control via a format, if the JS chooses to
    >>> do so (SDP is still there if JS wants). =C2=A0It only does so = for media streams, not for transports, but it allows incremental improvemen= t to the API.
    >> So, IF we decide to remove SDP and Offer/Answer, we'll end up = arguing about "Plan C(U) vs No Plan"? :)
    >
    > I think we already are :).

    At the virtual interim, the Plan A and Plan B folks were asked to sit= down and try to come up with a compromise "Plan AB" solution.
    I guess it would be good if people that don't want SDP could try to com= e up with a compromise "CU No Plan" solution :)

    Regards,

    Christer


    --0015174989eefd543404df99237d-- From matthew@matthew.at Thu Jun 20 10:21:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B3A21F9B6A for ; Thu, 20 Jun 2013 10:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUKq5OfrC0W5 for ; Thu, 20 Jun 2013 10:21:05 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0250321F9EAB for ; Thu, 20 Jun 2013 10:20:38 -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 5C71C250041; Thu, 20 Jun 2013 10:20:38 -0700 (PDT) Message-ID: <51C339EA.3050103@matthew.at> Date: Thu, 20 Jun 2013 10:20:42 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Thatcher References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <7594FB04B1934943A5C02806D1A2204B1C3B1680@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3B1A1C@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:21:11 -0000 On 6/20/2013 10:18 AM, Peter Thatcher wrote: > But I don't think CU-RTC is going to work well in the latter, since > the authors categorically reject incremental improvement. > > As long as the incremental improvement removes the offer/answer state machine, then that statement is false. Matthew Kaufman From pthatcher@google.com Thu Jun 20 10:23:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D311421F93E0 for ; Thu, 20 Jun 2013 10:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFBnT1cCOlO0 for ; Thu, 20 Jun 2013 10:23:46 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id BA19421F9007 for ; Thu, 20 Jun 2013 10:23:44 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro2so6455692pbb.27 for ; Thu, 20 Jun 2013 10:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EFpMae+ZY9tvGegkHa2Q5SVGo0H2o0cSsCn3hcbjsr8=; b=S2Q14Cu1kFZSdhCzkWM6o50h1KxB3o7vANXFD9Bl66PbkQLQYxoZ1S+rPH6lAR3Qts ADjbL0VRwgWyon3q/6dUgh7RoO/6wtbI1s2N+tYcyM/ZlOhM9rHGxDPib1iMugxabFGU xE/MRo/VACCVPICRxdii1gcPBadzfe80kKhsgxaQQm1GEBJjmz139tG6CxDkgcXs66A8 3TFZUKs/j39Zb/YNj6Pkup/GIORcBNl4tYf4du/x17yMjjkFY7YL4ka+LyBzZ7D+ElFt ex6Xi6zyWaPB6/4/I6bqM6Vq6kUSvkd347JTFuui7Xb7g5pL5sSdiYfS4isNIuo8AEAb iKsg== 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=EFpMae+ZY9tvGegkHa2Q5SVGo0H2o0cSsCn3hcbjsr8=; b=SWNbboPLFnN6hYlKb/XjpGOJ3GSaOsPcFkCsbRjSYeAxP2bviExeQjOvj/fW/xVIia XnwseJ3ItSUSyF+4OgSwsEyNIr/LCiI2MYQl4J6ZD6bgoPgmZg3QNSSv7ASTOQ3zF+L0 rMlxrlZwfPtFNZdF5LZSzbggBgeHIFgCJ3+rK6dUWtYkkQ9/mjGKDNxMJPg/dqOyKp0G 9f3xOu0i10cWFadg53CiuBOsSSWVYC2/+Exac25X9jCmoXvemFZz7oikA7GZIFPKphGw wfgPkUk6xPhKKIv0TX0ZD7Vi8F0vXiif9IcsGC9WLbrLALcjA32EatfoXyG2EHbNYPEC KPwA== X-Received: by 10.66.240.7 with SMTP id vw7mr2169722pac.70.1371749024357; Thu, 20 Jun 2013 10:23:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Thu, 20 Jun 2013 10:23:04 -0700 (PDT) In-Reply-To: <51C333E1.1030709@hookflash.com> References: <51C333E1.1030709@hookflash.com> From: Peter Thatcher Date: Thu, 20 Jun 2013 10:23:04 -0700 Message-ID: To: Robin Raymond Content-Type: multipart/related; boundary=047d7b15a54d5186b404df9935aa X-Gm-Message-State: ALoCoQlKJj99ChPTfQo9ErQd2ej0u2TW30THOOjKs28AMI4OxpVDeOy/L9p5uNGRTkoXertcPZcV4etA6TCUJVHjHer47NKqZ6+0OuP+Dj4knBQQ+UpCmzNjxpevloEK0bXEET64hSxLzxbPNCzdEvBjhVWUEzQAF+lqmJPu0g5N17nCjuXr7dS+5XO5/gYGXJgYlWzVPCMb Cc: "" Subject: Re: [rtcweb] WebRTC JS object API with SDP shim option X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:23:48 -0000 --047d7b15a54d5186b404df9935aa Content-Type: multipart/alternative; boundary=047d7b15a54d5186b204df9935a9 --047d7b15a54d5186b204df9935a9 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 20, 2013 at 9:54 AM, Robin Raymond wrote: > > You are right. It's time for those of us who are begging for an > alternative to SDP to come up with an alternative. > > I'm willing to lead such an effort. I just ask others to please have an > open mind. I absolutely do understand the need for the SIP world to have an > easy API they can use for SDP. But I also know SDP as an primary surface > API is making anything beyond a basic calling a requirement to mangle SDP > as a mechanism to control and obtain properties from an underlying > media/RTC engine. > > I think there is a really good compromise. That is to provide an API that > will adhere to the security policies needed (e.g. respects the need to > require ICE establishment), but provides a simple shim API similar to what > people already have with SDP but not be required to use for those who want > to a more direct approach. > > There's no need to "burn" the entire thing to the ground and start over > and that is _not_ my desire. > > This WebRTC thing must succeed but I can't imagine the W3C accepting our > proposal for mangling SDP as a primary surface API to do common edge case > scenarios. WIth an alternative proposal that satisfies both camps, I > believe they could accept and we can stop the anit-SDP crowd grumblings > once and for all. > > To that end I'm going to write two drafts: > draft-raymond-webrtc-js-object-api-rationale-00 (to explain requirements, > philosophy, methodology, benefits/pitfalls, use cases that are > difficult/impossible with SDP+O/A) > draft-raymond-webrtc-js-object-api-00 (to outline the actual API) > > Plus, I'll produce a shim on top of whatever API that will allow the SDP > folks to have a simple SDP based API similar to what exists now but is > entirely written in JavaScript to prove that this can be done. > > How are you going to test that shim without a working implementation of the clean API? One thing you could do is build a shim of clean API -> SDP. Then, you'd have two shims which would make a fun combination (SDP -> clean API -> SDP) and you're prove that SDP munging and the clean API are equivalent in power. Or you could fork Chrome or Firefox. Either way, you have a lot of work ahead of you. Best of luck. > I really want a viable solutions for all interested in having a really > good proposal API to ultimately become accepted by the W3C. > > If anyone has anything I should add to either of these drafts or wants to > be involved, please contact me. > > -Robin > > > Christer Holmberg > 20 June, 2013 12:55 AM > Hi, > > > At the virtual interim, the Plan A and Plan B folks were asked to sit down > and try to come up with a compromise "Plan AB" solution. > > I guess it would be good if people that don't want SDP could try to come > up with a compromise "CU No Plan" solution :) > > Regards, > > Christer > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b15a54d5186b204df9935a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Thu, Jun 20, 2013 at 9:54 AM, Robin Raymond &l= t;robin@hookflash.= com> wrote:

    You are right. It's time for those of us who are begging for an=20 alternative to SDP to come up with an alternative.

    I'm willing to lead such an effort. I just ask others to please have an= =20 open mind. I absolutely do understand the need for the SIP world to have an easy API they can use for SDP. But I also know SDP as an primary=20 surface API is making anything beyond a basic calling a requirement to=20 mangle SDP as a mechanism to control and obtain properties from an=20 underlying media/RTC engine.

    I think there is a really good compromise. That is to provide an API=20 that will adhere to the security policies needed (e.g. respects the need to require ICE establishment), but provides a simple shim API similar=20 to what people already have with SDP but not be required to use for=20 those who want to a more direct approach.

    There's no need to "burn" the entire thing to the ground and = start over=20 and that is _not_ my desire.

    This WebRTC thing must succeed but I can't imagine the W3C accepting ou= r proposal for mangling SDP as a primary surface API to do common edge=20 case scenarios. WIth an alternative proposal that satisfies both camps, I believe they could accept and we can stop the anit-SDP crowd grumblings once and for all.

    To that end I'm going to write two drafts:
    draft-raymond-webrtc-js-object-api-rationale-00 (to explain=20 requirements, philosophy, methodology, benefits/pitfalls, use cases that are difficult/impossible with SDP+O/A)
    draft-raymond-webrtc-js-object-api-00 (to outline the actual API)

    Plus, I'll produce a shim on top of whatever API that will allow the SD= P folks to have a simple SDP based API similar to what exists now but is=20 entirely written in JavaScript to prove that this can be done.


    How are you going to test that= shim without a working implementation of the clean API? =C2=A0
    <= br>
    One thing you could do is build a shim of clean API -> SDP= . =C2=A0Then, you'd have two shims which would make a fun combination (= SDP -> clean API -> SDP) and you're prove that SDP munging and th= e clean API are equivalent in power.

    Or you could fork Chrome or Firefox. =C2=A0
    <= br>
    Either way, you have a lot of work ahead of you. =C2=A0Best o= f luck.

    =C2=A0
    I really want a viable solutions for all interested in having a really=20 good proposal API to ultimately become accepted by the W3C.

    If anyone has anything I should add to either of these drafts or wants=20 to be involved, please contact me.

    -Robin


    =20 20 June, 2013=20 12:55 AM
    Hi,<= br>

    At the virtual interim, the Plan A and Plan B folks were asked to sit down and try to come up with a compromise "Plan AB" solution.

    = I guess it would be good if people that don't want SDP could try to come up=20 with a compromise "CU No Plan" solution :)

    Regards,
    Christer


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


    --047d7b15a54d5186b204df9935a9-- --047d7b15a54d5186b404df9935aa Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 4fc82587359b52ed_0.0.1.1 /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQECAQEB AQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAARCAAZABkDAREA AhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUKBwAAAAAAAAACAQME BQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAAAAAAAAAAAAADAAEEAv/E ACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oADAMBAAIRAxEAPwDuEt+gW/UL et6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJVIl7eXLCaZIGwBl3TY8epPx2+jy2 ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJ Ew/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx+a69/JSf9alIlste0VzaNpeFrcT9KKymotyi aZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mRUfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRD nu5azS8miKqjOTVkKqS/psG37fo1Fbabeg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GA cpOwBeN+U8/IkGbsiS8b7ryogmbzhbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH 4hPOI0DkjZtaJtFxuVEbIUUiyeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJ nYn9dnAQWl722p4ot37yzqnlfp6FrqbwawG8/9k= --047d7b15a54d5186b404df9935aa-- From bernard_aboba@hotmail.com Thu Jun 20 10:25:20 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6C821F9A52 for ; Thu, 20 Jun 2013 10:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-Z9H13Y71vh for ; Thu, 20 Jun 2013 10:25:12 -0700 (PDT) Received: from blu0-omc1-s37.blu0.hotmail.com (blu0-omc1-s37.blu0.hotmail.com [65.55.116.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6F06921F9A4C for ; Thu, 20 Jun 2013 10:25:09 -0700 (PDT) Received: from BLU169-W28 ([65.55.116.8]) by blu0-omc1-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jun 2013 10:25:08 -0700 X-TMN: [ExHn75a2trwK5//e9jDePNYm0O6999Ua] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_42c04f4e-1432-4c8e-9a75-0edba2e785f1_" From: Bernard Aboba To: Roman Shpount , "Hutton, Andrew" Date: Thu, 20 Jun 2013 10:25:08 -0700 Importance: Normal In-Reply-To: References: , <9F33F40F6F2CD847824537F3C4E37DDF115D2150@MCHP04MSX.global-ad.net>, MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2013 17:25:08.0733 (UTC) FILETIME=[1CB6CAD0:01CE6DDB] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:25:21 -0000 --_42c04f4e-1432-4c8e-9a75-0edba2e785f1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roman said:=20 "My question is=2C would this WebRTC 1.0 API ever become a standard without= SDP portion of it being well defined? Right not this is an opaque blob wit= h little or no definition attached to it. It can be modified and extended i= n non-compatible way by an implementer with no changes to the actual extern= al API surface." [BA] I would note that the lack of definition in the SDP blob is not only a= n issue for the WebRTC 1.0 API=2C but it will also be an issue for a lower-= level API if there is a requirement to demonstrate the ability to develop a= shim on top to implement the WebRTC 1.0 API. If WebRTC 1.0 is underspeci= fied=2C and in particular if implementations either differ significantly fr= om each other significantly or extend the functionality in undocumented way= s=2C then a backward compatibility requirement on a lower-level API becomes= very=2C very difficult to satisfy. The practical reality is that a backw= ard compatibility requirement needs to not only demonstrate compatibility w= ith the "WebRTC 1.0 API" specification=2C but also with deployed implementa= tions.=20 Therefore my take is that an underspecified WebRTC 1.0 API effectively pois= ons the well. = --_42c04f4e-1432-4c8e-9a75-0edba2e785f1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Roman said: =3B
    =
    "My question is=2C would this WebRTC 1.0 API ever become a standard wit= hout SDP portion of it being well defined? Right not this is an opaque blob= with little or no definition attached to it. It can be modified and extend= ed in non-compatible way by an implementer with no changes to the actual ex= ternal API surface."

    [BA] I would note that the la= ck of definition in the SDP blob is not only an issue for the WebRTC 1.0 AP= I=2C but it will also be an issue for a lower-level API if there is a requi= rement to demonstrate the ability to develop a shim on top to implement the= WebRTC 1.0 API.  =3B If WebRTC 1.0 is underspecified=2C and in particu= lar if implementations either differ significantly from each other signific= antly or extend the functionality in undocumented ways=2C then a backward c= ompatibility requirement on a lower-level API becomes very=2C very difficul= t to satisfy.  =3B The practical reality is that a backward compatibili= ty requirement needs to not only demonstrate compatibility with the "WebRTC= 1.0 API" specification=2C but also with deployed implementations. =3B<= /div>

    Therefore my take is that an underspecified WebRTC= 1.0 API effectively poisons the well. =3B
    = --_42c04f4e-1432-4c8e-9a75-0edba2e785f1_-- From rlb@ipv.sx Thu Jun 20 10:28:20 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A5521F9E88 for ; Thu, 20 Jun 2013 10:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.322 X-Spam-Level: X-Spam-Status: No, score=-0.322 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XcKpVFLJt+C for ; Thu, 20 Jun 2013 10:28:16 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 84ABA21F9E59 for ; Thu, 20 Jun 2013 10:28:07 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id m1so8395904oag.34 for ; Thu, 20 Jun 2013 10:28:06 -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:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=30wBvqcpVFF0wpFmskMgUUOlroWzP9m4psG0FuBgPoM=; b=XO7twAMT+HO7Ehiw2m93SiOXoIU16W9DjtilFgpHDFnTWeUJgsC6+W0zrSkskIRJMM xe0uGhEWgnKnlN6WZVxxStCIEUQmAThuAOZiw/LMSWPTWMdgTtVrDMSZvfxbyMYp9EYg 2WVHcjSlyOyHYtwe2nCMy8LtQYrnaotvS16u4FQS02rBCfTQDqcTmcSckymOqzzomHhV buv272ciMFDhwAGaufQwzl1P540ytYQ8YW1X+3WtQlpmTxeSaPWvjYz+Sj8JcXzjmjgJ j1Qs7eK2anhbNKm9X4T3i7f2JkQh0biSM95r8g7b70qQAqhuyC7k4SgWNamiK6gGqwcT hgNA== MIME-Version: 1.0 X-Received: by 10.182.60.2 with SMTP id d2mr1974686obr.75.1371749286686; Thu, 20 Jun 2013 10:28:06 -0700 (PDT) Received: by 10.60.26.135 with HTTP; Thu, 20 Jun 2013 10:28:06 -0700 (PDT) X-Originating-IP: [192.1.51.101] In-Reply-To: References: <9F33F40F6F2CD847824537F3C4E37DDF115D2150@MCHP04MSX.global-ad.net> Date: Thu, 20 Jun 2013 13:28:06 -0400 Message-ID: From: Richard Barnes To: "Matthew Kaufman (SKYPE)" Content-Type: multipart/alternative; boundary=089e015387dcf447c104df9944a5 X-Gm-Message-State: ALoCoQmk4HMptNDnJ21yCFK3nUPbLXEZDij7zlFEKGSabu7QZJ9ByR2ayGnfSqnjuGI4Hha8dqzu Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:28:21 -0000 --089e015387dcf447c104df9944a5 Content-Type: text/plain; charset=ISO-8859-1 Perhaps you could specify which references are missing? On Thu, Jun 20, 2013 at 11:57 AM, Matthew Kaufman (SKYPE) < matthew.kaufman@skype.net> wrote: > It must be possible for a third party to implement a compatible browser > without referring to anything but the chain of normative references. At the > present time, this is not the case, and would be grounds for not ratifying > the specification within W3C. > > Matthew Kaufman > > ------------------------------ > *From:* rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of > Roman Shpount [roman@telurix.com] > *Sent:* Thursday, June 20, 2013 8:47 AM > *To:* Hutton, Andrew > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" > debate to be re-opened . > > My question is, would this WebRTC 1.0 API ever become a standard without > SDP portion of it being well defined? > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e015387dcf447c104df9944a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Perhaps you could specify which references are missing?


    On Thu, Ju= n 20, 2013 at 11:57 AM, Matthew Kaufman (SKYPE) <matthew.kaufman@s= kype.net> wrote:
    It must be p= ossible for a third party to implement a compatible browser without referri= ng to anything but the chain of normative references. At the present time, = this is not the case, and would be grounds for not ratifying the specification within W3C.

    Matthew Kaufman

    Fro= m: rtcweb-= bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Roman Shpount [roman@telurix.com]
    Sent: Thursday, June 20, 2013 8:47 AM
    To: Hutton, Andrew
    Cc: rtcweb@ietf= .org
    Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not = SDP" debate to be re-opened .

    My question is, would this WebRTC 1.0 API ever become a standard witho= ut SDP portion of it being well defined?=A0

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


    --089e015387dcf447c104df9944a5-- From robin@hookflash.com Thu Jun 20 10:29:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B4521F9E4D for ; Thu, 20 Jun 2013 10:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8-4WDs3qjJ8 for ; Thu, 20 Jun 2013 10:29:37 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA3521F9F23 for ; Thu, 20 Jun 2013 10:28:58 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so17265502iea.4 for ; Thu, 20 Jun 2013 10:28:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=OAtwOdGs+qCwvXUqaPSZ9wIcGtQ7jhiFpLAOVdA3fSk=; b=JCw35UqTID/E7PDjaJGQLP6Ks7OtIHgn/EOqnTYi9U3RsJQnEtf3SJqaoRG6tBpzim 45D1g/EdwkpHAU48b3CceQkZ7v37T5mU1QL5JDYt8+Pm43PjPqpNqUOtu4BSGZMZhPFm kpFK79pAr0yY74hLzmH1z9cFcQ7WVfLCwBuwSqyHcf+9e6r/A2sJuZuTh3lNt/ud5rRn WhBIeEoYRGUw1GJQLNuHj1ldX+PJtkgbyeIAIJpFlKy0FBI35SnbS3mJ5lDoLakgpcFK 1/BU3JJsqNsJYLY8SxLPiA1sRv0rRaB6YM1A5fZGVOTbvqZrgsk8ClcWaQb8AYKKUI2w k6ow== X-Received: by 10.50.128.36 with SMTP id nl4mr251633igb.38.1371749330425; Thu, 20 Jun 2013 10:28:50 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id ir8sm1185448igb.6.2013.06.20.10.28.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 10:28:49 -0700 (PDT) Message-ID: <51C33BCE.2050203@hookflash.com> Date: Thu, 20 Jun 2013 13:28:46 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: "Hutton, Andrew" References: <9F33F40F6F2CD847824537F3C4E37DDF115D2150@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF115D233F@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF115D2432@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115D2432@MCHP04MSX.global-ad.net> Content-Type: multipart/alternative; boundary="------------040304070807000203010300" X-Gm-Message-State: ALoCoQl4oZT/V+asNDz9U/941imWoMr0mZGP4soG46BVv14KSOA+MY2Y93FbzrvCzxeLelSCGBvv Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:29:39 -0000 This is a multi-part message in MIME format. --------------040304070807000203010300 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Things to consider: 1) Many people who agreed with SDP have since changed their mind 2) If we opt to go with SDP in version #1 knowing that edge cases are causing major pains, those not doing SIP are having great pains, whose to say we will be able to fix it in version 2? At that point deployed systems will actually rely upon it and it will be even harder to affect change and then people will have two methods to do the same thing and have to support both because some browsers will be stuck on version 1 for a long time to come. 3) SDP has become a serialized surface API for object control/properties and the only way to extend this in the future is via SDP extensions; that's a huge part of the issue and objection. That's also probably why so many are focused on extending SDP because they know it doesn't do anything beyond a simple demo at this point and is not ready for prime time deployments and many real-world use cases. 4) There is very few people saying SDP is "good" or "right". The arguments seem to fall into "we've made that choice", "it's too late", "we'll fix it later", "we must get something out now" 5) The cost of fixing it now could be much less than everyone working around this later That's why I'd like to head up with a proposal with a JS shim for supporting SDP. We can get both worlds and put this debate truly to rest and (hopefully) even bring Microsoft onboard. I've written a media engine/RTC so I've got a good handle on what's involved and I've seen the webrtc C++ engine too. So I've got an idea as to what's going on under the hood and I have real world experience having written a SIP softphone client from scratch. Presently I'm trying to mangle Open Peer to utilize this SDP thing. Keep in mind, even I was okay at first with using SDP thinking I'd just parse/generate it until I thought about all its long term consequences as a surface API and then becomes strongly opposed to using it. Making a simple surface API that isn't reliant on SDP and creating a JS SDP shim is entirely possible/feasible and will allow for a flexible future where we don't have tons of competing extensions to SDP with no idea what each browser actually/officially supports. -Robin > Hutton, Andrew > 20 June, 2013 1:00 PM > > No it is not the only argument it is just stating the fact that we had > the debate previously in which the arguments were made and the balance > was in favor of SDP. As I said I don't really want to reopen all the > old arguments. > > I am saying that people are getting frustrated and considering a > change because we are concentrating on extending SDP rather than > keeping things simple and focusing on the current deliverables as > specified in the charter. If we had not gone this route then I think > we would have more success and people would not have become so frustrated. > > Changing fundamental decisions at a late stage is not a major deal and > comes with great costs so needs even more justification than the > original decision did. > > Andy. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Iñaki Baz Castillo > 20 June, 2013 12:41 PM > > Hi Andrew, please don't take me wrong but: > > So the only arguments pro-SDP are "it was debated many times" (it > seems it does not matter than many people that agreed then have > changed their mind after getting experience), "let do something simple > for now based on SDP, something that allows a simple PSTN call" (so > SDP will be here forever and any future WebRTC app will have to deal > with SDP nightmares and will be subject to its O/A model, forever and > ever). > > --------------040304070807000203010300 Content-Type: multipart/related; boundary="------------030905070107000204090203" --------------030905070107000204090203 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

    Things to consider:
    1) Many people who agreed with SDP have since changed their mind
    2) If we opt to go with SDP in version #1 knowing that edge cases are causing major pains, those not doing SIP are having great pains, whose to say we will be able to fix it in version 2? At that point deployed systems will actually rely upon it and it will be even harder to affect change and then people will have two methods to do the same thing and have to support both because some browsers will be stuck on version 1 for a long time to come.
    3) SDP has become a serialized surface API for object control/properties and the only way to extend this in the future is via SDP extensions; that's a huge part of the issue and objection. That's also probably why so many are focused on extending SDP because they know it doesn't do anything beyond a simple demo at this point and is not ready for prime time deployments and many real-world use cases.
    4) There is very few people saying SDP is "good" or "right". The arguments seem to fall into "we've made that choice", "it's too late", "we'll fix it later", "we must get something out now"
    5) The cost of fixing it now could be much less than everyone working around this later

    That's why I'd like to head up with a proposal with a JS shim for supporting SDP. We can get both worlds and put this debate truly to rest and (hopefully) even bring Microsoft onboard. I've written a media engine/RTC so I've got a good handle on what's involved and I've seen the webrtc C++ engine too. So I've got an idea as to what's going on under the hood and I have real world experience having written a SIP softphone client from scratch. Presently I'm trying to mangle Open Peer to utilize this SDP thing. Keep in mind, even I was okay at first with using SDP thinking I'd just parse/generate it until I thought about all its long term consequences as a surface API and then becomes strongly opposed to using it.

    Making a simple surface API that isn't reliant on SDP and creating a JS SDP shim is entirely possible/feasible and will allow for a flexible future where we don't have tons of competing extensions to SDP with no idea what each browser actually/officially supports.

    -Robin

    20 June, 2013 1:00 PM

    No it is not the only argument it is just stating the fact that we had the debate previously in which the arguments were made and the balance was in favor of SDP. As I said I don't really want to reopen all the old arguments.

    I am saying that people are getting frustrated and considering a change because we are concentrating on extending SDP rather than keeping things simple and focusing on the current deliverables as specified in the charter. If we had not gone this route then I think we would have more success and people would not have become so frustrated.

    Changing fundamental decisions at a late stage is not a major deal and comes with great costs so needs even more justification than the original decision did.

    Andy.
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    20 June, 2013 12:41 PM

    Hi Andrew, please don't take me wrong but:

    So the only arguments pro-SDP are "it was debated many times" (it
    seems it does not matter than many people that agreed then have
    changed their mind after getting experience), "let do something simple
    for now based on SDP, something that allows a simple PSTN call" (so
    SDP will be here forever and any future WebRTC app will have to deal
    with SDP nightmares and will be subject to its O/A model, forever and
    ever).


    --------------030905070107000204090203 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------030905070107000204090203 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxD9py+sZfjkviDxZNpF7b6h4d024uZb2x t7iQ3Ei/NuZkLAnggZwAwwAMVni+ZaU9ztwUafM5VtjEbQ/g0PD3/CSiz8MiBG2hlsrfBf02 iPn6Vwc+I2uel7DCfHbQn/Zrv9HvP2kfDcmk2+k2umTWl2q+TpkFs5kUAABljV1bLAjBByM1 24NzWlR6nnYyEG1KitD6v/4X78Wf+h4vv++Y/wD4mu3lRwninx/8CWFzqnhTxPelfsmuaPb2 cvOGE0UMZBz/ALgH5GuTGxcf3qPUwEoT/dSPKU8P+G1hGgb4vsP25l4cbgNgXP6detec5T+I 9lUaXLynqf7OHgDT7n4knX7IRiw8NKiLk5dppCSuPbCsT9BXZgqbqv2j6Hl46pClenHqrGl/ aC+o/OvSPGND9om/0xvhX4W0t763TXbSW1aOxeQC4ASBo5gU6jDYByBgjHWscY4+z1OnCX9r ofOZvNPWMvJc3PD7jAN2Q3pj0z2ryby5T3/rEeXlsfQv7K/iDw1pOhapZ6nrNjaa3e3xuGtJ 51SUwJGu1gCRkDLZxnFelgZQ9m0meHjU/aXZQ/4RHxx/0Jmvf+C6b/4mujmOM8Y/bJ/5PT+K P/X3a/8AoiKuLEbI6cN8R5mf9RP/ANdK5mdg7wx/yVDwJ/2Nmm/+jkrajuc2K2R+9VdJxn// 2Q== --------------030905070107000204090203-- --------------040304070807000203010300-- From pthatcher@google.com Thu Jun 20 10:32:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3841921F9AD3 for ; Thu, 20 Jun 2013 10:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Raca6M9x08Xg for ; Thu, 20 Jun 2013 10:32:23 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 77F0F21F9EAF for ; Thu, 20 Jun 2013 10:32:16 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb1so6528150pad.9 for ; Thu, 20 Jun 2013 10:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2Iv0UF7U+RPXatAy/Pb0pfNTN1IzX3e9ah2QVkh2UAs=; b=OcNcHdDz1Ui5BWL1SR0u4ZEwRFlCw72+HDedMEN/RNbvWwPhmAmZvfrKSwvU3BAeKr XllwWEUKflFoTAx0d4SHA4VGGfjvZF2j9Oo8LJWUgpcPAbSw7xDalAqlVuZSS4HB3CfJ EY2ATXRQ62v75OSZ+wf8WgfSRJSVJZCAEiSDr+w2qsAfRDFYVmkhqDYM8L+61+4A2HTV RwlQebjDm5cd5KKNFHETP/+FGRCxz3BZrN44qRcOHQnnq1l72MrBc8XfGT7sjT7uVKrv gWPwKa1CA4f66whb4ThBokS52x2+IYJXZHQtshmhcx2rBGxaNj7nm7ShYztQbkk8ULvv UVbA== 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=2Iv0UF7U+RPXatAy/Pb0pfNTN1IzX3e9ah2QVkh2UAs=; b=JmyJL3eMKj/tY+g18bGFS4XLWJgqfiX6k5/TgdP2D8EDsI7WyWM54CfV2SjpsJMqdn fqhwX3aHi9153ig3c/wLgNfEGNmbB4yq6Xnfu2F6NrENVbT1SKOfXt9tV0uYYbCYGYYn btNIATJBlUKVNcro6VWf0HMAsyfDfDBweLdKVVZb0VC8nbUoxIsbRKAy/G40d+oQVV7K gGN5l2pF3lj3fHOsOG9ekkEPN7kwx36/0XMvSS0Yz4Z4J4FVw7rbJ1dvs+5RhlUUlEHd Zlj+UlB3vBiRZtQXkNZC6hAO/njG00OjmvScORfS6WTQPTsGCea0QhCafY9s4E7pblCT JhfQ== X-Received: by 10.68.1.226 with SMTP id 2mr8635607pbp.150.1371749536145; Thu, 20 Jun 2013 10:32:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Thu, 20 Jun 2013 10:31:36 -0700 (PDT) In-Reply-To: <51C339EA.3050103@matthew.at> References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <7594FB04B1934943A5C02806D1A2204B1C3B1680@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3B1A1C@ESESSMB209.ericsson.se> <51C339EA.3050103@matthew.at> From: Peter Thatcher Date: Thu, 20 Jun 2013 10:31:36 -0700 Message-ID: To: Matthew Kaufman Content-Type: multipart/alternative; boundary=bcaec5314817d2c29804df995373 X-Gm-Message-State: ALoCoQlpV8hJWA9ibYFH43t044nzvrDXhOv7tm8BwbKtWVNiSaVS7nVl6jNdQKtMJ/3hpaCMA2EKkktknwjAInwc/DuisC/kkHopxKiHLoTBHQOhfqK66USJryx3x6V39kL34zIdSeSWOyF/wccV/a1CF2St1Cra5Y0M81mUFHCooU3HRdR14xCLND4BjbX7DEjhOCKbB5+l Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:32:24 -0000 --bcaec5314817d2c29804df995373 Content-Type: text/plain; charset=UTF-8 Would you support incremental improvements that remove the offer/answer state machine? If so, I suggest you draft and propose such incremental improvements. I would love to see them. On Thu, Jun 20, 2013 at 10:20 AM, Matthew Kaufman wrote: > On 6/20/2013 10:18 AM, Peter Thatcher wrote: > >> But I don't think CU-RTC is going to work well in the latter, since the >> authors categorically reject incremental improvement. >> >> >> > As long as the incremental improvement removes the offer/answer state > machine, then that statement is false. > > Matthew Kaufman > --bcaec5314817d2c29804df995373 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Would you support incremental improvements that remov= e the offer/answer state machine? =C2=A0If so, I suggest you draft and prop= ose such incremental improvements. =C2=A0I would love to see them.


    On Thu, Jun 20, 2013 at 10:20 AM, Matthe= w Kaufman <matthew@matthew.at> wrote:
    On 6/20/2013 10:18 AM, Peter Thatcher wrote:
    =C2=A0But I don't think CU-RTC is going to work well in the latter, sin= ce the authors categorically reject incremental improvement.



    As long as the incremental improvement removes the offer/answer state machi= ne, then that statement is false.

    Matthew Kaufman

    --bcaec5314817d2c29804df995373-- From matthew@matthew.at Thu Jun 20 10:37:36 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB5321F9D67 for ; Thu, 20 Jun 2013 10:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8qM6MTn8uaG for ; Thu, 20 Jun 2013 10:37:31 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E5B21F9E57 for ; Thu, 20 Jun 2013 10:37:31 -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 418BF250041; Thu, 20 Jun 2013 10:37:31 -0700 (PDT) Message-ID: <51C33DDF.4010104@matthew.at> Date: Thu, 20 Jun 2013 10:37:35 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Thatcher References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <7594FB04B1934943A5C02806D1A2204B1C3B1680@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3B1A1C@ESESSMB209.ericsson.se> <51C339EA.3050103@matthew.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:37:36 -0000 On 6/20/2013 10:31 AM, Peter Thatcher wrote: > Would you support incremental improvements that remove the > offer/answer state machine? If so, I suggest you draft and propose > such incremental improvements. I would love to see them. > When we broke our proposal down into a bunch of different deltas, we got strong feedback at the W3C meeting in Lyon that nobody wanted to touch SDP as the API or Offer/Answer as something that is baked in to the browser. We've done a whole lot of work on our proposal *and* have running code that demonstrates it. We're not going to waste any more time writing additional proposals that will also be rejected by the folks who really love SDP + O/A. If someone else wants to take our work as a reference or starting point, great. If everyone wants to wait until the current API gets to W3C to see what formal objections we file, that's fine too. Matthew Kaufman From pthatcher@google.com Thu Jun 20 10:42:41 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBFF21F9E14 for ; Thu, 20 Jun 2013 10:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-2JPClI+q5H for ; Thu, 20 Jun 2013 10:42:40 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 77FC521F9DFB for ; Thu, 20 Jun 2013 10:42:40 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id tj12so6507571pac.26 for ; Thu, 20 Jun 2013 10:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kc3XbaFiFHrnpa6RjLa7wlidFy7Dz+PTLk8+YBl2ZwY=; b=XDDaRMwBKp4A0iRFlQ9d5vC4P2qsTA6JMw8owgRL4Ea5OXC8ZH+KcmnhLlbX8H5Esf s+9gIyYx71U7N6+v3E0adGsn0bgicMWdQnLcJYNB+g8gWVzSPf7tstLVy+7R+qwN9EdK bX7Vnp3+hQ4VS3urEsqbUhQjrnnFlDXZWs6JBwCf/XqEN68ORw09H/ZOQP2hWzotYh+1 db3WdJS3VdJBPUA5KdazAoA0W7z7P2geBeKPwJ9p5JsNYvqlNq43N8Bb6JNIo9535jpy M1jgpyZG99K1ZjFaIgwOWtaMsEPo+Q3+pMRTERCBXds+y54D7iR78S6MuQvSaECZVw5G m8CQ== 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=kc3XbaFiFHrnpa6RjLa7wlidFy7Dz+PTLk8+YBl2ZwY=; b=LGLRdU4ODZwyZkMUxuU7frm1mefuzJ9XVAYOx4I8ijSA8bh0GAEF+dkjItY2i2mfJE n8CTFH8zAiqP3yc89O48GWgHK5LFMRl0SxWqtZqAGR/S70cuN+pIY2Uu8M9lqBLka+vb eTdwl+4Nf5RNZvF5HsJJp/JiAf+srVzDaMtRtc2jT7ZyvSHTBdlbPtLEXNbNIN/5OJpG C+VLrSYHUAcMzRde0L4LwiTyQQ1OX0+hufhN15AIjq6eVs5jSug0kY0v/MLtuya6jp7h L6BT3jXFIdKz65XocuGPztWtvg+zBwakFWNSpUNujclIZBgpKm5fWl+djD5l6v1rvBk5 C4Uw== X-Received: by 10.66.250.164 with SMTP id zd4mr12568366pac.141.1371750160175; Thu, 20 Jun 2013 10:42:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Thu, 20 Jun 2013 10:41:59 -0700 (PDT) In-Reply-To: <51C33DDF.4010104@matthew.at> References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <7594FB04B1934943A5C02806D1A2204B1C3B1680@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3B1A1C@ESESSMB209.ericsson.se> <51C339EA.3050103@matthew.at> <51C33DDF.4010104@matthew.at> From: Peter Thatcher Date: Thu, 20 Jun 2013 10:41:59 -0700 Message-ID: To: Matthew Kaufman Content-Type: multipart/alternative; boundary=047d7b15fea304ac3404df9979e3 X-Gm-Message-State: ALoCoQlykoBhCyxSwzq4BKfsHzf8jFdD3Qu81FnysRiM+aO9xY0YV8bgsPnl3XalmZ3gP9qBsPM8GFQV+Zpyd88wkgVYvpqMcws1d8r7NHTtQ2/5p4wajZnYsRYQlAVo7ihfMJsBvP+t0Oe8Z3zawSesDi6ttOPXla22tA83lDjVBcHvF2U3kDt1ZQWY9MteDbZ2HGBzVVfz Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:42:41 -0000 --047d7b15fea304ac3404df9979e3 Content-Type: text/plain; charset=UTF-8 OK, in that case, let me rewrite what I wrote earlier: If the WG decided "Let's throw out SDP and O/A in WebRTC 2.0", I'd be happy to help work on a "CU NoPlan" in that context. On the other hand, if the WG said "Let's leave SDP and O/A, but allow JS to bypass it", I'd be happy to work on that as well. But I don't think CU-RTC is going to work well in the latter, since the authors categorically reject any API that contains O/A. Does that accurately reflect the position of the authors of CU-RTCWeb? On Thu, Jun 20, 2013 at 10:37 AM, Matthew Kaufman wrote: > On 6/20/2013 10:31 AM, Peter Thatcher wrote: > >> Would you support incremental improvements that remove the offer/answer >> state machine? If so, I suggest you draft and propose such incremental >> improvements. I would love to see them. >> >> > When we broke our proposal down into a bunch of different deltas, we got > strong feedback at the W3C meeting in Lyon that nobody wanted to touch SDP > as the API or Offer/Answer as something that is baked in to the browser. > > We've done a whole lot of work on our proposal *and* have running code > that demonstrates it. We're not going to waste any more time writing > additional proposals that will also be rejected by the folks who really > love SDP + O/A. > > If someone else wants to take our work as a reference or starting point, > great. If everyone wants to wait until the current API gets to W3C to see > what formal objections we file, that's fine too. > > Matthew Kaufman > --047d7b15fea304ac3404df9979e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    OK, =C2=A0in that case, let me rewrite what I wrote earlie= r:

    If the WG decided "Let's throw out SDP and = O/A in WebRTC 2.0", I'd be happy to help work on a "CU NoPlan= " in that context. =C2=A0On the other hand, if the WG said "Let&#= 39;s leave SDP and O/A, but allow JS to bypass it", I'd be happy t= o work on that as well. =C2=A0But I don't think CU-RTC is going to work= well in the latter, since the authors categorically reject any API that co= ntains O/A.

    Does that accura= tely reflect the position of the authors of CU-RTCWeb?


    On Thu, Jun 20,= 2013 at 10:37 AM, Matthew Kaufman <matthew@matthew.at> wro= te:
    On 6/20/2013 10:31 AM, Pet= er Thatcher wrote:
    Would you support incremental improvements that remove the offer/answer sta= te machine? =C2=A0If so, I suggest you draft and propose such incremental i= mprovements. =C2=A0I would love to see them.


    When we broke our proposal down into a bunch of different deltas, we got st= rong feedback at the W3C meeting in Lyon that nobody wanted to touch SDP as= the API or Offer/Answer as something that is baked in to the browser.

    We've done a whole lot of work on our proposal *and* have running code = that demonstrates it. We're not going to waste any more time writing ad= ditional proposals that will also be rejected by the folks who really love = SDP + O/A.

    If someone else wants to take our work as a reference or starting point, gr= eat. If everyone wants to wait until the current API gets to W3C to see wha= t formal objections we file, that's fine too.

    Matthew Kaufman

    --047d7b15fea304ac3404df9979e3-- From andrew.hutton@siemens-enterprise.com Thu Jun 20 10:43:25 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A072421F9E14 for ; Thu, 20 Jun 2013 10:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryUTcdtTfZTV for ; Thu, 20 Jun 2013 10:43:21 -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 71BEB21F9DFB for ; Thu, 20 Jun 2013 10:43:21 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 60E7D23F0461; Thu, 20 Jun 2013 19:43:20 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Thu, 20 Jun 2013 19:43:20 +0200 From: "Hutton, Andrew" To: "Hutton, Andrew" , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . Thread-Index: AQHObEJByY7ZqkO+CkSPIPqSfmn6rpk+jpkggAASMACAACdKMP//6ASAgAAkEHCAAA534A== Date: Thu, 20 Jun 2013 17:43:19 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115D2692@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF115D2150@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF115D233F@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF115D2432@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115D2432@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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:43:25 -0000 SSBvYnZpb3VzbHkgbWVhbnQgdG8gc2F5ICJpcyBhIG1ham9yIGRlYWwiLg0KDQo+IENoYW5naW5n IGZ1bmRhbWVudGFsIGRlY2lzaW9ucyBhdCBhIGxhdGUgc3RhZ2UgaXMgbm90IGEgbWFqb3IgZGVh bCBhbmQNCj4gY29tZXMgd2l0aCBncmVhdCBjb3N0cyBzbyBuZWVkcyBldmVuIG1vcmUganVzdGlm aWNhdGlvbiB0aGFuIHRoZQ0KPiBvcmlnaW5hbCBkZWNpc2lvbiBkaWQuDQo+IA0KPiBBbmR5Lg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBydGN3 ZWIgbWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K From robin@hookflash.com Thu Jun 20 10:48:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1980621F9EBC for ; Thu, 20 Jun 2013 10:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxtMHKA4SkAo for ; Thu, 20 Jun 2013 10:48:12 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id BA4E721F9EB4 for ; Thu, 20 Jun 2013 10:48:12 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id f4so17389705iea.11 for ; Thu, 20 Jun 2013 10:48: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:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=Ij0zxqifwfOD3M7n2IsH++aMQZ2dBLNbSuAoNAJaMys=; b=knDH5U6nSnaYTISgeNjAmQGOnP9K9rhc1TOjKkJkAA/+9t6lhfx3ktgBkIW6EHGfM0 GlCaWOj621zTGi/i6frB1sV5n7pZRSj+qjtcjs1wLnyYYLYE1rDTOEmOFgwS3xWsytJC kVK6zSfjEgTLcbvKhBGxCVOX0R4baSig8fgBo926gZrNZ5rtN2a3QLKslkWuawCTjfWi 59YFTH3ZifItP5yG8JqhD2NzfJxQM/O59XtvwXzFNSC6Dcq53xMtajdj/AQUHKqlgyTI W0A648/T0DSphHmz449yRWLjz05GOEzYMbAGO3E1F7wI/aJZipQaYBgwmCb3szRT8YBx ORiw== X-Received: by 10.42.190.74 with SMTP id dh10mr3956947icb.35.1371750492280; Thu, 20 Jun 2013 10:48:12 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id nt6sm11889909igb.10.2013.06.20.10.48.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 10:48:11 -0700 (PDT) Message-ID: <51C34058.6070208@hookflash.com> Date: Thu, 20 Jun 2013 13:48:08 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Peter Thatcher References: <51C333E1.1030709@hookflash.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000902090204090209040909" X-Gm-Message-State: ALoCoQmPK8XPuciObJc0BV83ekqVqgQbRI1jcAn6v7An7T64rL/ddl63mmBHnGoePb9abqSNvj1C Cc: "" Subject: Re: [rtcweb] WebRTC JS object API with SDP shim option X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:48:14 -0000 This is a multi-part message in MIME format. --------------000902090204090209040909 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Correct, it is a lot of work. And I am greatly concerned that it will be ignored despite it potentially being the better option. I truly hope that if I do undertake this effort it will be given serious consideration. I really do have the industry's future at heart and even believe the SIP guys would be much better off if they had it as a JavaScript shim instead of backed into the browser binary. I will test in stages. Meaning, that I will provide unit tests with fake media/RTC engines underneath. Once I prove that the wiring works, I'll likely test this by taking our Open Peer client (which already works on webrtc C++ library's source internally) and interfacing to it from JavaScript and controlling it from the shim. With that I'll prove that it works by taking the SDP and connecting with real SIP networks and establishing calls. That will prove that we can do this entirely from JavaScript and interface between two independent signaling engines and connect to existing SIP networks at the same time. It's not the browser, but it's the same engine. Despite this, I fear that this work will be ignored no matter what I go through to prove it works better for everyone, and I don't want to go with learning the entire Chrome or Firefox source code and forking it only to be told no even if I make it work. That's why I'm going to do it in stages. -Robin > Peter Thatcher > 20 June, 2013 1:23 PM > > > > On Thu, Jun 20, 2013 at 9:54 AM, Robin Raymond > wrote: > > > You are right. It's time for those of us who are begging for an > alternative to SDP to come up with an alternative. > > I'm willing to lead such an effort. I just ask others to please > have an open mind. I absolutely do understand the need for the SIP > world to have an easy API they can use for SDP. But I also know > SDP as an primary surface API is making anything beyond a basic > calling a requirement to mangle SDP as a mechanism to control and > obtain properties from an underlying media/RTC engine. > > I think there is a really good compromise. That is to provide an > API that will adhere to the security policies needed (e.g. > respects the need to require ICE establishment), but provides a > simple shim API similar to what people already have with SDP but > not be required to use for those who want to a more direct approach. > > There's no need to "burn" the entire thing to the ground and start > over and that is _not_ my desire. > > This WebRTC thing must succeed but I can't imagine the W3C > accepting our proposal for mangling SDP as a primary surface API > to do common edge case scenarios. WIth an alternative proposal > that satisfies both camps, I believe they could accept and we can > stop the anit-SDP crowd grumblings once and for all. > > To that end I'm going to write two drafts: > draft-raymond-webrtc-js-object-api-rationale-00 (to explain > requirements, philosophy, methodology, benefits/pitfalls, use > cases that are difficult/impossible with SDP+O/A) > draft-raymond-webrtc-js-object-api-00 (to outline the actual API) > > Plus, I'll produce a shim on top of whatever API that will allow > the SDP folks to have a simple SDP based API similar to what > exists now but is entirely written in JavaScript to prove that > this can be done. > > > How are you going to test that shim without a working implementation > of the clean API? > > One thing you could do is build a shim of clean API -> SDP. Then, > you'd have two shims which would make a fun combination (SDP -> clean > API -> SDP) and you're prove that SDP munging and the clean API are > equivalent in power. > > Or you could fork Chrome or Firefox. > > Either way, you have a lot of work ahead of you. Best of luck. > > I really want a viable solutions for all interested in having a > really good proposal API to ultimately become accepted by the W3C. > > If anyone has anything I should add to either of these drafts or > wants to be involved, please contact me. > > -Robin > > > Christer Holmberg > 20 June, 2013 12:55 AM > Hi, > > > At the virtual interim, the Plan A and Plan B folks were asked to > sit down and try to come up with a compromise "Plan AB" solution. > > I guess it would be good if people that don't want SDP could try > to come up with a compromise "CU No Plan" solution :) > > Regards, > > Christer > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --------------000902090204090209040909 Content-Type: multipart/related; boundary="------------010807030903030701010101" --------------010807030903030701010101 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
    Correct, it is a lot of work. And I am greatly concerned that it will be ignored despite it potentially being the better option. I truly hope that if I do undertake this effort it will be given serious consideration. I really do have the industry's future at heart and even believe the SIP guys would be much better off if they had it as a JavaScript shim instead of backed into the browser binary.

    I will test in stages. Meaning, that I will provide unit tests with fake media/RTC engines underneath. Once I prove that the wiring works, I'll likely test this by taking our Open Peer client (which already works on webrtc C++ library's source internally) and interfacing to it from JavaScript and controlling it from the shim. With that I'll prove that it works by taking the SDP and connecting with real SIP networks and establishing calls. That will prove that we can do this entirely from JavaScript and interface between two independent signaling engines and connect to existing SIP networks at the same time. It's not the browser, but it's the same engine.

    Despite this, I fear that this work will be ignored no matter what I go through to prove it works better for everyone, and I don't want to go with learning the entire Chrome or Firefox source code and forking it only to be told no even if I make it work. That's why I'm going to do it in stages.

    -Robin


    20 June, 2013 1:23 PM



    On Thu, Jun 20, 2013 at 9:54 AM, Robin Raymond <robin@hookflash.com> wrote:

    You are right. It's time for those of us who are begging for an alternative to SDP to come up with an alternative.

    I'm willing to lead such an effort. I just ask others to please have an open mind. I absolutely do understand the need for the SIP world to have an easy API they can use for SDP. But I also know SDP as an primary surface API is making anything beyond a basic calling a requirement to mangle SDP as a mechanism to control and obtain properties from an underlying media/RTC engine.

    I think there is a really good compromise. That is to provide an API that will adhere to the security policies needed (e.g. respects the need to require ICE establishment), but provides a simple shim API similar to what people already have with SDP but not be required to use for those who want to a more direct approach.

    There's no need to "burn" the entire thing to the ground and start over and that is _not_ my desire.

    This WebRTC thing must succeed but I can't imagine the W3C accepting our proposal for mangling SDP as a primary surface API to do common edge case scenarios. WIth an alternative proposal that satisfies both camps, I believe they could accept and we can stop the anit-SDP crowd grumblings once and for all.

    To that end I'm going to write two drafts:
    draft-raymond-webrtc-js-object-api-rationale-00 (to explain requirements, philosophy, methodology, benefits/pitfalls, use cases that are difficult/impossible with SDP+O/A)
    draft-raymond-webrtc-js-object-api-00 (to outline the actual API)

    Plus, I'll produce a shim on top of whatever API that will allow the SDP folks to have a simple SDP based API similar to what exists now but is entirely written in JavaScript to prove that this can be done.


    How are you going to test that shim without a working implementation of the clean API?  

    One thing you could do is build a shim of clean API -> SDP.  Then, you'd have two shims which would make a fun combination (SDP -> clean API -> SDP) and you're prove that SDP munging and the clean API are equivalent in power.

    Or you could fork Chrome or Firefox.  

    Either way, you have a lot of work ahead of you.  Best of luck.

     
    I really want a viable solutions for all interested in having a really good proposal API to ultimately become accepted by the W3C.

    If anyone has anything I should add to either of these drafts or wants to be involved, please contact me.

    -Robin


    20 June, 2013 12:55 AM
    Hi,


    At the virtual interim, the Plan A and Plan B folks were asked to sit down and try to come up with a compromise "Plan AB" solution.

    I guess it would be good if people that don't want SDP could try to come up with a compromise "CU No Plan" solution :)

    Regards,

    Christer


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


    --------------010807030903030701010101 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------010807030903030701010101 Content-Type: image/jpeg; name="image.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="image.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9LNP0/T7jT7S4uNPtJpZbeKSSSSBHZ2KA kkkZJzVWIMqXVdDjuWjXw7ZPEjbTIII8nHUgbf61XKLmNyDTdFm8t00uxKSYIYWyDg9wcVLR R5v/AMJBrn/QWuv+/ppiPR9I/wCQRYf9esP/AKAKQHGzwSQXEluQWdHKDH8Rzx+dWSdzYwm2 t7eBiCYkRCfoAKllI8hoA7j+35oNPtLOyVQ0VtEryMM4OwZAH+NNITZluzyu0kjFndixbuSa Yja03xHcpMkN+VkR2C+ZgKVycc9sflSaHc4TyZv+eT/98mkM5n4gf8jrrH/Xx/7KtNbCe5z9 MRb0j/kLWH/X1D/6GKHsB9QVkan/2Q== --------------010807030903030701010101-- --------------000902090204090209040909-- From bernard_aboba@hotmail.com Thu Jun 20 10:49:03 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F7321F9F77 for ; Thu, 20 Jun 2013 10:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC-6HOH7GYsh for ; Thu, 20 Jun 2013 10:48:57 -0700 (PDT) Received: from blu0-omc3-s23.blu0.hotmail.com (blu0-omc3-s23.blu0.hotmail.com [65.55.116.98]) by ietfa.amsl.com (Postfix) with ESMTP id 208ED21F9F28 for ; Thu, 20 Jun 2013 10:48:57 -0700 (PDT) Received: from BLU169-W37 ([65.55.116.72]) by blu0-omc3-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jun 2013 10:48:56 -0700 X-TMN: [B9XZ7Mxbc87+su7f/AYgi7/Nr9/ZrtRz] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_fad9ecc3-b449-4696-bfdf-833ebdf94abf_" From: Bernard Aboba To: Peter Thatcher , Robin Raymond Date: Thu, 20 Jun 2013 10:48:55 -0700 Importance: Normal In-Reply-To: References: <51C333E1.1030709@hookflash.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2013 17:48:56.0219 (UTC) FILETIME=[6F8FDEB0:01CE6DDE] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC JS object API with SDP shim option X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:49:03 -0000 --_fad9ecc3-b449-4696-bfdf-833ebdf94abf_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Peter Thatcher said:=20 "How are you going to test that shim without a working implementation of th= e clean API? One thing you could do is build a shim of clean API -> SDP. Then=2C you'd = have two shims which would make a fun combination (SDP -> clean API -> SDP)= and you're prove that SDP munging and the clean API are equivalent in powe= r. Or you could fork Chrome or Firefox.=20 Either way=2C you have a lot of work ahead of you. Best of luck." [BA] Getting a working implementation of a clean API is not the biggest iss= ue. The biggest issue is how to determine whether a shim is "successful" o= r not. At this point=2C the reality is that the implementation code (inc= luding undocumented behavior) represents the WebRTC 1.0 specification=2C ra= ther than the documents produced by W3C and IETF. This makes the bar (eith= er "backward compatibility" or "equivalent in power") difficult to define= =2C let alone satisfy. =20 = --_fad9ecc3-b449-4696-bfdf-833ebdf94abf_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Peter Thatcher said: = =3B

    "How are you going to test that shim without a= working implementation of the clean API?

    One thin= g you could do is build a shim of clean API ->=3B SDP.  =3BThen=2C yo= u'd have two shims which would make a fun combination (SDP ->=3B clean AP= I ->=3B SDP) and you're prove that SDP munging and the clean API are equi= valent in power.

    Or you could fork Chrome or Firef= ox. =3B

    Either way=2C you have a lot of work ahead of you.  =3BBest of= luck."

    [BA] Getting a working implementation of a clean API is not the big= gest issue.  =3BThe biggest issue is how to determine whether a shim is= "successful" or not.  =3B =3BA= t this point=2C the reality is that the  =3Bimplementation code (includ= ing undocumented behavior) represents the WebRTC 1.0 specification=2C rathe= r than the documents produced by W3C and IETF.  =3BThis makes the bar (= either "backward compatibility" or "equivalent in power") =3Bdifficult to define=2C let alone satisfy. =  =3B


    <= /div>
    = --_fad9ecc3-b449-4696-bfdf-833ebdf94abf_-- From robin@hookflash.com Thu Jun 20 10:52:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D8921F9E4E for ; Thu, 20 Jun 2013 10:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6P3Dnm0ujU1 for ; Thu, 20 Jun 2013 10:52:42 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 93F8A21F9AE6 for ; Thu, 20 Jun 2013 10:52:42 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id a13so16415549iee.6 for ; Thu, 20 Jun 2013 10:52:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=Lkc0Du4rur3WbBuDo2JJYiqvuZ6RGVbySWUDZOddw/o=; b=CH5JzE8rS38M8N8l+3WtHEiaFUFvqYrODhry7Zow1MxMD353isNlQ2GY90ljhtu7iq i0JDsy8U1VEq31BwHFRWUvNobVyVxUKfZfqKiYBCqSo3coZwAmTd07BNPu3fp81CAY6T yXTuqpGIGQ9FuePDNNNajpF6Nr8zob55yw8SFJQlOYhTqNcByxHH593Twq5Iw5tLWDc7 wcHsWkNJFZlvwJveqODboB2/DQoOxq3aWC48uOP6OD3i2a0oCvds/fa1+8j14soq9ZhB VekJUDHMCde2aCJn2Ac48rBXqczaUtxWFwggSWW1YdEDbJQuRsruV/FGl8ISCj0iaYQG /wtA== X-Received: by 10.43.77.137 with SMTP id zi9mr484980icb.106.1371750761986; Thu, 20 Jun 2013 10:52:41 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id nm17sm11933425igb.5.2013.06.20.10.52.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 10:52:41 -0700 (PDT) Message-ID: <51C34166.2080901@hookflash.com> Date: Thu, 20 Jun 2013 13:52:38 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Bernard Aboba References: <51C333E1.1030709@hookflash.com>, In-Reply-To: Content-Type: multipart/alternative; boundary="------------030404060608060009090709" X-Gm-Message-State: ALoCoQnncxHVB6ADQ2LY6790NcoUvugybQSXlSuFgTv35Z+GV9PlwTxPBru699QXvigqHMIeWobl Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC JS object API with SDP shim option X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:52:44 -0000 This is a multi-part message in MIME format. --------------030404060608060009090709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Would someone produce unit tests against the produced SDP and offered SDP that is the "defined webrtc spec" so the bar could be set? Hitting a moving target will be challenging. Seems to me a lot of what is SDP is not extremely well defined at this point so the only thing I can do is produce "good" SDP since the exact definition of what is webRTC SDP seems a bit lacking. -Robin > Bernard Aboba > 20 June, 2013 1:48 PM > Peter Thatcher said: > > "How are you going to test that shim without a working implementation > of the clean API? > > One thing you could do is build a shim of clean API -> SDP. Then, > you'd have two shims which would make a fun combination (SDP -> clean > API -> SDP) and you're prove that SDP munging and the clean API are > equivalent in power. > > Or you could fork Chrome or Firefox. > > Either way, you have a lot of work ahead of you. Best of luck." > > [BA] Getting a working implementation of a clean API is not the > biggest issue. The biggest issue is how to determine whether a shim > is "successful" or not. At this point, the reality is that the > implementation code (including undocumented behavior) represents the > WebRTC 1.0 specification, rather than the documents produced by W3C > and IETF. This makes the bar (either "backward compatibility" or > "equivalent in power") difficult to define, let alone satisfy. > > --------------030404060608060009090709 Content-Type: multipart/related; boundary="------------060805040303060508040203" --------------060805040303060508040203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    Would someone produce unit tests against the produced SDP and offered SDP that is the "defined webrtc spec" so the bar could be set? Hitting a moving target will be challenging. Seems to me a lot of what is SDP is not extremely well defined at this point so the only thing I can do is produce "good" SDP since the exact definition of what is webRTC SDP seems a bit lacking.

    -Robin


    20 June, 2013 1:48 PM
    Peter Thatcher said: 

    "How are you going to test that shim without a working implementation of the clean API?

    One thing you could do is build a shim of clean API -> SDP.  Then, you'd have two shims which would make a fun combination (SDP -> clean API -> SDP) and you're prove that SDP munging and the clean API are equivalent in power.

    Or you could fork Chrome or Firefox. 

    Either way, you have a lot of work ahead of you.  Best of luck."

    [BA] Getting a working implementation of a clean API is not the biggest issue.  The biggest issue is how to determine whether a shim is "successful" or not.   At this point, the reality is that the  implementation code (including undocumented behavior) represents the WebRTC 1.0 specification, rather than the documents produced by W3C and IETF.  This makes the bar (either "backward compatibility" or "equivalent in power") difficult to define, let alone satisfy.  


    --------------060805040303060508040203 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------060805040303060508040203-- --------------030404060608060009090709-- From pthatcher@google.com Thu Jun 20 10:56:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EE321F99C9 for ; Thu, 20 Jun 2013 10:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDon3SYZDFjU for ; Thu, 20 Jun 2013 10:56:03 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B8FE921F9CBD for ; Thu, 20 Jun 2013 10:56:00 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa11so6550895pad.33 for ; Thu, 20 Jun 2013 10:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gLNmYtEJx68jl7IMLdZbPpZzUi9ZHIAqbWvCEZaHepk=; b=BUg3/1dMQoHufEJYzfrS4StqRsZKkyax3XuSVIr9rkIfmf8UoTTPsvU3EHd63hMhS/ goixG8mMM/TeaVQBUCRkeAP5ZIaaz3fMF5409F6RcGqyA3ZPEQbnfW9YjES3ozhirROo EJZInnAAiinGE9jlTXYdptQ/LS6Kzrecg3PaAOr81gXK1dbiWZo3Jlpy3R5IH7KJWtV6 /8TA+8HX3MpcFLSxfv/yxy78fcR/DX4bczPjRCSmUVdBnbiFZhdV03x9OvQ/YI4xQMdd 4MSuQLeaXKMZq36v+KAAPc8Nvbxt4jDFQn5oMTbM0wYCSdbnSZgxlHuTuk4qIa3SjqWj QX0w== 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=gLNmYtEJx68jl7IMLdZbPpZzUi9ZHIAqbWvCEZaHepk=; b=VSuFhZB7E5auQQKKSHaQP9Ou6EByIJe10xODjdf1kBVRJM9SRjcLp9tFh/EK2se0pQ 4T5wPmz34gFnrBuh3+aqHkskltrJl7ehT4dcrqW+hZH5bmecsmAnAg5YBoJ2LBFHCtNX C2qVBV5p+GhrZfq/w+92unofBgxVWTcpoTiLpzh2tCKipLLyyoLXL1gVJvmfSCOnknJW u5g3lEOuWp4058AvlABBEWnOY7nfpD2A9fsbONxBvmx5P29lDC9j9/XIqDers7G2kWvh 8McTi1knP0R7urzQoQaNTxisgTvdZdKDlB83z7iICl/jQt2ZexHtu0cQUGwCZmv97H2H KkMQ== X-Received: by 10.68.1.226 with SMTP id 2mr8724060pbp.150.1371750960337; Thu, 20 Jun 2013 10:56:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Thu, 20 Jun 2013 10:55:20 -0700 (PDT) In-Reply-To: References: <51C333E1.1030709@hookflash.com> From: Peter Thatcher Date: Thu, 20 Jun 2013 10:55:20 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=bcaec5314817b62ad804df99a838 X-Gm-Message-State: ALoCoQmObQQbEutCw4R/NeupMo+u3IXORQLbAVnl+zbuj+Xy/drLMGrQEdAGkeL2vQGpUm7/dtHyO22jDSw7ooSodKze5hGS0LJFffTFRZ8QcxNlWuXjm0j0vxg67Pfw8KhXYebkftbOjdLv93AE5MSHfH1AhuZBi2lW8meLVsz68c/y9ZAzFYxox9K9cXB6jWjyZfNpCHsS Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC JS object API with SDP shim option X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:56:04 -0000 --bcaec5314817b62ad804df99a838 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 20, 2013 at 10:48 AM, Bernard Aboba wrote: > Peter Thatcher said: > > "How are you going to test that shim without a working implementation of > the clean API? > > One thing you could do is build a shim of clean API -> SDP. Then, you'd > have two shims which would make a fun combination (SDP -> clean API -> SDP) > and you're prove that SDP munging and the clean API are equivalent in power. > > Or you could fork Chrome or Firefox. > > Either way, you have a lot of work ahead of you. Best of luck." > > [BA] Getting a working implementation of a clean API is not the biggest > issue. > If implementing the clean API in browser is the small issue, then poor Robin has a massive challenge ahead. > The biggest issue is how to determine whether a shim is "successful" or > not. At this point, the reality is that the implementation code > (including undocumented behavior) represents the WebRTC 1.0 specification, > rather than the documents produced by W3C and IETF. This makes the bar > (either "backward compatibility" or "equivalent in power") difficult to > define, let alone satisfy. > > > --bcaec5314817b62ad804df99a838 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Thu, Jun 20, 2013 at 10:48 AM, Bernard Aboba &= lt;bernard_a= boba@hotmail.com> wrote:
    Pet= er Thatcher said:=C2=A0

    "How are you going to= test that shim without a working implementation of the clean API?

    One thing you could do is build a shim of clean API -> SDP. = =C2=A0Then, you'd have two shims which would make a fun combination (SD= P -> clean API -> SDP) and you're prove that SDP munging and the = clean API are equivalent in power.

    Or you could fork Chrome or Firefox.=C2=A0

    Either way, you have a lot of = work ahead of you. =C2=A0Best of luck."

    [BA] Getting a working implementation of a clean = API is not the biggest issue. =C2=A0

    If implementing the clean API in browser is t= he small issue, then poor Robin has a massive challenge ahead.

    =C2=A0
    The biggest issue is how to deter= mine whether a shim is "successful" or not. =C2=A0=C2=A0At this point, the reality is that the =C2=A0implemen= tation code (including undocumented behavior) represents the WebRTC 1.0 spe= cification, rather than the documents produced by W3C and IETF. =C2=A0This = makes the bar (either "backward compatibility" or "equivalen= t in power")=C2=A0difficult to d= efine, let alone satisfy. =C2=A0



    --bcaec5314817b62ad804df99a838-- From bernard_aboba@hotmail.com Thu Jun 20 11:02:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D0921F9FF5 for ; Thu, 20 Jun 2013 11:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzxwCF2GLoWC for ; Thu, 20 Jun 2013 11:02:04 -0700 (PDT) Received: from blu0-omc2-s21.blu0.hotmail.com (blu0-omc2-s21.blu0.hotmail.com [65.55.111.96]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8BB21F9FE1 for ; Thu, 20 Jun 2013 11:02:00 -0700 (PDT) Received: from BLU169-W87 ([65.55.111.73]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jun 2013 11:02:00 -0700 X-TMN: [Hf+ZhDkC39nvTcYt1sL2Q6F06c9N0kPr] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_849cbe1a-8152-4245-bfb1-d70d3516ee38_" From: Bernard Aboba To: Robin Raymond Date: Thu, 20 Jun 2013 11:01:59 -0700 Importance: Normal In-Reply-To: <51C34166.2080901@hookflash.com> References: <51C333E1.1030709@hookflash.com>, , <51C34166.2080901@hookflash.com> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2013 18:02:00.0393 (UTC) FILETIME=[42F75390:01CE6DE0] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC JS object API with SDP shim option X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 18:02:10 -0000 --_849cbe1a-8152-4245-bfb1-d70d3516ee38_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Robin said:=20 =0A= =0A= "Would someone produce unit tests against the produced SDP and offered =0A= SDP that is the "defined webrtc spec" so the bar could be set?" [BA] If there actually was a "defined webrtc spec" that covered the SDP blo= b in detail=2C that would be possible. But at the moment=2C that doesn't = exist (and seems unlikely to be produced). =20 Robin also said:=20 "Hitting a=0A= moving target will be challenging. Seems to me a lot of what is SDP is =0A= not extremely well defined at this point so the only thing I can do is =0A= produce "good" SDP since the exact definition of what is webRTC SDP =0A= seems a bit lacking." [BA] I would suggest that the SDP subset relating to Audio probably can be = well defined enough to produce unit tests. Given the state of the "Plan A"= vs. "Plan B" debate=2C and the other video-related uncertainties=2C trying= to develop test cases for video would probably be a fool's errand.=20 =0A= = --_849cbe1a-8152-4245-bfb1-d70d3516ee38_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Robin said: =3B
    =0A= =0A=
    "Would someone produce unit tests against the produced SDP and offered = =0A= SDP that is the "defined webrtc spec" so the bar could be set?"
    <= br>
    [BA] If there actually was a "defined webrtc spec" that cover= ed the SDP blob in detail=2C that would be possible.  =3B But at the mo= ment=2C that doesn't exist (and seems unlikely to be produced).  =3B

    Robin also said: =3B

    "Hitting a=0A= moving target will be challenging. Seems to me a lot of what is SDP is =0A= not extremely well defined at this point so the only thing I can do is =0A= produce "good" SDP since the exact definition of what is webRTC SDP =0A= seems a bit lacking."
    =
    [BA] I would sugg= est that the SDP subset relating to Audio probably can be well defined enou= gh to produce unit tests.  =3BGiven the state of the "Plan A" vs. "Plan= B" debate=2C and the other video-related uncertainties=2C trying to develo= p test cases for video would probably be a fool's errand. =3B

    =0A=
    = --_849cbe1a-8152-4245-bfb1-d70d3516ee38_-- From partha@parthasarathi.co.in Thu Jun 20 11:05:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133E421F9E0D for ; Thu, 20 Jun 2013 11:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0F49Cs4I06xL for ; Thu, 20 Jun 2013 11:05:24 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.238]) by ietfa.amsl.com (Postfix) with ESMTP id 42FC821F9FFF for ; Thu, 20 Jun 2013 11:05:19 -0700 (PDT) Received: from userPC (unknown [122.179.30.185]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 1A94E638E0B; Thu, 20 Jun 2013 18:05:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1371751518; bh=UF3XRO77cFXMG8m+9uFTBbYfhpMc8Sxq6JPmhk1f834=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Y4QOTtrXHvT34P5SwQGA/rmayzXCq5COUCybFKS0d+VWHMGoG8r8JyLtKriq7r6gb w3HdmwyWAmx94wTiN8IwoEIc+tEp/e1Z+ykHA/8fVbx3NXjZhBTRnQyLgCq0axmhXm IZykGwyj6XQXevdnWN7kglPMx7Y9EL7pzCBNZPkA= From: "Parthasarathi R" To: "'Hutton, Andrew'" , References: <9F33F40F6F2CD847824537F3C4E37DDF115D2150@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115D2150@MCHP04MSX.global-ad.net> Date: Thu, 20 Jun 2013 23:35:08 +0530 Message-ID: <00b401ce6de0$b6638380$232a8a80$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHObEJByY7ZqkO+CkSPIPqSfmn6rpk+jpkggABE8GA= Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0202.51C3445E.00CB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 18:05:29 -0000 Hi Andy, Your proposed approach looks reasonable way to move forward. In case SDP improvements like multiplexing, bundling is taken the = priority for WebRTC 1.0 which results in discussing whether offer/answer = is required or not for those enhancements, then it will lead to discuss = whether SDP is required or not as well.=20 Thanks Partha > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Thursday, June 20, 2013 8:56 PM > To: rtcweb@ietf.org > Subject: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate > to be re-opened . >=20 >=20 > IMHO the re-opening of the debate on "SDP or not SDP" is not the right > approach to making progress at this moment in time as it would only > serve to slow the process even further and reopen all the old > arguments. >=20 > The agreement albeit a W3C agreement was to assess the requirements = for > a lower level API (Without SDP) once a first release of WebRTC is > achieved and I think we should not reverse that agreement there was > strong consensus on that at the time. >=20 > However I think we should have a close look at our priorities and what > we really need to get to what would effectively be WebRTC 1.0. My > feeling is that we are trying to do too much. >=20 > Let's take a short pause for breath and think about what we really = need > for a successful WebRTC 1.0 as I think we are maybe focused on the > wrong issues and we seem to have got diverted from the priorities set > in the charter (http://datatracker.ietf.org/wg/rtcweb/charter/). >=20 > For example to make even basic WebRTC applications easily deployable = we > need to resolve the firewall issues as stated in the charter (bullet > 3). We don't even have an adopted draft for that yet but I hope that > can be changed very soon. If WebRTC apps work from my home but not > when I check in to a hotel or go to my office then we really have a > problem even with the most basic audio only apps. >=20 > In conclusion, let's focus on the requirements specified in the > charter, concentrate on more basic issues relating to security and > deployment that really need to be solved now. Some of the more > sophisticated features such as SSRC signaling and bundling could = become > part of WebRTC 2.0. >=20 > Let's make WebRTC 1.0 successful as soon as possible. >=20 > Regards > Andy >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of I=C3=B1aki Baz Castillo > > Sent: 18 June 2013 17:36 > > To: rtcweb@ietf.org > > Subject: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened > > > > Hi all, I re-send this mail in a new thread. > > > > > > Dear WG Chairs, > > > > With all due respect, IMHO there is too much controversy about SDP > > usage in WebRTC so I would like to request the WG to reopen the "SDP > > or not SDP" debate. > > > > I would also appreciate that those in favour of mandating SDP as the > > core communication for WebRTC explain their rationale again (given > the > > number of arguments against SDP and the frustration SDP is causing), > > and also that they give arguments and responses to all the SDP > related > > issues nicely summarized in this mail: > > > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html > > > > > > Thanks a lot. > > > > > > -- > > I=C3=B1aki Baz Castillo > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From andrew.hutton@siemens-enterprise.com Thu Jun 20 12:38:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD6521E808A for ; Thu, 20 Jun 2013 12:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agdPsNtDM1BW for ; Thu, 20 Jun 2013 12:38:45 -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 1819211E80FB for ; Thu, 20 Jun 2013 12:38:45 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 28A981EB8446; Thu, 20 Jun 2013 21:38:44 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Thu, 20 Jun 2013 21:38:43 +0200 From: "Hutton, Andrew" To: Bernard Aboba , Peter Thatcher Thread-Topic: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . Thread-Index: AQHObEJByY7ZqkO+CkSPIPqSfmn6rpk+jpkggAAmEgCAAAUrAIAARf8g Date: Thu, 20 Jun 2013 19:38:43 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115D2B4D@MCHP04MSX.global-ad.net> References: , <9F33F40F6F2CD847824537F3C4E37DDF115D2150@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened . X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 19:38:50 -0000 What I am saying is that if we need a plan then no plan looks like the best= option for WebRTC 1.0 and that we need to stop trying to boil the ocean an= d concentrate on what is needed to achieve the goals set out in the charter= . It seems to me that we have got diverted from the original goals. I don't believe this means that video is not adequately covered although it= might mean a bit more implementation effort for those that want to get ahe= ad of the game and build more complex applications but that is fair. What is not fair is to reverse previous decisions because we are struggling= to achieve things which are not even covered by the charter. Regards Andy > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: 20 June 2013 18:17 > To: Peter Thatcher; Hutton, Andrew > Cc: rtcweb@ietf.org > Subject: RE: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" > debate to be re-opened . >=20 > Peter Thatcher said: >=20 > "Some of the more sophisticated features such as SSRC signaling and > bundling could become part of WebRTC 2.0" >=20 > That's tantamount to saying Plan A vs. Plan B vs. NoPlan is part of > WebRTC 2.0. =A0Is that what you're suggesting? >=20 > [BA] If the "Plan A" vs. "Plan B" issue is not resolved, then WebRTC > v1.0 would really only cover audio scenarios adequately. =A0 That might > make sense if we believed that WebRTC API 2.0 would go in a different > direction and be concluded quickly. However, I'd observe that just > because something isn't specified in a standard doesn't mean it won't > be widely implemented. =A0 And once you have functionality widely > implemented, you typically have to deal with backward compatibility - > and when the thing to be backward compatible with isn't specified, then > it's a bit of a headache. From andrew.hutton@siemens-enterprise.com Thu Jun 20 13:52:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDE321F9F49 for ; Thu, 20 Jun 2013 13:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjfrXM557Qcf for ; Thu, 20 Jun 2013 13:52:50 -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 872F511E80D3 for ; Thu, 20 Jun 2013 13:52:49 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 999E723F0469; Thu, 20 Jun 2013 22:52:48 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Thu, 20 Jun 2013 22:52:48 +0200 From: "Hutton, Andrew" To: Hadriel Kaplan , Richard Barnes Thread-Topic: [rtcweb] No Interim on SDES at this juncture Thread-Index: AQHObVFVBYzpHvj1BUGlhj09l8oaqpk+DoOAgAEDiyA= Date: Thu, 20 Jun 2013 20:52:47 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115D2D76@MCHP04MSX.global-ad.net> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> In-Reply-To: <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 20:52:55 -0000 Agree with Hadriel here I so no additional security benefit for EKT given t= hat any media gateway is going to be in cahoots with the webserver and has = access to the key. So all we are left with is the performance benefit of using SDES support in= the browser which is significant and reduces the barrier to deploying WebR= TC so let's go for the option that is easy to specify, easy to deploy, chea= p to implement (already exists in Chrome), and we are all familiar with. SDES support looks like the obvious choice. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: 20 June 2013 08:11 > To: Richard Barnes > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] No Interim on SDES at this juncture >=20 >=20 > On Jun 19, 2013, at 8:58 PM, Richard Barnes wrote: >=20 > > I think we still disagree on the scenario. I've tried to sketch out > the full sequence of operations to be clear. (WebSequenceDiagrams > source below.) > > > > > > ISTM that there are two major differences: > > -- In the SDES case, the JS and the Web Server both have access to > the media keys. In the EKT case, the browser handles the keying update > directly. > > -- In the EKT case, the PBX/gateway has to be in the media path to do > EKT. After EKT, it just switches packets (it's basically a TURN > server). > > > > So it seems like a security benefit for EKT and a performance benefit > for SDES. Your quantitative valuation of these benefits / costs may > vary. >=20 > I'm confused. EKT has "a security benefit" for whom, exactly? > It's not more secure for the browser user, since a malicious web server > can simply *be* the PBX, terminate DTLS-EKT and get the key and the > browser user would never know it. > It's not more secure for the SIP user, since the SIP user is only doing > SDES and has no idea what's happening on the far-end. >=20 > Who are you saying is being better protected from what? >=20 > I suppose we could claim the owner of the PBX feels more secure, if > they're not the same as the owner of the web-server and don't trust the > web-server. But again, if the web-server owner is malicious it will > just terminate the media pretending to be the PBX on one side, and > pretending to be the browser to the real PBX on the other side. And > why would a PBX owner accept calls from a web-server it doesn't trust > to begin with? >=20 > Afaict, the main security benefit of DTLS-EKT is the same as that of > DTLS-SRTP: the keys aren't sent in the JSON/SDP/whatever, so they can't > be sniffed even if cleartext HTTP is used. So in a weird way, the > security benefit of it is it let's us use an insecure HTTP transport > for the JSON/SDP/HTML/whatever. Luckily the ability to see and modify > what goes on there is no big deal... like for example be able to insert > a malicious DTLS-SRTP B2BUA that records everything. Oh, wait... >=20 > -hadriel >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From roman@telurix.com Thu Jun 20 13:58:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B70C21F9E36 for ; Thu, 20 Jun 2013 13:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFUciuJ1+9qE for ; Thu, 20 Jun 2013 13:58:08 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5F67121F9E1F for ; Thu, 20 Jun 2013 13:58:08 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so30851wgg.2 for ; Thu, 20 Jun 2013 13:58:07 -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=QLhsfYVD+MpRJRX+cUBXEycGxkcqE2MWHDISwMYtBqY=; b=auEDmNg0BlxQUTIjVFsUAGxTZxWOVTnKoSvfd+BiALBtUsO8Q693AVeLhPO7HlSQdN nfIC/q/ye9ktGwOhlIh2JwoH7sjnrC7OqxX7RhVy+v6togXa9OCK5Uv/KrR240rANmVv nVRCjB+zhKqni8SqenNKBlTxR5C58cF9R0oDN2X71W8e3j+Ks1TUjJlTIjoatA0nqJuS VxRYm6uyI0xBT32TQD/qVAgwbri6bYMwQPyKpIJeWP8YsSnAkhcel6OgCUOl013C+Fl7 HqpNr/M5cH/IWgjbCqQre8uOzEk7BP+2BhFHbVJspFf5Fom4yEcdARFBYgb2YX3Ihd/3 5ToA== X-Received: by 10.180.106.163 with SMTP id gv3mr696445wib.53.1371761887282; Thu, 20 Jun 2013 13:58:07 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [2a00:1450:400c:c05::231]) by mx.google.com with ESMTPSA id m3sm18726908wij.5.2013.06.20.13.58.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 13:58:06 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so2111514wid.4 for ; Thu, 20 Jun 2013 13:58:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.195.12.133 with SMTP id eq5mr6994183wjd.27.1371761885422; Thu, 20 Jun 2013 13:58:05 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Thu, 20 Jun 2013 13:58:05 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115D2D76@MCHP04MSX.global-ad.net> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115D2D76@MCHP04MSX.global-ad.net> Date: Thu, 20 Jun 2013 16:58:05 -0400 Message-ID: From: Roman Shpount To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=047d7bb04c90e5ff5e04df9c33af X-Gm-Message-State: ALoCoQmyuA0+WdCs4MokwmTDz5Bw2ZX1zsr9rcQG3N2GMqBkzmyuVsCsLT++AF5Zby3h5WyCVV10 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 20:58:09 -0000 --047d7bb04c90e5ff5e04df9c33af Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 20, 2013 at 4:52 PM, Hutton, Andrew < andrew.hutton@siemens-enterprise.com> wrote: > Agree with Hadriel here I so no additional security benefit for EKT given > that any media gateway is going to be in cahoots with the webserver and has > access to the key. > > So all we are left with is the performance benefit of using SDES support > in the browser which is significant and reduces the barrier to deploying > WebRTC so let's go for the option that is easy to specify, easy to deploy, > cheap to implement (already exists in Chrome), and we are all familiar with. > > SDES support looks like the obvious choice. > > Not to play devil's advocate, but how is it any different then arguments to support plain RTP? All the same things apply to RTP. On top of this SRTP is no more secure then plain RTP when communicating with a server over plain HTTP or communicating with untrusted server over HTTPS. If we decided that RTP is unacceptable from security point of view, then how is SRTP acceptable? _____________ Roman Shpount --047d7bb04c90e5ff5e04df9c33af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Thu, Jun 20, 2013 at 4:52 PM, Hutton, Andrew <= a= ndrew.hutton@siemens-enterprise.com> wrote:
    Agree with Hadriel here I so no additional s= ecurity benefit for EKT given that any media gateway is going to be in caho= ots with the webserver and has access to the key.

    So all we are left with is the performance benefit of using SDES support in= the browser which is significant and reduces the barrier to deploying WebR= TC so let's go for the option that is easy to specify, easy to deploy, = cheap to implement (already exists in Chrome), and we are all familiar with= .

    SDES support looks like the obvious choice.


    Not to play devil's advocate, but = how is it any different then arguments to support plain RTP? All the same t= hings apply to RTP. On top of this SRTP is no more secure then plain RTP wh= en communicating with a server over plain HTTP or communicating with untrus= ted server over HTTPS. If we decided that RTP is unacceptable from security= point of view, then how is SRTP acceptable?
    _____________
    Roman Shpount
    =A0
    --047d7bb04c90e5ff5e04df9c33af-- From andrew.hutton@siemens-enterprise.com Thu Jun 20 14:25:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20C321F919D for ; Thu, 20 Jun 2013 14:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i29Tlls0ptKB for ; Thu, 20 Jun 2013 14:25:47 -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 A681721E80CD for ; Thu, 20 Jun 2013 14:25:42 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id A23921EB8452; Thu, 20 Jun 2013 23:25:21 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Thu, 20 Jun 2013 23:25:21 +0200 From: "Hutton, Andrew" To: Roman Shpount Thread-Topic: [rtcweb] No Interim on SDES at this juncture Thread-Index: AQHObVFVBYzpHvj1BUGlhj09l8oaqpk+DoOAgAEDiyD//+OAgIAAIqoA Date: Thu, 20 Jun 2013 21:25:20 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115D2E8D@MCHP04MSX.global-ad.net> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115D2D76@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: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF115D2E8DMCHP04MSXglobal_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 21:25:52 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF115D2E8DMCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Communication with an untrusted server is always insecure, even if using DT= LS-SRTP, it is surely the level of risk that is the issue and the problem t= o solve is how the browser indicates that to the user. Using SRTP is always more secure than using plain RTP but again I think the= problem to be solved is how the user is notified about the level of risk. Regards Andy From: Roman Shpount [mailto:roman@telurix.com] Sent: 20 June 2013 21:58 To: Hutton, Andrew Cc: Hadriel Kaplan; Richard Barnes; rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture On Thu, Jun 20, 2013 at 4:52 PM, Hutton, Andrew > wrote: Agree with Hadriel here I so no additional security benefit for EKT given t= hat any media gateway is going to be in cahoots with the webserver and has = access to the key. So all we are left with is the performance benefit of using SDES support in= the browser which is significant and reduces the barrier to deploying WebR= TC so let's go for the option that is easy to specify, easy to deploy, chea= p to implement (already exists in Chrome), and we are all familiar with. SDES support looks like the obvious choice. Not to play devil's advocate, but how is it any different then arguments to= support plain RTP? All the same things apply to RTP. On top of this SRTP i= s no more secure then plain RTP when communicating with a server over plain= HTTP or communicating with untrusted server over HTTPS. If we decided that= RTP is unacceptable from security point of view, then how is SRTP acceptab= le? _____________ Roman Shpount --_000_9F33F40F6F2CD847824537F3C4E37DDF115D2E8DMCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Communication with an unt= rusted server is always insecure, even if using DTLS-SRTP, it is surely the= level of risk that is the issue and the problem to solve is how the browser indicates that to the user.

     <= /p>

    Using SRTP is always more= secure than using plain RTP but again I think the problem to be solved is = how the user is notified about the level of risk.

     <= /p>

    Regards=

    Andy

     <= /p>

     <= /p>

     <= /p>

     <= /p>

     <= /p>

     <= /p>

     <= /p>

     <= /p>

    From: Roman Sh= pount [mailto:roman@telurix.com]
    Sent: 20 June 2013 21:58
    To: Hutton, Andrew
    Cc: Hadriel Kaplan; Richard Barnes; rtcweb@ietf.org
    Subject: Re: [rtcweb] No Interim on SDES at this juncture=

     

    On Thu, Jun 20, 2013 at 4:52 PM, Hutton, Andrew <= a= ndrew.hutton@siemens-enterprise.com> wrote:

    Agree with Hadriel he= re I so no additional security benefit for EKT given that any media gateway= is going to be in cahoots with the webserver and has access to the key.
    So all we are left with is the performance benefit of using SDES support in= the browser which is significant and reduces the barrier to deploying WebR= TC so let's go for the option that is easy to specify, easy to deploy, chea= p to implement (already exists in Chrome), and we are all familiar with.

    SDES support looks like the obvious choice.

     

    Not to play devil's advocate, but how is it any diff= erent then arguments to support plain RTP? All the same things apply to RTP= . On top of this SRTP is no more secure then plain RTP when communicating w= ith a server over plain HTTP or communicating with untrusted server over HTTPS. If we decided that RTP is unacceptable f= rom security point of view, then how is SRTP acceptable?

    _____________
    Roman Shpount

     

    --_000_9F33F40F6F2CD847824537F3C4E37DDF115D2E8DMCHP04MSXglobal_-- From ibc@aliax.net Thu Jun 20 14:27:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275ED21E80C9 for ; Thu, 20 Jun 2013 14:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvaWI5nXnXYA for ; Thu, 20 Jun 2013 14:27:46 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB4721E8064 for ; Thu, 20 Jun 2013 14:27:46 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so18755qab.8 for ; Thu, 20 Jun 2013 14:27:45 -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=smu6FQFU1/bJ4OXvHDeCstHu4WtP/3j19fbggtcvtN4=; b=fv4idoYYQIeWgpXfk2OczxYcE7lhMqEvk9Sxdrfz/M24nRoxu/F0TMlQFWNRLnZg2y dYPH4VQY7juBontRGQSCd6c9J4YW1E77EoLYDpiZy75juaSg0R0p5XPyrkXHlZgYofeI DNbq3XV+WRWQO45wgwNVjwmAxspf8IMBm+iK7/nWzQ7HaIhd98xTwQSsJ5Zgl1iVLRUn U5hnW+4IF68J8xeYcHHNS3/biCrPJkE0TzTvTnQ9laMz1UhsDWp/scqMZuhgF15ujUvN JAI3G3elOeiVsGjTj5i7gOIXUUti0jrkuuG70hqbYJIuDOyQYDRelV0djY1MhlzucPJb xktw== X-Received: by 10.224.177.201 with SMTP id bj9mr11031911qab.14.1371763665604; Thu, 20 Jun 2013 14:27:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Thu, 20 Jun 2013 14:27:25 -0700 (PDT) In-Reply-To: <51C333E1.1030709@hookflash.com> References: <51C333E1.1030709@hookflash.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 20 Jun 2013 23:27:25 +0200 Message-ID: To: Robin Raymond Content-Type: multipart/related; boundary=20cf303b39f1014e1804df9c9ebe X-Gm-Message-State: ALoCoQloHjfPhmg/pN/rTqg62dOCRBUNHm8jwa190potuTu8pE6A8F70P3R/ZRqZ3OSX2O6tGKl/ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC JS object API with SDP shim option X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 21:27:47 -0000 --20cf303b39f1014e1804df9c9ebe Content-Type: multipart/alternative; boundary=20cf303b39f1014e1604df9c9ebd --20cf303b39f1014e1604df9c9ebd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable IMHO this is the way to go, something that will make feasible to build any *future* protocol that just relies in RTP but not on SDP O/A. +1 2013/6/20 Robin Raymond > > You are right. It's time for those of us who are begging for an > alternative to SDP to come up with an alternative. > > I'm willing to lead such an effort. I just ask others to please have an > open mind. I absolutely do understand the need for the SIP world to have = an > easy API they can use for SDP. But I also know SDP as an primary surface > API is making anything beyond a basic calling a requirement to mangle SDP > as a mechanism to control and obtain properties from an underlying > media/RTC engine. > > I think there is a really good compromise. That is to provide an API that > will adhere to the security policies needed (e.g. respects the need to > require ICE establishment), but provides a simple shim API similar to wha= t > people already have with SDP but not be required to use for those who wan= t > to a more direct approach. > > There's no need to "burn" the entire thing to the ground and start over > and that is _not_ my desire. > > This WebRTC thing must succeed but I can't imagine the W3C accepting our > proposal for mangling SDP as a primary surface API to do common edge case > scenarios. WIth an alternative proposal that satisfies both camps, I > believe they could accept and we can stop the anit-SDP crowd grumblings > once and for all. > > To that end I'm going to write two drafts: > draft-raymond-webrtc-js-object-api-rationale-00 (to explain requirements, > philosophy, methodology, benefits/pitfalls, use cases that are > difficult/impossible with SDP+O/A) > draft-raymond-webrtc-js-object-api-00 (to outline the actual API) > > Plus, I'll produce a shim on top of whatever API that will allow the SDP > folks to have a simple SDP based API similar to what exists now but is > entirely written in JavaScript to prove that this can be done. > > I really want a viable solutions for all interested in having a really > good proposal API to ultimately become accepted by the W3C. > > If anyone has anything I should add to either of these drafts or wants to > be involved, please contact me. > > -Robin > > > Christer Holmberg > 20 June, 2013 12:55 AM > Hi, > > > At the virtual interim, the Plan A and Plan B folks were asked to sit dow= n > and try to come up with a compromise "Plan AB" solution. > > I guess it would be good if people that don't want SDP could try to come > up with a compromise "CU No Plan" solution :) > > Regards, > > Christer > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --=20 I=C3=B1aki Baz Castillo --20cf303b39f1014e1604df9c9ebd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    IMHO this is the way to go, something that will make feasi= ble to build any *future* protocol that just relies in RTP but not on SDP O= /A.

    +1


    2013/6/20 Robin Raymond <robin@hookflash.com>

    You are right. It's time for those of us who are begging for an=20 alternative to SDP to come up with an alternative.

    I'm willing to lead such an effort. I just ask others to please have an= =20 open mind. I absolutely do understand the need for the SIP world to have an easy API they can use for SDP. But I also know SDP as an primary=20 surface API is making anything beyond a basic calling a requirement to=20 mangle SDP as a mechanism to control and obtain properties from an=20 underlying media/RTC engine.

    I think there is a really good compromise. That is to provide an API=20 that will adhere to the security policies needed (e.g. respects the need to require ICE establishment), but provides a simple shim API similar=20 to what people already have with SDP but not be required to use for=20 those who want to a more direct approach.

    There's no need to "burn" the entire thing to the ground and = start over=20 and that is _not_ my desire.

    This WebRTC thing must succeed but I can't imagine the W3C accepting ou= r proposal for mangling SDP as a primary surface API to do common edge=20 case scenarios. WIth an alternative proposal that satisfies both camps, I believe they could accept and we can stop the anit-SDP crowd grumblings once and for all.

    To that end I'm going to write two drafts:
    draft-raymond-webrtc-js-object-api-rationale-00 (to explain=20 requirements, philosophy, methodology, benefits/pitfalls, use cases that are difficult/impossible with SDP+O/A)
    draft-raymond-webrtc-js-object-api-00 (to outline the actual API)

    Plus, I'll produce a shim on top of whatever API that will allow the SD= P folks to have a simple SDP based API similar to what exists now but is=20 entirely written in JavaScript to prove that this can be done.

    I really want a viable solutions for all interested in having a really=20 good proposal API to ultimately become accepted by the W3C.

    If anyone has anything I should add to either of these drafts or wants=20 to be involved, please contact me.

    -Robin


    =20 20 June, 2013=20 12:55 AM
    Hi,<= br>

    At the virtual interim, the Plan A and Plan B folks were asked to sit down and try to come up with a compromise "Plan AB" solution.

    = I guess it would be good if people that don't want SDP could try to come up=20 with a compromise "CU No Plan" solution :)

    Regards,
    Christer


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




    --
    I=C3=B1a= ki Baz Castillo
    <ibc@aliax.net&g= t;
    --20cf303b39f1014e1604df9c9ebd-- --20cf303b39f1014e1804df9c9ebe Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 4fc82587359b52ed_0.0.1.1 /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQECAQEB AQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAARCAAZABkDAREA AhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUKBwAAAAAAAAACAQME BQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAAAAAAAAAAAAADAAEEAv/E ACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oADAMBAAIRAxEAPwDuEt+gW/UL et6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJVIl7eXLCaZIGwBl3TY8epPx2+jy2 ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJ Ew/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx+a69/JSf9alIlste0VzaNpeFrcT9KKymotyi aZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mRUfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRD nu5azS8miKqjOTVkKqS/psG37fo1Fbabeg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GA cpOwBeN+U8/IkGbsiS8b7ryogmbzhbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH 4hPOI0DkjZtaJtFxuVEbIUUiyeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJ nYn9dnAQWl722p4ot37yzqnlfp6FrqbwawG8/9k= --20cf303b39f1014e1804df9c9ebe-- From ibc@aliax.net Thu Jun 20 14:49:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFCD11E80E1 for ; Thu, 20 Jun 2013 14:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9J8NiFKYQSL for ; Thu, 20 Jun 2013 14:49:58 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1812011E80E4 for ; Thu, 20 Jun 2013 14:49:48 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so37173qab.1 for ; Thu, 20 Jun 2013 14:49: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=uCrDZ1/W2yBYA4Lml8KZI7/Wb+Kx0Wcvernped6bLlg=; b=FjSepNA5iEW9p6BsL8M3k94d3YlH9img820xq2JBghcA5947Nsor5XqD0t/mNcMA70 s/lKiaTLWca1hn+3cFTlA1cnN+2Dz3XoPA+4hslP8OCTL4usj+t9zxP1l3EGH0jxjsCO eu9Zf/nOovNx2qUcdt3nTDhylGX8l9WV8spdJ4ajUBn51q8kFMs98LVl5RcCoY0Keqeh 9l+D6KlbC1zQZHhGsPobB5oftVr0NdjxrWxT3VarNo9KZj9KBnZ8wDdZnxCAbOvmVvPT o6i4j9/35FXOx6tEGDror4zq8MtUXorAl/QhinaAFuodmCDFPAnJkCKCC13aiXymBrmo naSw== X-Received: by 10.224.177.201 with SMTP id bj9mr11105864qab.14.1371764987536; Thu, 20 Jun 2013 14:49:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Thu, 20 Jun 2013 14:49:27 -0700 (PDT) In-Reply-To: <51C335F9.4000900@alvestrand.no> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 20 Jun 2013 23:49:27 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQncxeep2/xyBoiDvt2vtG1cWnVEW1M4Is4ZdXrATRhYK/lv1IX1ucYNeM5fNpWfItb4x/Je Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 21:49:59 -0000 2013/6/20 Harald Alvestrand : >> IMHO it would be much more interesting a JS demo that takes the SDP >> generated by Chrome and "converts" it into a Jingle XML session >> description (I mean XEP-0167), and that can interoperate (via XMPP >> over WebSocket or whatever) with a XMPP/Jingle endpoint by >> incrementally sending/receiving transport (ICE stuff) and media >> capabilities (as XEP-0167 allows) in different XMPP messages. > > You find it interesting. I'm sure you have a particular XMPP/Jingle > endpoint in mind that you want to connect to. > > Create one. Or try, and share with us why it did not work. It will not work (with the current SDP-based model) because it will require that my JS code parses the SDP blob retrieved from the browser, extracts all the fields/attributes and "exports" them into some XML bodies. What is the problem here? SDP itself because there are tons of possible valid representations for the *same* session description information into SDP blobs that look different (but mean the same). And the problem is that we don't know how the SDP blob retrieved from current browser model and version will look. My JS code could properly parse a SDP blob generated by Chrome 35 but may fail in Chrome 36 or Firefox 29 due to "cosmethic" changes in the SDP. If this statement is not true (I hope I don't need to code a XMPP/Jingle endpoint to prove it...), why are there so many SDP compatibility issues in widely deployed SDP-based protocolos (i.e. SIP)? Why do SBCs exist? (I know "fixing-SDP-compatibility-issues" is not their only feature, but it is one of them). >> And it would also be interesting a JS demo that interoperates with a >> SIP gateway and is able to perform the "hold" / "unhold" feature so >> widely extended in SIP world (via reINVITE with a=3Dinactive/sendonly >> and 200 "OK" with a=3Dinactive/recvonly). > > We have people who have demonstrated interoperability with SIP softphones= . > Some of them are on this list. > Can they tell us what happened when they tried? Which kind of interoperability? Let me guess it: - Initial INVITE with SDP. - 200 OK response with SDP. - Lot of applause when the browser produces audio. - BYE. In JsSIP we are getting frustrated trying to implement the "hold" / "unhold" feature because it requires SDP parsing and mangling. Sending a re-INVITE with a modified SDP (now with a video track enabled) seems to work (after lot of pain) but we still miss a reliable API to know what the new SDP means. Instead we need to parse the SDP to detect global (or per m=3D) line attributes like "a=3Dinactive" or "a=3Dsendonly" etc etc. It's really painful. BTW I don't know wheter you support PlanA, PlanB or NoPlan, but I did a question (in this case about NoPlan) for which I got no response, and honestly I would like to see it replied regardless the solution uses PlanA, PlanB or NoPlan model: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07871.html I would *really* appreciate a response to that mail (with any Plan as solution), really. Best regards. -- I=C3=B1aki Baz Castillo From rlb@ipv.sx Thu Jun 20 15:24:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F1921F9E39 for ; Thu, 20 Jun 2013 15:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.375 X-Spam-Level: * X-Spam-Status: No, score=1.375 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKH8YvjTcIfT for ; Thu, 20 Jun 2013 15:24:34 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D756221F9DF7 for ; Thu, 20 Jun 2013 15:24:14 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id m1so8488652oag.6 for ; Thu, 20 Jun 2013 15:24:03 -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:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=uyIJ+xKil9oDtGYhVLf7TDXJuxrclUiixZ7FMUD/LFg=; b=NtwILv10OK+GBx7B7Af6xzcLdBHjvCCuXtBrN6tb2GKhlUDg0JDIUmZucZQUUUWm4p 1ZOLNQssHpDButA6JYg8z5NuR45i7O4fkk5PyuUoOWknjtQqXYxvjz+KOS9yu/yLGkO2 4/hxhFuEnL7eGMc91Aaulk9q+oXY8v/BPvlBm+EbQmF+V4UpGnKZzXMzgJ2jqj9qBQ5A m4P5mYJtaXd07nxJkewDmmDKOOXvaRM4CDdxs7rSWGt73HFlI50GMNPKkKwV7hGZBj6s Ulu4Phxfvz5w4WDgsCpLi5jIScMHFPLN0lZYWPeC+H4hUv39A1o25YvFbps940pMWsZx XOFg== MIME-Version: 1.0 X-Received: by 10.60.33.202 with SMTP id t10mr5357348oei.2.1371767043831; Thu, 20 Jun 2013 15:24:03 -0700 (PDT) Received: by 10.60.26.135 with HTTP; Thu, 20 Jun 2013 15:24:03 -0700 (PDT) X-Originating-IP: [108.18.40.68] In-Reply-To: <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> Date: Thu, 20 Jun 2013 18:24:03 -0400 Message-ID: From: Richard Barnes To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=089e013c66b45cca0104df9d6775 X-Gm-Message-State: ALoCoQnOQXEPcTXwRf0vDK7URMJP7TIl8P2lOerDps64qSri6P+uUMq7jepWsQdaFjuX1OamUXvf Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 22:24:39 -0000 --089e013c66b45cca0104df9d6775 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 20, 2013 at 3:11 AM, Hadriel Kaplan wrote: > > On Jun 19, 2013, at 8:58 PM, Richard Barnes wrote: > > > I think we still disagree on the scenario. I've tried to sketch out the > full sequence of operations to be clear. (WebSequenceDiagrams source > below.) > > > > > > ISTM that there are two major differences: > > -- In the SDES case, the JS and the Web Server both have access to the > media keys. In the EKT case, the browser handles the keying update > directly. > > -- In the EKT case, the PBX/gateway has to be in the media path to do > EKT. After EKT, it just switches packets (it's basically a TURN server). > > > > So it seems like a security benefit for EKT and a performance benefit > for SDES. Your quantitative valuation of these benefits / costs may vary. > > I'm confused. EKT has "a security benefit" for whom, exactly? > It's not more secure for the browser user, since a malicious web server > can simply *be* the PBX, terminate DTLS-EKT and get the key and the browser > user would never know it. > It's not more secure for the SIP user, since the SIP user is only doing > SDES and has no idea what's happening on the far-end. > > Who are you saying is being better protected from what? > It's more secure in the sense that it makes a malicious web server do more work: It forces the web server to act as the PBX and terminate DTLS, instead of just pulling the key out of the SDP and decrypting media. So the browser user is (incrementally) better protected against the malicious web server. It's more secure in the sense that JS can't access the key, so an injected script can't grab the key and exfiltrate it. So the browser user is better protected against XSS risks. It's more secure in the sense that SDES has no end-to-end authentication [1], so implementing SDES creates bid-down attacks. If an attacker can't get a valid identity, he just claims not to support DTLS-SRTP. So the browser user is better protected against bid-down attacks by remote users (e.g., the malicious web server's PBX). --Richard > > I suppose we could claim the owner of the PBX feels more secure, if > they're not the same as the owner of the web-server and don't trust the > web-server. But again, if the web-server owner is malicious it will just > terminate the media pretending to be the PBX on one side, and pretending to > be the browser to the real PBX on the other side. And why would a PBX > owner accept calls from a web-server it doesn't trust to begin with? > > Afaict, the main security benefit of DTLS-EKT is the same as that of > DTLS-SRTP: the keys aren't sent in the JSON/SDP/whatever, so they can't be > sniffed even if cleartext HTTP is used. So in a weird way, the security > benefit of it is it let's us use an insecure HTTP transport for the > JSON/SDP/HTML/whatever. Luckily the ability to see and modify what goes on > there is no big deal... like for example be able to insert a malicious > DTLS-SRTP B2BUA that records everything. Oh, wait... > > -hadriel > > --089e013c66b45cca0104df9d6775 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Thu, Jun 20, 2013 at 3:11 AM, Hadriel Kaplan <hadriel.kaplan@oracle.com> wrote:

    On Jun 19, 2013, at 8:58 PM, Richard Barnes <rlb@ipv.sx> wrote:

    > I think we still disagree on the scenario. =A0= I've tried to sketch out the full sequence of operations to be clear. = =A0(WebSequenceDiagrams source below.)
    > <http://goo.gl/uR= i0W>
    >
    > ISTM that there are two major differences:
    > -- In the SDES case, the JS and the Web Server both have access to the= media keys. =A0In the EKT case, the browser handles the keying update dire= ctly.
    > -- In the EKT case, the PBX/gateway has to be in the media path to do = EKT. =A0After EKT, it just switches packets (it's basically a TURN serv= er).
    >
    > So it seems like a security benefit for EKT and a performance benefit = for SDES. =A0Your quantitative valuation of these benefits / costs may vary= .

    I'm confused. =A0EKT has "a security benefit" for whom,= exactly?
    It's not more secure for the browser user, since a malicious web server= can simply *be* the PBX, terminate DTLS-EKT and get the key and the browse= r user would never know it.
    It's not more secure for the SIP user, since the SIP user is only doing= SDES and has no idea what's happening on the far-end.

    Who are you saying is being better protected from what?

    It's more secure in the sense that it makes a malicious web server do = more work: It forces the web server to act as the PBX and terminate DTLS, i= nstead of just pulling the key out of the SDP and decrypting media. =A0So t= he browser user is (incrementally) better protected against the malicious w= eb server.

    It's more secure i= n the sense that JS can't access the key, so an injected script can'= ;t grab the key and exfiltrate it. =A0So the browser user is better protect= ed against XSS risks.

    It's more secure in the sense that SDES has n= o end-to-end authentication [1], so implementing SDES creates bid-down atta= cks. =A0If an attacker can't get a valid identity, he just claims not t= o support DTLS-SRTP. =A0So the browser user is better protected against bid= -down attacks by remote users (e.g., the malicious web server's PBX).

    --Richard



    =A0

    I suppose we could claim the owner of the PBX feels more secure, if they= 9;re not the same as the owner of the web-server and don't trust the we= b-server. =A0But again, if the web-server owner is malicious it will just t= erminate the media pretending to be the PBX on one side, and pretending to = be the browser to the real PBX on the other side. =A0And why would a PBX ow= ner accept calls from a web-server it doesn't trust to begin with?

    Afaict, the main security benefit of DTLS-EKT is the same as that of DTLS-S= RTP: the keys aren't sent in the JSON/SDP/whatever, so they can't b= e sniffed even if cleartext HTTP is used. =A0So in a weird way, the securit= y benefit of it is it let's us use an insecure HTTP transport for the J= SON/SDP/HTML/whatever. =A0Luckily the ability to see and modify what goes o= n there is no big deal... like for example be able to insert a malicious DT= LS-SRTP B2BUA that records everything. =A0Oh, wait...

    -hadriel


    --089e013c66b45cca0104df9d6775-- From rlb@ipv.sx Thu Jun 20 15:25:21 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF9421E809E for ; Thu, 20 Jun 2013 15:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.373 X-Spam-Level: * X-Spam-Status: No, score=1.373 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35U3sZFaQsvS for ; Thu, 20 Jun 2013 15:25:17 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5C721E8091 for ; Thu, 20 Jun 2013 15:25:17 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wd20so7823901obb.33 for ; Thu, 20 Jun 2013 15:25:16 -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:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=BGCAkY7THlxX6I1/BDC1u03gfN2wxJn4DW9XwihkqK4=; b=W7x/BQChYnpjoJYippLKZ/c6mOZCywE2stZwryhjOvM1o+DPZ85tCel6knwrsPE/+E ENDJEUMZ2B9dXEA8UlhWrEntVNrSgNg6/Zpn8rBdH4mIRYLeU0pyLAdLiZBymzTXPApF HzsvJ+NEW77XTe1H1LWzmwcopQSxbYTGPvAo61/jl2zP4KwbLIWkp0bLICuUBYB+RyCf wSTIRSj5MFBZSxetSd+UmtA3OdQdkFZqWbbHV01mtR7snmUBYTz9Jbm9em8wmGK3KGBb WcsX4BMTtdfQzuyWJPxUwkwZsfy45p5WstBzrPubYd9CW568Zmt2GDpw1/JVWIo/v1Iy Z6fQ== MIME-Version: 1.0 X-Received: by 10.182.246.198 with SMTP id xy6mr2446330obc.1.1371767116775; Thu, 20 Jun 2013 15:25:16 -0700 (PDT) Received: by 10.60.26.135 with HTTP; Thu, 20 Jun 2013 15:25:16 -0700 (PDT) X-Originating-IP: [108.18.40.68] In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115D2D76@MCHP04MSX.global-ad.net> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115D2D76@MCHP04MSX.global-ad.net> Date: Thu, 20 Jun 2013 18:25:16 -0400 Message-ID: From: Richard Barnes To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=001a11c1bc04b5d81104df9d6bc0 X-Gm-Message-State: ALoCoQnAJxhEoO5V7pdJThCRsV5y7vyRdm9JQtSKGBuORoG8umZ4zDK6CyN1TPHNSm0118FcxcJX Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 22:25:21 -0000 --001a11c1bc04b5d81104df9d6bc0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 20, 2013 at 4:52 PM, Hutton, Andrew < andrew.hutton@siemens-enterprise.com> wrote: > Agree with Hadriel here I so no additional security benefit for EKT given > that any media gateway is going to be in cahoots with the webserver and has > access to the key. > See my reply to Hadriel on XSS and bid-down attacks. > So all we are left with is the performance benefit of using SDES support > in the browser which is significant and reduces the barrier to deploying > WebRTC so let's go for the option that is easy to specify, easy to deploy, > cheap to implement (already exists in Chrome), and we are all familiar with. > > SDES support looks like the obvious choice. > > Regards > Andy > > > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of Hadriel Kaplan > > Sent: 20 June 2013 08:11 > > To: Richard Barnes > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] No Interim on SDES at this juncture > > > > > > On Jun 19, 2013, at 8:58 PM, Richard Barnes wrote: > > > > > I think we still disagree on the scenario. I've tried to sketch out > > the full sequence of operations to be clear. (WebSequenceDiagrams > > source below.) > > > > > > > > > ISTM that there are two major differences: > > > -- In the SDES case, the JS and the Web Server both have access to > > the media keys. In the EKT case, the browser handles the keying update > > directly. > > > -- In the EKT case, the PBX/gateway has to be in the media path to do > > EKT. After EKT, it just switches packets (it's basically a TURN > > server). > > > > > > So it seems like a security benefit for EKT and a performance benefit > > for SDES. Your quantitative valuation of these benefits / costs may > > vary. > > > > I'm confused. EKT has "a security benefit" for whom, exactly? > > It's not more secure for the browser user, since a malicious web server > > can simply *be* the PBX, terminate DTLS-EKT and get the key and the > > browser user would never know it. > > It's not more secure for the SIP user, since the SIP user is only doing > > SDES and has no idea what's happening on the far-end. > > > > Who are you saying is being better protected from what? > > > > I suppose we could claim the owner of the PBX feels more secure, if > > they're not the same as the owner of the web-server and don't trust the > > web-server. But again, if the web-server owner is malicious it will > > just terminate the media pretending to be the PBX on one side, and > > pretending to be the browser to the real PBX on the other side. And > > why would a PBX owner accept calls from a web-server it doesn't trust > > to begin with? > > > > Afaict, the main security benefit of DTLS-EKT is the same as that of > > DTLS-SRTP: the keys aren't sent in the JSON/SDP/whatever, so they can't > > be sniffed even if cleartext HTTP is used. So in a weird way, the > > security benefit of it is it let's us use an insecure HTTP transport > > for the JSON/SDP/HTML/whatever. Luckily the ability to see and modify > > what goes on there is no big deal... like for example be able to insert > > a malicious DTLS-SRTP B2BUA that records everything. Oh, wait... > > > > -hadriel > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c1bc04b5d81104df9d6bc0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Thu, Jun 20, 2013 at 4:52 PM, Hutton, Andrew <andrew.hutton@siemens-enterprise.com> wrote:
    <= div class=3D"gmail_extra">
    Agree with Hadrie= l here I so no additional security benefit for EKT given that any media gat= eway is going to be in cahoots with the webserver and has access to the key= .

    See my reply to Hadriel on XSS and bid-dow= n attacks.

    =A0
    So all we are left with is the performance benefit of using SDES support in= the browser which is significant and reduces the barrier to deploying WebR= TC so let's go for the option that is easy to specify, easy to deploy, = cheap to implement (already exists in Chrome), and we are all familiar with= .

    SDES support looks like the obvious choice.

    Regards
    Andy



    > -----Original Message-----
    > From: rtcweb-bounces@ietf.o= rg [mailto:rtcweb-bounces@ie= tf.org] On
    > Behalf Of Hadriel Kaplan
    > Sent: 20 June 2013 08:11
    > To: Richard Barnes
    > Cc: rtcweb@ietf.org
    > Subject: Re: [rtcweb] No Interim on SDES at this juncture
    >
    >
    > On Jun 19, 2013, at 8:58= PM, Richard Barnes <rlb@ipv.sx> wrote:
    >
    > > I think we still disagree on the scenario. =A0I've tried to s= ketch out
    > the full sequence of operations to be clear. =A0(WebSequenceDiagrams > source below.)
    > > <http://goo.= gl/uRi0W>
    > >
    > > ISTM that there are two major differences:
    > > -- In the SDES case, the JS and the Web Server both have access t= o
    > the media keys. =A0In the EKT case, the browser handles the keying upd= ate
    > directly.
    > > -- In the EKT case, the PBX/gateway has to be in the media path t= o do
    > EKT. =A0After EKT, it just switches packets (it's basically a TURN=
    > server).
    > >
    > > So it seems like a security benefit for EKT and a performance ben= efit
    > for SDES. =A0Your quantitative valuation of these benefits / costs may=
    > vary.
    >
    > I'm confused. =A0EKT has "a security benefit" for whom, = exactly?
    > It's not more secure for the browser user, since a malicious web s= erver
    > can simply *be* the PBX, terminate DTLS-EKT and get the key and the > browser user would never know it.
    > It's not more secure for the SIP user, since the SIP user is only = doing
    > SDES and has no idea what's happening on the far-end.
    >
    > Who are you saying is being better protected from what?
    >
    > I suppose we could claim the owner of the PBX feels more secure, if > they're not the same as the owner of the web-server and don't = trust the
    > web-server. =A0But again, if the web-server owner is malicious it will=
    > just terminate the media pretending to be the PBX on one side, and
    > pretending to be the browser to the real PBX on the other side. =A0And=
    > why would a PBX owner accept calls from a web-server it doesn't tr= ust
    > to begin with?
    >
    > Afaict, the main security benefit of DTLS-EKT is the same as that of > DTLS-SRTP: the keys aren't sent in the JSON/SDP/whatever, so they = can't
    > be sniffed even if cleartext HTTP is used. =A0So in a weird way, the > security benefit of it is it let's us use an insecure HTTP transpo= rt
    > for the JSON/SDP/HTML/whatever. =A0Luckily the ability to see and modi= fy
    > what goes on there is no big deal... like for example be able to inser= t
    > a malicious DTLS-SRTP B2BUA that records everything. =A0Oh, wait... >
    > -hadriel
    >
    > __________________= _____________________________
    > rtcweb mailing list
    > rtcweb@ietf.org
    > https://www.ietf.org/mailman/listinfo/rtcweb

    --001a11c1bc04b5d81104df9d6bc0-- From emil@sip-communicator.org Thu Jun 20 15:34:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D4B21E8091 for ; Thu, 20 Jun 2013 15:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KtzH-D+5v64 for ; Thu, 20 Jun 2013 15:34:07 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5388521F9E8D for ; Thu, 20 Jun 2013 15:34:01 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so5942399wgh.0 for ; Thu, 20 Jun 2013 15:34:00 -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=ReFPsqn7JWLGoZKMgrNbb7mO2Ub+rNiUi6URMFiC0GA=; b=PevdXivpecCOfejU57x/h1AeUUaQC/Q9vMRPSzkbLCTfnfnCwEd7S9Pb0m979Ap1D4 u1eBbIjfmOdHNGQytCehvxaOPwzpTFLPPd7b9kHfr321eld9q/7i9HlKC3VDQQ8Cl0Ws nZyH9DZE4rqUFWmcqTGotkhrUPmtl0ynfn7uot9WulWK3J0MCFjzo0xZIVnF2AGHXbGX sTW3K/wbuhgTAEZHc7JGSPJnKr6FZGBVQmQRB1Glv8OdvFWPXBp8fUJfjzhNUhfkBFLG adkEkW40aY1NVpVPtzGL6Idg+6mpuOTa9wWFfOkNwC9HMNefV28qh1VjcGfEAmTPQFgi PmGg== X-Received: by 10.194.173.71 with SMTP id bi7mr7241052wjc.2.1371767640909; Thu, 20 Jun 2013 15:34:00 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id r9sm19207142wik.1.2013.06.20.15.33.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 15:34:00 -0700 (PDT) Message-ID: <51C38356.3020402@jitsi.org> Date: Fri, 21 Jun 2013 00:33:58 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk6p1qqhuvinuIcX/I3Pf7MZxpaBJMoqDPvbmkpPD+lRFhsHxF/AY+dHRDHGPodgIMkplyO Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 22:34:08 -0000 Hey I=C3=B1aki, On 20.06.13, 23:49, I=C3=B1aki Baz Castillo wrote: > In JsSIP we are getting frustrated trying to implement the "hold" / > "unhold" feature because it requires SDP parsing and mangling. Sending > a re-INVITE with a modified SDP (now with a video track enabled) seems > to work (after lot of pain) but we still miss a reliable API to know > what the new SDP means. Instead we need to parse the SDP to detect > global (or per m=3D) line attributes like "a=3Dinactive" or "a=3Dsendon= ly" > etc etc. It's really painful. I am having a problem following what you are trying to achieve here. In=20 JsSIP you seem to be going for a full SIP implementation in the browser. = If this is true and if this WG decides to remove SDP from the API=20 surface, then you would need to completely parse SDP in the JS and then=20 convert it into API calls. Similarly, when creating offers and answers=20 you would need to construct SDP all by yourself. So I am not sure why the SDP parsing in the current situation is so much = of a blocker for your use case. > BTW I don't know wheter you support PlanA, PlanB or NoPlan, but I did > a question (in this case about NoPlan) for which I got no response, > and honestly I would like to see it replied regardless the solution > uses PlanA, PlanB or NoPlan model: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07871.html > > I would *really* appreciate a response to that mail (with any Plan as > solution), really. Yup, sorry for being silent on that one. Busy days. My personal take on No Plan SIP interop is that the JS app would take=20 the initial SDP out of the browser, send it to a signalling gateway and=20 leave that gateway do whatever it wants with it. Some gateways will resend it with no changes (it is likely that an=20 increasing number of endpoints will come to support the kind of SDP that = comes from browsers). Most GWs will probably handle it as any B2BUA=20 handles a call leg. They'd keep a state and possibly convert some of the = SDP to match what various endpoints expect. The other option would be indeed to do the same thing in JS. I believe=20 this is JsSIP's use case. In that case however, regardless of whether=20 you choose Plan A, Plan B, No Plan or CU-RTC-Web, you will inevitably be = exposed to a fair amount of complexity, parsing and JS magic. You are, after all, building a SIP stack. In the above mail you also say: > Another example: > > * I am a powerful SIP conference server which properly implements > WebRTC. I initiate a call to 5 users (running JS SIP app in their > browsers). The initial INVITE has SSRC/MSID fields in the SDP > identifying all the participants, am I right? No, with No Plan there are no SSRCs and MSIDs in the SDP that comes from = the browser. > * Later, during the conference, I call to another 6th participant and > enter him into the conference, so I need to send a re-INVITE to every > participant with a modified version of the SDP (note that this is SIP > protocol, so I need to use SIP messages to carry the new info about > SSRC/MSID and so on). That's the thing. You don't need that. In Jitsi we do exactly this=20 operation with no Offer/Answer signalling. RTP carries enough=20 information to process streams and we use upper layer signalling (4575)=20 for things such as mapping SSRCs to users and announcing current=20 participant list. Cheers, Emil --=20 https://jitsi.org From bossiel@yahoo.fr Thu Jun 20 15:45:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E7021F9D90 for ; Thu, 20 Jun 2013 15:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VATJBwoa0aO5 for ; Thu, 20 Jun 2013 15:44:59 -0700 (PDT) Received: from nm25.bullet.mail.ir2.yahoo.com (nm25.bullet.mail.ir2.yahoo.com [212.82.96.49]) by ietfa.amsl.com (Postfix) with ESMTP id DD2A521E80C0 for ; Thu, 20 Jun 2013 15:44:58 -0700 (PDT) Received: from [212.82.98.124] by nm25.bullet.mail.ir2.yahoo.com with NNFMP; 20 Jun 2013 22:44:57 -0000 Received: from [212.82.108.113] by tm17.bullet.mail.ir2.yahoo.com with NNFMP; 20 Jun 2013 22:44:57 -0000 Received: from [127.0.0.1] by omp1022.mail.ird.yahoo.com with NNFMP; 20 Jun 2013 22:44:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 609994.71058.bm@omp1022.mail.ird.yahoo.com Received: (qmail 78289 invoked by uid 60001); 20 Jun 2013 22:44:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1371768297; bh=pSSMxiitxl2+tjNWqV6I+pMmez57uKK/Poicy8bQtNU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=k2ybzFUispdZVP8fE5XLBNcn1XySENnZgFIdz16cIRVKGz7qw42Zo6cEQ/bVcXJi29v4iq7SrWBNehgevfLlfvbesmDhGHrzkM1AZPuKteQ10tC0x6oNN1FhV5pAsJj9cFLO6dluQmkqWtZU9xieneaHLT1ye6+HoWYgJrhgpz8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=JNSHFOVmoODl/c8M/26Vxrph3RIfHpWOof6YMWEFNm9BVet8xRCI9bKCwcCOiqRw1tSzi0IxWkVNmUKwRr91UAKd+Fi/40IAj162a7CGlUQSk+KMmJUCDWAlX9+IsAuE/8LVGIATFa0ptluhMVVVntmmJ9lXHn8NpqYTi/ILEVE=; X-YMail-OSG: l8B4KQQVM1npLCxCxssNFseJiSGVfLVU9BXmyuWJnYGgEI3 vAjUjekFBjrIcs3FIRIEkqjNukx0Env3vM4GQPguKISujfUD.UDFHc8idMxv HbdQeW80kDYE0XoeZbHT885ACzkvRaoW4rbMNxKZvj5gR9bRqgVvPjiJJYvC btDXuXDNIC7xgRCzy12n_iTFHaSSt7TwKXe4uLHGyjaGvapnEZS_lIs.CEZp sioyGNzmvotlBhN9SNQwY0u2K4qWGqdxnEGAnt6A4EKbokmYXhry8l9v6_Ss G4u7PcpEuiMDJPzCyQlqNLjsrZZr3kkD_GsCOzooX049mPG6iiKXgPxOE.Ij lPxGkIiEmNAdBXMjlY.W1liiTIJ418IpJq_er.3eOxA75Hc25BKRSaIylHUG JmcN1zVdsJspqXznmnlfPsX_tGyTZY9zgdl74LlVCGW2vmO42fIyewK2y1MS X01rtvNuQ0Cmg56_x8c4x1L9lAt_zKaLODG.f7mT6jneOdQMI70j6k8oLFPJ xj37WEUHdj.Ow7g7hXmk8NM54aRwsXEzOvEP. Received: from [88.179.39.5] by web171302.mail.ir2.yahoo.com via HTTP; Thu, 20 Jun 2013 23:44:57 BST X-Rocket-MIMEInfo: 002.001, KzEgZm9yIFNEUCAuLi5idXQgd2UgKERvdWJhbmdvIFRlbGVjb20pIHdvdWxkIHByb3ZpZGUgYSBnYXRld2F5IHRvIFNJUC9JTVMgd29ybGQgZm9yIGFueSBzdWNoIGRyYWZ0IGFzIHByb29mIG9mIGNvbmNlcHQuCkkndmUgc2VlbiBvbiBtYW55IHBvc3RzIG9uIG1zZG4gYmxvZyB0aGF0IGl0J3MgZWFzeSB0byBpbnRlcm9wIHdpdGggU0lQIHVzaW5nIENVLVJUQy1XRUIgYnV0IGhhdmVuJ3Qgc2VlbiBhbnkgZGVtby4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRGXCoDogScOxYWtpIEJheiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.147.553 References: <51C333E1.1030709@hookflash.com> Message-ID: <1371768297.54026.YahooMailNeo@web171302.mail.ir2.yahoo.com> Date: Thu, 20 Jun 2013 23:44:57 +0100 (BST) From: Bossiel thioriguel To: Robin Raymond In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1670751155-516304665-1371768297=:54026" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC JS object API with SDP shim option X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bossiel thioriguel List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 22:45:04 -0000 --1670751155-516304665-1371768297=:54026 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable +1 for SDP ...but we (Doubango Telecom) would provide a gateway to SIP/IMS = world for any such draft as proof of concept.=0AI've seen on many posts on = msdn blog that it's easy to interop with SIP using CU-RTC-WEB but haven't s= een any demo.=0A=0A=0A________________________________=0A De=A0: I=F1aki Ba= z Castillo =0A=C0=A0: Robin Raymond = =0ACc=A0: "rtcweb@ietf.org" =0AEnvoy=E9 le : Jeudi 20 jui= n 2013 23h27=0AObjet=A0: Re: [rtcweb] WebRTC JS object API with SDP shim op= tion=0A =0A=0A=0AIMHO this is the way to go, something that will make feasi= ble to build any *future* protocol that just relies in RTP but not on SDP O= /A.=0A=0A+1=0A=0A=0A=0A2013/6/20 Robin Raymond =0A=0A= =0A>You are right. It's time for those of us who are begging for an =0Aalte= rnative to SDP to come up with an alternative.=0A>=0A>I'm willing to lead s= uch an effort. I just ask others to please have an =0Aopen mind. I absolute= ly do understand the need for the SIP world to have=0A an easy API they can= use for SDP. But I also know SDP as an primary =0Asurface API is making an= ything beyond a basic calling a requirement to =0Amangle SDP as a mechanism= to control and obtain properties from an =0Aunderlying media/RTC engine.= =0A>=0A>I think there is a really good compromise. That is to provide an AP= I =0Athat will adhere to the security policies needed (e.g. respects the ne= ed=0A to require ICE establishment), but provides a simple shim API similar= =0Ato what people already have with SDP but not be required to use for =0A= those who want to a more direct approach.=0A>=0A>There's no need to "burn" = the entire thing to the ground and start over =0Aand that is _not_ my desir= e.=0A>=0A>This WebRTC thing must succeed but I can't imagine the W3C accept= ing our=0A proposal for mangling SDP as a primary surface API to do common = edge =0Acase scenarios. WIth an alternative proposal that satisfies both ca= mps, I=0A believe they could accept and we can stop the anit-SDP crowd grum= blings=0A once and for all.=0A>=0A>To that end I'm going to write two draft= s:=0A>draft-raymond-webrtc-js-object-api-rationale-00 (to explain =0Arequir= ements, philosophy, methodology, benefits/pitfalls, use cases that=0A are d= ifficult/impossible with SDP+O/A)=0A>draft-raymond-webrtc-js-object-api-00 = (to outline the actual API)=0A>=0A>Plus, I'll produce a shim on top of what= ever API that will allow the SDP=0A folks to have a simple SDP based API si= milar to what exists now but is =0Aentirely written in JavaScript to prove = that this can be done.=0A>=0A>I really want a viable solutions for all inte= rested in having a really =0Agood proposal API to ultimately become accepte= d by the W3C.=0A>=0A>If anyone has anything I should add to either of these= drafts or wants =0Ato be involved, please contact me.=0A>=0A>-Robin=0A>=0A= >=0A>=0A>Christer Holmberg=0A>20 June, 2013 =0A12:55 AM=0A>Hi,=0A>=0A>=0A>= =0A>At=0A=0A the virtual interim, the Plan A and Plan B folks were asked to= sit down=0A and try to come up with a compromise "Plan AB" solution.=0A>= =0A>I guess=0A it would be good if people that don't want SDP could try to = come up =0Awith a compromise "CU No Plan" solution :)=0A>=0A>Regards,=0A>= =0A>Christer=0A>=0A>_______________________________________________=0A>rtcw= eb mailing list=0A>rtcweb@ietf.org=0A>https://www.ietf.org/mailman/listinfo= /rtcweb=0A>=0A>=0A=0A=0A-- =0AI=F1aki Baz Castillo=0A =0A___= ____________________________________________=0Artcweb mailing list=0Artcweb= @ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/rtcweb --1670751155-516304665-1371768297=:54026 Content-Type: multipart/related; boundary="1670751155-1211630109-1371768297=:54026" --1670751155-1211630109-1371768297=:54026 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    +1 for SDP= ...but we (Doubango Telecom) would provide a gateway to SIP/IMS world for = any such draft as proof of concept.
    I've seen= on many posts on msdn blog that it's easy to interop with SIP using CU-RTC= -WEB but haven't seen any demo.

    De : I=F1a= ki Baz Castillo <ibc@aliax.net>
    =C0 : Robin Raymond <robin@hookflash.com> Cc : "rtcweb@ietf.or= g" <rtcweb@ietf.org>
    Envoy= =E9 le : Jeudi 20 juin 2013 23h27
    Objet : Re: [rtcweb] WebRTC JS object API with = SDP shim option

    IMHO this is the way to go, something= that will make feasible to build any *future* protocol that just relies in= RTP but not on SDP O/A.

    +1


    =0A= =0A2013/6/20 Robin Raymond <robin@hookflash.com>
    =0A=0A=0A
    =0A
    =0AYou are right. It's time for = those of us who are begging for an =0Aalternative to SDP to come up with an= alternative.
    =0A
    =0AI'm willing to lead such an effort. I just ask= others to please have an =0Aopen mind. I absolutely do understand the need= for the SIP world to have=0A an easy API they can use for SDP. But I also = know SDP as an primary =0Asurface API is making anything beyond a basic cal= ling a requirement to =0Amangle SDP as a mechanism to control and obtain pr= operties from an =0Aunderlying media/RTC engine.
    =0A
    =0AI think the= re is a really good compromise. That is to provide an API =0Athat will adhe= re to the security policies needed (e.g. respects the need=0A to require IC= E establishment), but provides a simple shim API similar =0Ato what people = already have with SDP but not be required to use for =0Athose who want to a= more direct approach.
    =0A
    =0AThere's no need to "burn" the entire = thing to the ground and start over =0Aand that is _not_ my desire.
    =0A =
    =0AThis WebRTC thing must succeed but I can't imagine the W3C accepting= our=0A proposal for mangling SDP as a primary surface API to do common edg= e =0Acase scenarios. WIth an alternative proposal that satisfies both camps= , I=0A believe they could accept and we can stop the anit-SDP crowd grumbli= ngs=0A once and for all.
    =0A
    =0ATo that end I'm going to write two = drafts:
    =0Adraft-raymond-webrtc-js-object-api-rationale-00 (to explain = =0Arequirements, philosophy, methodology, benefits/pitfalls, use cases that= =0A are difficult/impossible with SDP+O/A)
    =0Adraft-raymond-webrtc-js-ob= ject-api-00 (to outline the actual API)
    =0A
    =0APlus, I'll produce a= shim on top of whatever API that will allow the SDP=0A folks to have a sim= ple SDP based API similar to what exists now but is =0Aentirely written in = JavaScript to prove that this can be done.
    =0A
    =0AI really want a v= iable solutions for all interested in having a really =0Agood proposal API = to ultimately become accepted by the W3C.
    =0A
    =0AIf anyone has anyt= hing I should add to either of these drafts or wants =0Ato be involved, ple= ase contact me.
    =0A
    =0A-Robin
    =0A
    =0A
    =0A
    =09
    =0A=0A
    =0A=0A =0A 20 June, 2013 =0A12:55 AM<= /font>
    =0A=0A
    Hi,


    At=0A=0A the virtual i= nterim, the Plan A and Plan B folks were asked to sit down=0A and try to co= me up with a compromise "Plan AB" solution.

    I guess=0A it would be g= ood if people that don't want SDP could try to come up =0Awith a compromise= "CU No Plan" solution :)

    Regards,

    Christer
    =0A <= br>=0A
    =0A=0A
    _______________________________________________
    = =0Artcweb mailing list
    =0Artcweb@ietf.org<= /a>
    =0A    https://www.ietf.org/mailman/listinfo/rtcweb=
    =0A



    --
    I= =F1aki Baz Castillo
    <ibc@aliax.net>= =0A

    _______________________________________________
    rtcwe= b mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/r= tcweb


    --1670751155-1211630109-1371768297=:54026 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-Id: <1.3787650210@web171302.mail.ir2.yahoo.com> /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQECAQEB AQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAARCAAZABkDAREA AhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUKBwAAAAAAAAACAQME BQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAAAAAAAAAAAAADAAEEAv/E ACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oADAMBAAIRAxEAPwDuEt+gW/UL et6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJVIl7eXLCaZIGwBl3TY8epPx2+jy2 ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJ Ew/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx+a69/JSf9alIlste0VzaNpeFrcT9KKymotyi aZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mRUfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRD nu5azS8miKqjOTVkKqS/psG37fo1Fbabeg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GA cpOwBeN+U8/IkGbsiS8b7ryogmbzhbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH 4hPOI0DkjZtaJtFxuVEbIUUiyeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJ nYn9dnAQWl722p4ot37yzqnlfp6FrqbwawG8/9k= --1670751155-1211630109-1371768297=:54026-- --1670751155-516304665-1371768297=:54026-- From roman@telurix.com Thu Jun 20 15:50:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5118A21E809E for ; Thu, 20 Jun 2013 15:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjl-6Jcn6hnN for ; Thu, 20 Jun 2013 15:50:29 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DD22B11E80E1 for ; Thu, 20 Jun 2013 15:50:28 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so6052638wgh.12 for ; Thu, 20 Jun 2013 15:50: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=nnQ23MIoz49Rv2mOA/LaYrFc70/TYnrl2pRMFpggYMY=; b=YILQxnBsNmf0fQRNvAa6yCiVpB22Ay4idstF+s9rBZ9zEYQJSAMXi3/CAinh0vkUsw 4pFbVLQXv1rrlRm9BDMLpz/MGpbE32J0SSOe5QZNgBgAAoyCvI4xc+O+D4If5re50e6v eF/S2vEkPRY40ikpjA77Nr3vrW/rdaaj9vaSsBKkHpt7Xj29y6mJazWnLJ3EGK14e7AX 1BfBUYnmVRH2LltibEwZudM6XqsUXhATQ3J/m5TLgjnJYiiTve9OXaODSoKN9Yx5uzgV En+Y67MRDC0QOH0AjO+5GVAs9D3deaj90v5wuDl5mnc2/MS98AR2Elr/93+SWcKXJh71 hnQg== X-Received: by 10.194.104.199 with SMTP id gg7mr7333571wjb.56.1371768628056; Thu, 20 Jun 2013 15:50:28 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [2a00:1450:400c:c00::22d]) by mx.google.com with ESMTPSA id f8sm1961358wiv.0.2013.06.20.15.50.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 15:50:27 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so5950220wgh.0 for ; Thu, 20 Jun 2013 15:50:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.81.103 with SMTP id z7mr874480wix.65.1371768624706; Thu, 20 Jun 2013 15:50:24 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Thu, 20 Jun 2013 15:50:24 -0700 (PDT) In-Reply-To: <1371768297.54026.YahooMailNeo@web171302.mail.ir2.yahoo.com> References: <51C333E1.1030709@hookflash.com> <1371768297.54026.YahooMailNeo@web171302.mail.ir2.yahoo.com> Date: Thu, 20 Jun 2013 18:50:24 -0400 Message-ID: From: Roman Shpount To: Bossiel thioriguel Content-Type: multipart/related; boundary=f46d044288cc9751ab04df9dc579 X-Gm-Message-State: ALoCoQnl8atgrk6Yx84d+actjNIsbb40/eUjGJjJv2qFKnoW0EAjeb+s2Hq0UG29cI1j3JgOvpWF Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC JS object API with SDP shim option X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 22:50:30 -0000 --f46d044288cc9751ab04df9dc579 Content-Type: multipart/alternative; boundary=f46d044288cc9751a804df9dc578 --f46d044288cc9751a804df9dc578 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 on this as well. We will provide a service which will connect something that implements this draft to public PSTN/SIP _____________ Roman Shpount On Thu, Jun 20, 2013 at 6:44 PM, Bossiel thioriguel wrote= : > +1 for SDP ...but we (Doubango Telecom) would provide a gateway to SIP/IM= S > world for any such draft as proof of concept. > I've seen on many posts on msdn blog that it's easy to interop with SIP > using CU-RTC-WEB but haven't seen any demo. > > ------------------------------ > *De :* I=F1aki Baz Castillo > *=C0 :* Robin Raymond > *Cc :* "rtcweb@ietf.org" > *Envoy=E9 le :* Jeudi 20 juin 2013 23h27 > *Objet :* Re: [rtcweb] WebRTC JS object API with SDP shim option > > IMHO this is the way to go, something that will make feasible to build an= y > *future* protocol that just relies in RTP but not on SDP O/A. > > +1 > > > 2013/6/20 Robin Raymond > > > You are right. It's time for those of us who are begging for an > alternative to SDP to come up with an alternative. > > I'm willing to lead such an effort. I just ask others to please have an > open mind. I absolutely do understand the need for the SIP world to have = an > easy API they can use for SDP. But I also know SDP as an primary surface > API is making anything beyond a basic calling a requirement to mangle SDP > as a mechanism to control and obtain properties from an underlying > media/RTC engine. > > I think there is a really good compromise. That is to provide an API that > will adhere to the security policies needed (e.g. respects the need to > require ICE establishment), but provides a simple shim API similar to wha= t > people already have with SDP but not be required to use for those who wan= t > to a more direct approach. > > There's no need to "burn" the entire thing to the ground and start over > and that is _not_ my desire. > > This WebRTC thing must succeed but I can't imagine the W3C accepting our > proposal for mangling SDP as a primary surface API to do common edge case > scenarios. WIth an alternative proposal that satisfies both camps, I > believe they could accept and we can stop the anit-SDP crowd grumblings > once and for all. > > To that end I'm going to write two drafts: > draft-raymond-webrtc-js-object-api-rationale-00 (to explain requirements, > philosophy, methodology, benefits/pitfalls, use cases that are > difficult/impossible with SDP+O/A) > draft-raymond-webrtc-js-object-api-00 (to outline the actual API) > > Plus, I'll produce a shim on top of whatever API that will allow the SDP > folks to have a simple SDP based API similar to what exists now but is > entirely written in JavaScript to prove that this can be done. > > I really want a viable solutions for all interested in having a really > good proposal API to ultimately become accepted by the W3C. > > If anyone has anything I should add to either of these drafts or wants to > be involved, please contact me. > > -Robin > > > Christer Holmberg > 20 June, 2013 12:55 AM > Hi, > > > At the virtual interim, the Plan A and Plan B folks were asked to sit dow= n > and try to come up with a compromise "Plan AB" solution. > > I guess it would be good if people that don't want SDP could try to come > up with a compromise "CU No Plan" solution :) > > Regards, > > Christer > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > -- > I=F1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d044288cc9751a804df9dc578 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 on this as well. We will provide a service which will connect something = that implements this draft to public PSTN/SIP
    _______= ______
    Roman Shpount


    On Thu, Jun 20, 2013 at 6:44 PM, Bossiel= thioriguel <bossiel@yahoo.fr> wrote:
    +1 for SDP ...but we (Doubango Telecom) would provide a= gateway to SIP/IMS world for any such draft as proof of concept.
    I've seen on many posts on msdn blog that it's easy to interop wi= th SIP using CU-RTC-WEB but haven't seen any demo.

    De=A0: I=F1aki Baz Castillo <ibc@aliax.net>
    =C0=A0: Robin Raymond <robin@hookflash.com>
    Cc=A0: "rtcweb@ietf.org" <rtcweb@ietf.org>
    = Envoy=E9 le : Jeudi 20 juin = 2013 23h27
    Objet=A0: Re: [rtcweb] WebR= TC JS object API with SDP shim option

    IMHO this is the way to go, something t= hat will make feasible to build any *future* protocol that just relies in R= TP but not on SDP O/A.

    +1


    2013/6/20 Robin Raymond <robin@hookflash.com>

    You are right. It's time for those of us who are begging for an=20 alternative to SDP to come up with an alternative.

    I'm willing to lead such an effort. I just ask others to please have an= =20 open mind. I absolutely do understand the need for the SIP world to have an easy API they can use for SDP. But I also know SDP as an primary=20 surface API is making anything beyond a basic calling a requirement to=20 mangle SDP as a mechanism to control and obtain properties from an=20 underlying media/RTC engine.

    I think there is a really good compromise. That is to provide an API=20 that will adhere to the security policies needed (e.g. respects the need to require ICE establishment), but provides a simple shim API similar=20 to what people already have with SDP but not be required to use for=20 those who want to a more direct approach.

    There's no need to "burn" the entire thing to the ground and = start over=20 and that is _not_ my desire.

    This WebRTC thing must succeed but I can't imagine the W3C accepting ou= r proposal for mangling SDP as a primary surface API to do common edge=20 case scenarios. WIth an alternative proposal that satisfies both camps, I believe they could accept and we can stop the anit-SDP crowd grumblings once and for all.

    To that end I'm going to write two drafts:
    draft-raymond-webrtc-js-object-api-rationale-00 (to explain=20 requirements, philosophy, methodology, benefits/pitfalls, use cases that are difficult/impossible with SDP+O/A)
    draft-raymond-webrtc-js-object-api-00 (to outline the actual API)

    Plus, I'll produce a shim on top of whatever API that will allow the SD= P folks to have a simple SDP based API similar to what exists now but is=20 entirely written in JavaScript to prove that this can be done.

    I really want a viable solutions for all interested in having a really=20 good proposal API to ultimately become accepted by the W3C.

    If anyone has anything I should add to either of these drafts or wants=20 to be involved, please contact me.

    -Robin


    =20 20 June, 2013=20 12:55 AM
    Hi,<= br>

    At the virtual interim, the Plan A and Plan B folks were asked to sit down and try to come up with a compromise "Plan AB" solution.

    = I guess it would be good if people that don't want SDP could try to come up=20 with a compromise "CU No Plan" solution :)

    Regards,
    Christer


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




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

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



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


    --f46d044288cc9751a804df9dc578-- --f46d044288cc9751ab04df9dc579 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: <1.3787650210@web171302.mail.ir2.yahoo.com> X-Attachment-Id: 881edcabd4a75f4f_0.0.1.1 /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQECAQEB AQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAARCAAZABkDAREA AhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUKBwAAAAAAAAACAQME BQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAAAAAAAAAAAAADAAEEAv/E ACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oADAMBAAIRAxEAPwDuEt+gW/UL et6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJVIl7eXLCaZIGwBl3TY8epPx2+jy2 ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJ Ew/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx+a69/JSf9alIlste0VzaNpeFrcT9KKymotyi aZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mRUfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRD nu5azS8miKqjOTVkKqS/psG37fo1Fbabeg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GA cpOwBeN+U8/IkGbsiS8b7ryogmbzhbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH 4hPOI0DkjZtaJtFxuVEbIUUiyeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJ nYn9dnAQWl722p4ot37yzqnlfp6FrqbwawG8/9k= --f46d044288cc9751ab04df9dc579-- From roman@telurix.com Thu Jun 20 15:58:35 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D72921F9A80 for ; Thu, 20 Jun 2013 15:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IF0+L3bcjdqb for ; Thu, 20 Jun 2013 15:58:33 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 443A921F9A74 for ; Thu, 20 Jun 2013 15:58:25 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so71805wiv.7 for ; Thu, 20 Jun 2013 15:58:21 -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=+KABUKOZNNo4bQIEE9rxE2vLeqQkdVHVPabju0l6H+k=; b=p4uvf7r4bKno5171VWKbBjMolFBrdjDC0lfy7hmMVCz/hK1UifxYfWsypHVx/yWQq3 7lfuQysEE5Be02cZ0q5OfNZyFEgtReXVffEs396u1xS2ONfUIFQSxSYcSkzyTwLXWCFQ W4FhFMUQn+a43RUCYTjjmLFf+tafv5xVJ3GYEudAfUagPzjwBrybUw94yxcOgTBCE0/2 sSXfWEv0y/ObONB0VxxhSFq+RIxFnadd3Ma26hecBTl+h97IoxVYBjfVIyBrDxfWfipF /Yco2mTeLZdcXpxb/jiYY+pTETTm8oiLo+oxmPqmEHaxN4idIVUiJ1gxLIYsAjwL+vZ5 lUCg== X-Received: by 10.180.36.107 with SMTP id p11mr986004wij.31.1371769101230; Thu, 20 Jun 2013 15:58:21 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [2a00:1450:400c:c05::233]) by mx.google.com with ESMTPSA id x13sm3601344wib.3.2013.06.20.15.58.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 15:58:20 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hj3so68666wib.6 for ; Thu, 20 Jun 2013 15:58:19 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.9.212 with SMTP id c20mr478488wib.65.1371769099259; Thu, 20 Jun 2013 15:58:19 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Thu, 20 Jun 2013 15:58:19 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115D2E8D@MCHP04MSX.global-ad.net> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115D2D76@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF115D2E8D@MCHP04MSX.global-ad.net> Date: Thu, 20 Jun 2013 18:58:19 -0400 Message-ID: From: Roman Shpount To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=001a11c1879ce017e604df9de1d1 X-Gm-Message-State: ALoCoQmbWt1JBf3F7G8nlxf70OxuUtPYybhsR8zzaIdZ7ArBz2FZdE7GJY1V6ZMcQuhbSF9B3C85 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 22:58:35 -0000 --001a11c1879ce017e604df9de1d1 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 20, 2013 at 5:25 PM, Hutton, Andrew < andrew.hutton@siemens-enterprise.com> wrote: > Using SRTP is always more secure than using plain RTP but again I think > the problem to be solved is how the user is notified about the level of > risk. > > > Please explain how SRTP is more secure the plain RTP when communicating with plain HTTP server? I can decode either from a simple packet capture. After all, you did say always... _____________ Roman Shpount --001a11c1879ce017e604df9de1d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Thu, Jun 20, 2013 at 5:25 PM, Hutton, And= rew <andrew.hutton@siemens-enterprise.com> wrote:

    Using SRTP is always more secure than using = plain RTP but again I think the problem to be solved is how the user is not= ified about the level of risk.



    Please explain how SRTP is more secure the plain RTP when communicating wi= th plain HTTP server? I can decode either from a simple packet capture. Aft= er all, you did say always...
    _____________
    Roman Shpount
    =A0
    --001a11c1879ce017e604df9de1d1-- From rlb@ipv.sx Thu Jun 20 16:09:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818AC21F9CD0 for ; Thu, 20 Jun 2013 16:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.371 X-Spam-Level: * X-Spam-Status: No, score=1.371 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7heVPCrUjwK for ; Thu, 20 Jun 2013 16:09:17 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1F221F9CB7 for ; Thu, 20 Jun 2013 16:09:17 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id f4so8607439oah.21 for ; Thu, 20 Jun 2013 16:09:16 -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:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=T6Kt1RXd9ONcFSItjTYsgQ/RDe/ION13+P6MgBcFzJI=; b=eWKjZJL4p+unVx3QXGURGChIYkZm9LA/4q+o0fOogzTu06z9ZLax64QZBmUj47Ajci o66mCq4RUnT5WSQf3zCBisn9F/hL6TN3+94uJMCgNeb98jxzYQ2BtgI+N5SvUtRN8xGw b5Ycsdfw37UjjzBwD0E1l+jvVXK2LWiRNhvC2RVxCY+fLwlzJNkF2tF+p/JCOaNZS8pW sePV+OYmhtPQRIh09Dm4QwIC7GJV74l/3uWWrePCDbOjDMSQJUu4iRw36fsN0TMnBomL nnvU5JxuV8zf7+nkz4PtuyV+GlPG3NKt56/6OjifL2HzPJKiIQVOA9RNJX8NLncmII4P zxCQ== MIME-Version: 1.0 X-Received: by 10.182.60.2 with SMTP id d2mr2459325obr.75.1371769756846; Thu, 20 Jun 2013 16:09:16 -0700 (PDT) Received: by 10.60.26.135 with HTTP; Thu, 20 Jun 2013 16:09:16 -0700 (PDT) X-Originating-IP: [108.18.40.68] In-Reply-To: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115D2D76@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF115D2E8D@MCHP04MSX.global-ad.net> Date: Thu, 20 Jun 2013 19:09:16 -0400 Message-ID: From: Richard Barnes To: Roman Shpount Content-Type: multipart/alternative; boundary=089e015387dc12259b04df9e09bb X-Gm-Message-State: ALoCoQnlMYTytu/Qr42ti6nCC3BWLYww24lJc3NEobABNh/P+Bp5OsPFsbnA/hagJMqgYEfbw+08 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 23:09:22 -0000 --089e015387dc12259b04df9e09bb Content-Type: text/plain; charset=ISO-8859-1 The path from end to end media path is not the same as the path from end to middle (signaling path). SRTP in general (without assumptions on key management) protects against a passive attacker that is on the media path but not on the signaling path. If, in addition, the browser does not expose media keys to JS (as is required for SDES), then even an active attacker who hijacks the HTTP connection to inject scripts cannot access the media keys. --Richard On Thu, Jun 20, 2013 at 6:58 PM, Roman Shpount wrote: > > On Thu, Jun 20, 2013 at 5:25 PM, Hutton, Andrew < > andrew.hutton@siemens-enterprise.com> wrote: > >> Using SRTP is always more secure than using plain RTP but again I think >> the problem to be solved is how the user is notified about the level of >> risk. >> >> >> > Please explain how SRTP is more secure the plain RTP when communicating > with plain HTTP server? I can decode either from a simple packet capture. > After all, you did say always... > _____________ > Roman Shpount > > --089e015387dc12259b04df9e09bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    The path from end to end media path is not the same as the= path from end to middle (signaling path). =A0SRTP in general (without assu= mptions on key management) protects against a passive=A0attacker=A0that is = on the media path but not on the signaling path.

    If, in addition, the browser does not expose media keys to J= S (as is required for SDES), then even an active attacker who hijacks the H= TTP connection to inject scripts cannot access the media keys. =A0

    --Richard

    =A0


    On Thu, Jun 20, 2013 at= 6:58 PM, Roman Shpount <roman@telurix.com> wrote:

    On Thu, Jun 20, 2013 at 5:25 PM, Hutton, Andrew <= a= ndrew.hutton@siemens-enterprise.com> wrote:

    Using SRTP is always more secure than using = plain RTP but again I think the problem to be solved is how the user is not= ified about the level of risk.



    Please explain how SRTP is more secure the plain RTP when communicat= ing with plain HTTP server? I can decode either from a simple packet captur= e. After all, you did say always...
    _____________
    Roman = Shpount
    =A0

    --089e015387dc12259b04df9e09bb-- From ibc@aliax.net Thu Jun 20 16:24:36 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF4121E80AD for ; Thu, 20 Jun 2013 16:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vKM5Zpj2yQr for ; Thu, 20 Jun 2013 16:24:35 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8006F21E80B9 for ; Thu, 20 Jun 2013 16:24:29 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id n1so4123326qcx.22 for ; Thu, 20 Jun 2013 16:24: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=u/kREXIGyrA/uUnwxWew2c/M/zpwgGiIvd5MTZg7ulg=; b=bcMP26j9nQVqQvA/SJM/qlo5geZNfld6nHetiJZhlskq/rzz38ffs2p09tdy5w72t3 jGTYwGEo5c5PUChxZA4aTpyDdI1a83xzKvc9By7O9KJY1Gnw/I310626ooZsNdmhQRvu LlIu/A+PqC+/PdQPCkFSzZUYpg3x+tUHYTHPwchFRYoQwSuhpNPnQt/vXruKDdNDEBhN acMMLMGh7skoAivAmo3ofD14VGiM0QYvUyjpBrZKJ4WJYxh7LKifypXcV/83FBjTdIRn mCChkmGgESuNxjK8DNEc55FkPJ8wH0wzTs2CsZ8bbO+ahh8g6RcZw85p4uOuKGe8hYhY rhIQ== X-Received: by 10.229.21.201 with SMTP id k9mr577733qcb.91.1371770669406; Thu, 20 Jun 2013 16:24:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Thu, 20 Jun 2013 16:24:09 -0700 (PDT) In-Reply-To: <51C38356.3020402@jitsi.org> References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 21 Jun 2013 01:24:09 +0200 Message-ID: To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl+3S0JYSO0WOCCKriLtX5RXFGcQSIQC5+Bvywgq7kLpztzXHNY9oTX65R3NNHpTeLv3jJV Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 23:24:36 -0000 2013/6/21 Emil Ivov : > > On 20.06.13, 23:49, I=C3=B1aki Baz Castillo wrote: >> >> In JsSIP we are getting frustrated trying to implement the "hold" / >> "unhold" feature because it requires SDP parsing and mangling. Sending >> a re-INVITE with a modified SDP (now with a video track enabled) seems >> to work (after lot of pain) but we still miss a reliable API to know >> what the new SDP means. Instead we need to parse the SDP to detect >> global (or per m=3D) line attributes like "a=3Dinactive" or "a=3Dsendonl= y" >> etc etc. It's really painful. > > > I am having a problem following what you are trying to achieve here. In > JsSIP you seem to be going for a full SIP implementation in the browser. = If > this is true and if this WG decides to remove SDP from the API surface, t= hen > you would need to completely parse SDP in the JS and then convert it into > API calls. Similarly, when creating offers and answers you would need to > construct SDP all by yourself. And we will do it very happily because then we will know what *exactly* we are sending on-the-wire. > So I am not sure why the SDP parsing in the current situation is so much = of > a blocker for your use case. Because regardless I am a SIP-guy, I understand that the main mission of WebRTC is to provide realtime communications *for* the WWW, and not to enable a new interface for like-telephony-bussines. Today I'm doing SIP. Tomorrow I may be doing [[put_here_a_future_RTC_protocol_not_based_on_SDP]] and then I don't want to be constrained by decisions made today that force any future RTC protocol to deal with SDP O/A model. :) >> BTW I don't know wheter you support PlanA, PlanB or NoPlan, but I did >> a question (in this case about NoPlan) for which I got no response, >> and honestly I would like to see it replied regardless the solution >> uses PlanA, PlanB or NoPlan model: >> >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07871.html >> > The other option would be indeed to do the same thing in JS. I believe th= is > is JsSIP's use case. In that case however, regardless of whether you choo= se > Plan A, Plan B, No Plan or CU-RTC-Web, you will inevitably be exposed to = a > fair amount of complexity, parsing and JS magic. > > You are, after all, building a SIP stack. Yes, but JsSIP creates its own SIP messages to be sent in the wire, so we have full control over *what* we create and send. Those SIP messages are not provided by the WebRTC API. But for the SDP component, JsSIP retreives a SDP blob string from the PC. > > In the above mail you also say: > >> Another example: >> >> * I am a powerful SIP conference server which properly implements >> WebRTC. I initiate a call to 5 users (running JS SIP app in their >> browsers). The initial INVITE has SSRC/MSID fields in the SDP >> identifying all the participants, am I right? > > > No, with No Plan there are no SSRCs and MSIDs in the SDP that comes from = the > browser. OK >> * Later, during the conference, I call to another 6th participant and >> enter him into the conference, so I need to send a re-INVITE to every >> participant with a modified version of the SDP (note that this is SIP >> protocol, so I need to use SIP messages to carry the new info about >> SSRC/MSID and so on). > > > That's the thing. You don't need that. In Jitsi we do exactly this operat= ion > with no Offer/Answer signalling. RTP carries enough information to proces= s > streams and we use upper layer signalling (4575) for things such as mappi= ng > SSRCs to users and announcing current participant list. That is much better than Plan A and Plan B. BTW: What would happen in NoPlan if the remote (i.e. a SIP gateway/endpoing) sends you a re-INVITE for "hold" purposes and you pass the SDP to your PC? or you should not pass the SDP to your PC? and if so, what about if the SDP contains updated ICE candidates due to remote peer network mobility? Thanks a lot for your response. -- I=C3=B1aki Baz Castillo From roman@telurix.com Thu Jun 20 16:31:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F0421F9A70 for ; Thu, 20 Jun 2013 16:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljPaoOVHL+Yu for ; Thu, 20 Jun 2013 16:31:53 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5649C21F9A64 for ; Thu, 20 Jun 2013 16:31:53 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so87195wib.2 for ; Thu, 20 Jun 2013 16:31:52 -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=NgM/0NgVNRybA4Sx/lSVTIJi/Rax0cr1FaYqTUr+df4=; b=Z+lXSNHD8jZyWTl6CWn1RQjTCroJgMqK3cnfTUoNj8AIDIj2aTmeDXRSX2Y5sabU7R 1ECVEscZsGZ27x9HDY8sE5t8Uh67ejzPCyxBdMbu00GlXwrOrJ23wlBE/X1pofzRk3+9 P3Q37fHd78vZ1wqd4TszPOwlzuFQWEOdLe9z1WERccmPwxFUHkG8jMgnVBGRYa7NetCZ +Yo2UCxD8t/exqhR6qb+wKMaCzPvJlglUftxcnyEk8XAzPBbPyWT1FU16UVEfYJrs7Sa t+aRMshnvZu1b27MhUX2ICo8hDzKW8nKtwIgEFsQyZk94qceylnHqf0bd2zG7rrAL1qE JKbg== X-Received: by 10.194.108.73 with SMTP id hi9mr2256075wjb.85.1371771112516; Thu, 20 Jun 2013 16:31:52 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [2a00:1450:400c:c03::233]) by mx.google.com with ESMTPSA id w4sm2407815wia.9.2013.06.20.16.31.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 16:31:51 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so5888479wes.38 for ; Thu, 20 Jun 2013 16:31:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.173.71 with SMTP id bi7mr7349852wjc.2.1371771110626; Thu, 20 Jun 2013 16:31:50 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Thu, 20 Jun 2013 16:31:50 -0700 (PDT) In-Reply-To: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115D2D76@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF115D2E8D@MCHP04MSX.global-ad.net> Date: Thu, 20 Jun 2013 19:31:50 -0400 Message-ID: From: Roman Shpount To: Richard Barnes Content-Type: multipart/alternative; boundary=089e0112cf9ac31c4004df9e59bf X-Gm-Message-State: ALoCoQk3kx4yr3Drydmb5uXYTdDqeVzoHwRw5yBVuDnVEFdUYo/c0Uz7VewdDqF3knHNHZr/y63G Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 23:31:54 -0000 --089e0112cf9ac31c4004df9e59bf Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 20, 2013 at 7:09 PM, Richard Barnes wrote: > The path from end to end media path is not the same as the path from end > to middle (signaling path). SRTP in general (without assumptions on key > management) protects against a passive attacker that is on the media path > but not on the signaling path. > My point is that if I can intercept all the traffic from the end point and the end point uses HTTP to send the keys I can decode everything sent over SRTP. This means we have one very insecure point. The whole system is as secure as the least secure portion of it. Thus SRTP with plain HTTP is exactly as secure as plain RTP (ie not at all). > If, in addition, the browser does not expose media keys to JS (as is > required for SDES), then even an active attacker who hijacks the HTTP > connection to inject scripts cannot access the media keys DTLS is only slightly more secure with plain HTTP and no identity, since I would need to hijack the HTTP session and decode/encode media. A bit more work but marginally so. Following this logic, should not this group outlaw WebRTC sessions from not HTTPS sources? _____________ Roman Shpount --089e0112cf9ac31c4004df9e59bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Thu, Jun 20, 2013 at 7:09 PM, = Richard Barnes <rlb@ipv.sx> wrote:
    The path from end to end media path is not the same as the= path from end to middle (signaling path). =A0SRTP in general (without assu= mptions on key management) protects against a passive=A0attacker=A0that is = on the media path but not on the signaling path.

    My point is that if I can intercept all th= e traffic from the end point and the end point uses HTTP to send the keys I= can decode everything sent over SRTP. This means we have one very insecure= point. The whole system is as secure as the least secure portion of it. Th= us SRTP with plain HTTP is exactly as secure as plain RTP (ie not at all).<= /div>
    =A0
    If, in addition, the= browser does not expose media keys to JS (as is required for SDES), then e= ven an active attacker who hijacks the HTTP connection to inject scripts ca= nnot access the media keys

    DTLS is only slightly more secure with plain HTTP= and no identity, since I would need to hijack the HTTP session and decode/= encode media. A bit more work but marginally so.

    Following this logic, should not this group outlaw WebRTC sessions from not= HTTPS sources?
    _____________
    Roman Shpount
    =A0
    --089e0112cf9ac31c4004df9e59bf-- From martin.thomson@gmail.com Thu Jun 20 16:36:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C99F21F9FC0 for ; Thu, 20 Jun 2013 16:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaoJsI5CnHkZ for ; Thu, 20 Jun 2013 16:36:38 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 729BE21F9F9E for ; Thu, 20 Jun 2013 16:36:38 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so6073825wgh.12 for ; Thu, 20 Jun 2013 16:36: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=J+hjIkJ+xicpY7dfg3MSiBxuhr71p71AB3CWL/jitZI=; b=yl3XoZ76yZ4c7rSNhsswHR3AHTZQsiIcc6GWbt2WQbmMRcvLfBI7PaQLg9Oi+GyKeh BksGlsTeKjYmmA0M0o2m3V2wKld2XtItupKRA5sChz3Y8woPKnVHNX/ZIyzhrbBOrXpD CMYg6hU8QGtVtuJBcj2CPrOjcR7VQTtkNSfWytxolhvq8vFIWld3SweEItW9/1QHNiP1 PbKDEDs6rcm6BHJRsqfgA1NdBpryWGItLVTVU1TXg3eSM/SqgDPvKSo8DFMzqNpxM1kY pOe+nu0k3AFEKu+GYiopbLXoJMAkMw1GhlEw1Ox6ZPdfNdFT/PV0Rh2WSJyTh2I5ByOP Nbew== MIME-Version: 1.0 X-Received: by 10.180.20.46 with SMTP id k14mr1091506wie.14.1371771397554; Thu, 20 Jun 2013 16:36:37 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 20 Jun 2013 16:36:37 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115D2E8D@MCHP04MSX.global-ad.net> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115D2D76@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF115D2E8D@MCHP04MSX.global-ad.net> Date: Thu, 20 Jun 2013 16:36:37 -0700 Message-ID: From: Martin Thomson To: "Hutton, Andrew" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 23:36:39 -0000 On 20 June 2013 14:25, Hutton, Andrew wrote: > Using SRTP is always more secure than using plain RTP but again I think the > problem to be solved is how the user is notified about the level of risk. I'm fairly sure that the levels of trust can be very easily enumerated: Do you trust the site? (i.e., default access level on getUserMedia or a session that uses SDES) Do you trust some other guy? Where the identity of the other guy is provided. (peerIdentity/noaccess constraint on getUserMedia, and DTLS-SRTP, and - if it isn't a domain name - an identity provider) Given that either default access levels on gUM or use of SDES to be equivalent, and I think that they are to a reasonable approximation, then the security story for SDES isn't that weak. From martin.thomson@gmail.com Thu Jun 20 16:41:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCC721F9B16 for ; Thu, 20 Jun 2013 16:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AgeFN-T6y5u for ; Thu, 20 Jun 2013 16:41:08 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7551821F9B0D for ; Thu, 20 Jun 2013 16:41:08 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so122376wgg.4 for ; Thu, 20 Jun 2013 16:41: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=tG1msRTNzP55FqQH9kfIAyTPsUQpOVi2KUbWmTf7TIs=; b=TE6pAVK2OVjYRQiS7hVx8oE+89KK7qsNeSWfcGNY13YHg3T2PrJNCBLvV5jh23Wixr +gY567AKSFrg1p1b2aaEb8jqVt2jgWG/YMxvNqiCaalhwW6QITS5Rt+7ntzBl1N93wM1 +F8sPzHcx3HEl6kPMd2QgWlGzCy6mA1CtEvRAhw/lUIHWE2YP72hduR4g5VjZ4/kBFUV Uv1TS6miRUoz8HcNtDhKfhkJOcS56jGqUR+nNxS9dXB4bSrGpThlpCW+TMW13VnRsjgr yiE7fWp5vGSVACoDBNOFTgImZyc52yiPle4PkMJELGJnq37LHd/zjsEGPDdpkhF50EtV Xb8w== MIME-Version: 1.0 X-Received: by 10.180.87.162 with SMTP id az2mr1113032wib.10.1371771667474; Thu, 20 Jun 2013 16:41:07 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 20 Jun 2013 16:41:07 -0700 (PDT) In-Reply-To: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115D2D76@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF115D2E8D@MCHP04MSX.global-ad.net> Date: Thu, 20 Jun 2013 16:41:07 -0700 Message-ID: From: Martin Thomson To: Richard Barnes Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 23:41:09 -0000 On 20 June 2013 16:09, Richard Barnes wrote: > If, in addition, the browser does not expose media keys to JS (as is > required for SDES), then even an active attacker who hijacks the HTTP > connection to inject scripts cannot access the media keys. That's only true if that attacker were not able to also set the keys. I haven't had anyone explain what the API for EKT would look like, but one possibility would permit that attacker to set keys (i.e., keying would be write-only). That possibility would be attractive from a symmetry perspective - the non-browser can insert new keying, why should the browser be prevented from doing so - but I can see how implementation of EKT does not strictly require that possibility. That would preclude some interesting browser-API-based scenarios though. From hadriel.kaplan@oracle.com Thu Jun 20 17:33:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D0521E80DC for ; Thu, 20 Jun 2013 17:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSJj4KjELlaf for ; Thu, 20 Jun 2013 17:33:21 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE2B11E8133 for ; Thu, 20 Jun 2013 17:33:21 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5L0XJi0017967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 00:33:20 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5L0XIML004129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 00:33:19 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5L0XHco014384; Fri, 21 Jun 2013 00:33:18 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-166-188.vpn.oracle.com (/10.154.166.188) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jun 2013 17:33:17 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Thu, 20 Jun 2013 20:33:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <34FBF882-8820-4C95-9B26-E6C60CFD993D@oracle.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115D2D76@MCHP04MSX.global-ad.net> To: Roman Shpount X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 00:33:28 -0000 On Jun 20, 2013, at 4:58 PM, Roman Shpount wrote: > Not to play devil's advocate, but how is it any different then = arguments to support plain RTP? All the same things apply to RTP. On top = of this SRTP is no more secure then plain RTP when communicating with a = server over plain HTTP or communicating with untrusted server over = HTTPS. If we decided that RTP is unacceptable from security point of = view, then how is SRTP acceptable? I'm operating under the assumption we would only allow the Browser to = use SDES if and only if it is also using HTTPS to the web server. And = I'm operating under the assumption that all browsers still MUST offer = DTLS-SRTP, and choose it instead SDES if they receive such an offer. =20 In such a model, any two browsers do DTLS-SRTP to each other unless the = web-server/JS is malicious. Ergo, unless the web-server/JS is = malicious, only calls to/from a gateway use an SDES key. The SDES key = isn't sniffable on the browser-server HTTPS portion. Obviously it's = sniffable beyond the web server, if it gets sent in the clear somewhere = else. But we know that will also happen even with DTLS-SRTP, because = the gateway will terminate DTLS-SRTP and use SDES or plain RTP on the = other side. So we're not losing anything. So... in theory the danger is relegated to the malicious web-server = case. But a malicious web server can get your media anyway, even with = DTLS-SRTP, because it can simply direct you to its own "gateway" to = terminate DTLS-SRTP and record the media. There is no practical way to = prevent a malicious web-server from getting your media, no matter what = we do, for common every-day users. Frankly with a malicious web server you're screwed in so many other ways = anyway, that making it just slightly harder for it to get your media is = like putting on a scuba drysuit when jumping into a pool of molten lava. = Yes, you'll live for some fraction of a millisecond longer. And then = what? -hadriel From hadriel.kaplan@oracle.com Thu Jun 20 18:11:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1196D21E80F8 for ; Thu, 20 Jun 2013 18:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wyFjKBJMzzu for ; Thu, 20 Jun 2013 18:11:33 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD6321E80E6 for ; Thu, 20 Jun 2013 18:11:32 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5L1BSc3009461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 01:11:29 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5L1BRPw023590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 01:11:27 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5L1BRFf004736; Fri, 21 Jun 2013 01:11:27 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-166-188.vpn.oracle.com (/10.154.166.188) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jun 2013 18:11:26 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Thu, 20 Jun 2013 21:11:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> To: Richard Barnes X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 01:11:52 -0000 On Jun 20, 2013, at 6:24 PM, Richard Barnes wrote: > It's more secure in the sense that it makes a malicious web server do = more work: It forces the web server to act as the PBX and terminate = DTLS, instead of just pulling the key out of the SDP and decrypting = media. So the browser user is (incrementally) better protected against = the malicious web server. Uh huh. So, like, the only people who could afford to do that and would = want to do that would be criminals, drug dealers, mobsters, casinos, = news organizations, political parties, and governments then? Phew! And = here I was being worried. But wait a minute... I was under the distinct impression from people in = this group that doing DTLS-SRTP termination on the gateways was no big = deal for "modern" servers... that it was so cheap and trivial that your = cell phone could do it for umpteen streams... that we shouldn't be = worried about the overhead of it whatsoever. Surely you can't be = telling me that it's at all difficult for someone running a malicious = web site to do it?!? ;) > It's more secure in the sense that JS can't access the key, so an = injected script can't grab the key and exfiltrate it. So the browser = user is better protected against XSS risks. This part I'd like to understand better. Can you explain it? =20 If a Browser cannot determine what server the JS being executed for = WebRTC API calls/callbacks came from, or cannot tell if it came from one = over HTTPS in particular, then using SDES might be a real problem. I = was under the impression browsers did know those things (or at least = that they're theoretically supposed to, ignoring that there are "bugs" = here and there). > It's more secure in the sense that SDES has no end-to-end = authentication [1], so implementing SDES creates bid-down attacks. If = an attacker can't get a valid identity, he just claims not to support = DTLS-SRTP. So the browser user is better protected against bid-down = attacks by remote users (e.g., the malicious web server's PBX). This is just another symptom of talking to a malicious web server, and = basically a repeat of the argument that DTLS-EKT is "more secure" = because a malicious web server has to do a little more work to steal = everything. It's like being stuck in a big cage with a man-eating lion = and deciding to run around in circles in the hopes the lion isn't going = to chase you. If he's hungry at all, you're dead; chasing you down is = not sufficiently more difficult for him to stay hungry. -hadriel From rlb@ipv.sx Thu Jun 20 19:14:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8BF1F0D3D for ; Thu, 20 Jun 2013 19:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrDGaOX8IQ27 for ; Thu, 20 Jun 2013 19:14:23 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 28A241F0D38 for ; Thu, 20 Jun 2013 19:14:23 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va7so7998163obc.13 for ; Thu, 20 Jun 2013 19:14:22 -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:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=1J3YpGUl0W3XSH5Rx3rmDA+1YZux5/yYGM3GqQp9e3c=; b=eh4f7nNmHh18Fn42Hk05ovyB3DBL06iuUUyMY4Tmg7/YHy1mP0ZumNy4tYloGSbYsm iH2wFnvncOVvW9npz5SdLoed/5m6rnldcnDkMBqUZIe4XqcIW+I8qPF80osA8Cv+YyTe Oj1VgkwHrwBDJyq0+cQ/n2y6Ef8xlijLJjQAJENa7T2AZoq3BxxWXmS7sX9CX0RbHHvC jEECKPw/eFRO0x2SOMULUFIdqh9VPeExMPs+Hnf53z881b96LLhTGcmtFyo6vxI+LIou flHNT8bOhwhP+xzV/5USSVqDwIPqe0H8yLBRxKkhiNqYGD4gbxJz0+ZMe8hEgKHwMLq9 8QvA== MIME-Version: 1.0 X-Received: by 10.60.95.136 with SMTP id dk8mr5803895oeb.4.1371780862699; Thu, 20 Jun 2013 19:14:22 -0700 (PDT) Received: by 10.60.26.135 with HTTP; Thu, 20 Jun 2013 19:14:22 -0700 (PDT) X-Originating-IP: [128.89.255.40] In-Reply-To: <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> Date: Thu, 20 Jun 2013 22:14:22 -0400 Message-ID: From: Richard Barnes To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=089e0112caf007fe8504dfa09f14 X-Gm-Message-State: ALoCoQkLWL34l2KWOz678TTpCVXJWfseycd3OLt0IIDrl8+kPCv903HWbE1q2SwAt1nmfRC88Fp5 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 02:14:27 -0000 --089e0112caf007fe8504dfa09f14 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 20, 2013 at 9:11 PM, Hadriel Kaplan wrote: > > On Jun 20, 2013, at 6:24 PM, Richard Barnes wrote: > > > It's more secure in the sense that it makes a malicious web server do > more work: It forces the web server to act as the PBX and terminate DTLS, > instead of just pulling the key out of the SDP and decrypting media. So > the browser user is (incrementally) better protected against the malicious > web server. > > Uh huh. So, like, the only people who could afford to do that and would > want to do that would be criminals, drug dealers, mobsters, casinos, news > organizations, political parties, and governments then? Phew! And here I > was being worried. > > But wait a minute... I was under the distinct impression from people in > this group that doing DTLS-SRTP termination on the gateways was no big deal > for "modern" servers... that it was so cheap and trivial that your cell > phone could do it for umpteen streams... that we shouldn't be worried about > the overhead of it whatsoever. Surely you can't be telling me that it's at > all difficult for someone running a malicious web site to do it?!? > ;) Look, I said it was "incremental", right? :) At the very least, it keeps out the script kiddies. If you compromise my web site, you have to have some other resources to compromise the users' voice sessions; you can't just do it from the web server you've pwned. You might not be up against a tiger every time; sometimes, it's just a house cat. > > It's more secure in the sense that JS can't access the key, so an > injected script can't grab the key and exfiltrate it. So the browser user > is better protected against XSS risks. > > This part I'd like to understand better. Can you explain it? > If a Browser cannot determine what server the JS being executed for WebRTC > API calls/callbacks came from, or cannot tell if it came from one over > HTTPS in particular, then using SDES might be a real problem. I was under > the impression browsers did know those things (or at least that they're > theoretically supposed to, ignoring that there are "bugs" here and there). As with many things in the web security model, the answer is "It's complicated". The wikipedia article on XSS is pretty good. The upshot is that your typical web page gets cobbled together out of many pieces, often from different domains. Scripts from multiple sources get imported into the overall security context of the page. This composition can happen deliberately (e.g., mashups, JS libraries) or maliciously (XSS). Let me provide an example of each: 1. Suppose I use jQuery to do pretty layout on my page. There's nothing that actually constrains jQuery to only do layout. If jQuery is out to get me, it could do something like overwrite window.PeerConnection, so that all of the page's WebRTC calls go through the jQuery library and are subject to its control. So if the PeerConnection API exposes keys, jQuery can steal them. 2. Suppose the overall page is loaded over HTTPS, but one of the scripts is loaded over HTTP. Then the overall security context for the page is HTTPS, but if an attacker can hijack that HTTP load to introduce a script, in which case he can do the same bad stuff that jQuery could in the above example. (This is why we have the following sentence in draft-ietf-rtcweb-security-arch: "It is RECOMMENDED that browsers which allow active mixed content nevertheless disable RTCWEB functionality in mixed content settings." There are mitigations to a lot of these sorts of issues, but some are still being developed. And of course, there's no guarantee that a given site will follow all the best practices. So it seems sensible to limit the damage that an injected script can do. --Richard > > It's more secure in the sense that SDES has no end-to-end authentication > [1], so implementing SDES creates bid-down attacks. If an attacker can't > get a valid identity, he just claims not to support DTLS-SRTP. So the > browser user is better protected against bid-down attacks by remote users > (e.g., the malicious web server's PBX). > > This is just another symptom of talking to a malicious web server, and > basically a repeat of the argument that DTLS-EKT is "more secure" because a > malicious web server has to do a little more work to steal everything. > It's like being stuck in a big cage with a man-eating lion and deciding to > run around in circles in the hopes the lion isn't going to chase you. If > he's hungry at all, you're dead; chasing you down is not sufficiently more > difficult for him to stay hungry. > > -hadriel > > --089e0112caf007fe8504dfa09f14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Thu, Jun 20, 2013 at 9:11 PM, Hadriel Kaplan <hadriel.kaplan@oracle.com> wrote:

    On Jun 20, 2013, at 6:24 PM, Richard Barnes <rlb@ipv.sx> wrote:

    > It's more secure in the sense that it makes a malicious web server= do more work: It forces the web server to act as the PBX and terminate DTL= S, instead of just pulling the key out of the SDP and decrypting media. =A0= So the browser user is (incrementally) better protected against the malicio= us web server.

    Uh huh. =A0So, like, the only people who could afford to do that and = would want to do that would be criminals, drug dealers, mobsters, casinos, = news organizations, political parties, and governments then? =A0Phew! =A0An= d here I was being worried.

    But wait a minute... I was under the distinct impression from people in thi= s group that doing DTLS-SRTP termination on the gateways was no big deal fo= r "modern" servers... that it was so cheap and trivial that your = cell phone could do it for umpteen streams... that we shouldn't be worr= ied about the overhead of it whatsoever. =A0Surely you can't be telling= me that it's at all difficult for someone running a malicious web site= to do it?!?
    ;)

    Look, I said it was "incremental&qu= ot;, right? =A0:) =A0At the very least, it keeps out the script kiddies. = =A0 If you compromise my web site, you have to have some other resources to= compromise the users' voice sessions; you can't just do it from th= e web server you've pwned. =A0You might not be up against a tiger every= time; sometimes, it's just a house cat.

    =A0
    > It's more secure in the sense that JS can't access the key, so= an injected script can't grab the key and exfiltrate it. =A0So the bro= wser user is better protected against XSS risks.

    This part I'd like to understand better. =A0Can you explain it? If a Browser cannot determine what server the JS being executed for WebRTC = API calls/callbacks came from, or cannot tell if it came from one over HTTP= S in particular, then using SDES might be a real problem. =A0I was under th= e impression browsers did know those things (or at least that they're t= heoretically supposed to, ignoring that =A0there are "bugs" here = and there).

    As with many things in the web security model, the answ= er is "It's complicated". =A0The wikipedia article on XSS is = pretty good.
    <http://en.wikipedia.org/wiki/Cross-site_scripting>

    The upshot is that your typical web page gets cobbled t= ogether out of many pieces, often from different domains. =A0Scripts from m= ultiple sources get imported into the overall security context of the page.= =A0This composition can happen deliberately (e.g., mashups, JS libraries) = or maliciously (XSS). =A0Let me provide an example of each:

    1. Suppose I use jQuery to do pretty layout on my page.= =A0There's nothing that actually constrains jQuery to only do layout. = =A0If jQuery is out to get me, it could do something like overwrite window.= PeerConnection, so that all of the page's WebRTC calls go through the j= Query library and are subject to its control. =A0So if the PeerConnection A= PI exposes keys, jQuery can steal them.

    2. Suppose the overall page is loaded over HTTPS, but o= ne of the scripts is loaded over HTTP. =A0Then the overall security context= for the page is HTTPS, but if an attacker can hijack that HTTP load to int= roduce a script, in which case he can do the same bad stuff that jQuery cou= ld in the above example. =A0(This is why we have the following sentence in = draft-ietf-rtcweb-security-arch: "It is RECOMMENDED that browsers whic= h allow active mixed content nevertheless disable RTCWEB functionality in m= ixed content settings."

    There are mitigations to a lot of these sorts of issues= , but some are still being developed. =A0And of course, there's no guar= antee that a given site will follow all the best practices. =A0So it seems = sensible to limit the damage that an injected script can do.

    --Richard

    =A0
    > It's more secure in the sense that SDES has no end-to-end authenti= cation [1], so implementing SDES creates bid-down attacks. =A0If an attacke= r can't get a valid identity, he just claims not to support DTLS-SRTP. = =A0So the browser user is better protected against bid-down attacks by remo= te users (e.g., the malicious web server's PBX).

    This is just another symptom of talking to a malicious web server, an= d basically a repeat of the argument that DTLS-EKT is "more secure&quo= t; because a malicious web server has to do a little more work to steal eve= rything. =A0It's like being stuck in a big cage with a man-eating lion = and deciding to run around in circles in the hopes the lion isn't going= to chase you. =A0If he's hungry at all, you're dead; chasing you d= own is not sufficiently more difficult for him to stay hungry.

    -hadriel


    --089e0112caf007fe8504dfa09f14-- From rlb@ipv.sx Thu Jun 20 19:18:16 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E41821E80EB for ; Thu, 20 Jun 2013 19:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnMSbkUxx2nw for ; Thu, 20 Jun 2013 19:18:11 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 34C6521E80B0 for ; Thu, 20 Jun 2013 19:18:11 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id k7so8632719oag.23 for ; Thu, 20 Jun 2013 19:18:10 -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:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=1iYBgiBBOqHMu8m6Z7kBpmjpEpGdviCVt8TS045bA2g=; b=OS0xXxD6FEkZEdXYD3tnc7Wyv68Wo5bJ/PckrbhNmaVqBdLkv2/qLnOxgRmkISkH95 CJWxTLgL4XNOeC93699OqYAjj/y8ky7EpbPwnXCZ77E+Xd0nhnpb+IjPfvS2GgivKSDj wjwm0mOECJvKbLYJhWPruZm3BxpMzJsEvF8pe8JcScpLDltvnnHGFf7JrreLqISftm5W aQ1FPAKIBDwtgiS42yX8TDDG+WvU8pwp2UXv4cYElLxnBf+VSeSmAh3OLgLAQb08jc4x bG2DeNxU0zrboE7VoZQbdDSFwz1FtTie08vzZCctrtXt4uWH3KQExSTgiaqPSNEf2PUS pZjg== MIME-Version: 1.0 X-Received: by 10.60.144.233 with SMTP id sp9mr5602653oeb.53.1371781090583; Thu, 20 Jun 2013 19:18:10 -0700 (PDT) Received: by 10.60.26.135 with HTTP; Thu, 20 Jun 2013 19:18:10 -0700 (PDT) X-Originating-IP: [128.89.255.40] In-Reply-To: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115D2D76@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF115D2E8D@MCHP04MSX.global-ad.net> Date: Thu, 20 Jun 2013 22:18:10 -0400 Message-ID: From: Richard Barnes To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b3a8b669d3cc304dfa0acdd X-Gm-Message-State: ALoCoQmcqFCftTPzcqnBXGXc38fQtgLkSExwinzp9dVK3GFpKgh10x3ffrV7TCTW5C6K83+SP66y Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 02:18:16 -0000 --047d7b3a8b669d3cc304dfa0acdd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 20, 2013 at 7:41 PM, Martin Thomson wrote: > On 20 June 2013 16:09, Richard Barnes wrote: > > If, in addition, the browser does not expose media keys to JS (as is > > required for SDES), then even an active attacker who hijacks the HTTP > > connection to inject scripts cannot access the media keys. > > That's only true if that attacker were not able to also set the keys. > I haven't had anyone explain what the API for EKT would look like, but > one possibility would permit that attacker to set keys (i.e., keying > would be write-only). That possibility would be attractive from a > symmetry perspective - the non-browser can insert new keying, why > should the browser be prevented from doing so - but I can see how > implementation of EKT does not strictly require that possibility. > That would preclude some interesting browser-API-based scenarios > though. > Good point. I hadn't thought of that. In order for SDES to work, though, I would think you would need both getting and setting of keys. What interesting scenarios do you have in mind? I wonder whether the group considers them critical for v1. In any case, this seems like something where a conservative approach could be taken at first, then a key access API added later. --Richard --047d7b3a8b669d3cc304dfa0acdd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Thu, Jun 20, 2013 at 7:41 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
    On 20 June 2013 16:09, Ric= hard Barnes <rlb@ipv.sx> wrote:
    > If, in addition, the browser does not expose media keys to JS (as is > required for SDES), then even an active attacker who hijacks the HTTP<= br> > connection to inject scripts cannot access the media keys.

    That's only true if that attacker were not able to also set the k= eys.
    I haven't had anyone explain what the API for EKT would look like, but<= br> one possibility would permit that attacker to set keys (i.e., keying
    would be write-only). =A0That possibility would be attractive from a
    symmetry perspective - the non-browser can insert new keying, why
    should the browser be prevented from doing so - but I can see how
    implementation of EKT does not strictly require that possibility.
    That would preclude some interesting browser-API-based scenarios
    though.

    Good point. =A0I ha= dn't thought of that. =A0In order for SDES to work, though, I would thi= nk you would need both getting and setting of keys.

    What interesting scenarios do you have= in mind? =A0I wonder whether the group considers them critical for v1.

    In any ca= se, this seems like something where a conservative approach could be taken = at first, then a key access API added later.

    --Richard

    --047d7b3a8b669d3cc304dfa0acdd-- From hadriel.kaplan@oracle.com Thu Jun 20 19:58:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613E521E80DF for ; Thu, 20 Jun 2013 19:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xstqsNwE0xMi for ; Thu, 20 Jun 2013 19:58:38 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 738CD21E80F3 for ; Thu, 20 Jun 2013 19:58:38 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5L2wXRx012047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 02:58:34 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5L2wWhc019156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 02:58:33 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5L2wWrO019148; Fri, 21 Jun 2013 02:58:32 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-166-188.vpn.oracle.com (/10.154.166.188) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jun 2013 19:58:32 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Thu, 20 Jun 2013 22:58:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <529DCF4E-2A8B-475F-8CCE-7E2ABC72EFB1@oracle.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> To: Richard Barnes X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 02:58:44 -0000 On Jun 20, 2013, at 10:14 PM, Richard Barnes wrote: > > It's more secure in the sense that JS can't access the key, so an = injected script can't grab the key and exfiltrate it. So the browser = user is better protected against XSS risks. >=20 > This part I'd like to understand better. Can you explain it? > If a Browser cannot determine what server the JS being executed for = WebRTC API calls/callbacks came from, or cannot tell if it came from one = over HTTPS in particular, then using SDES might be a real problem. I = was under the impression browsers did know those things (or at least = that they're theoretically supposed to, ignoring that there are "bugs" = here and there). >=20 > As with many things in the web security model, the answer is "It's = complicated". The wikipedia article on XSS is pretty good. > >=20 > The upshot is that your typical web page gets cobbled together out of = many pieces, often from different domains. Scripts from multiple = sources get imported into the overall security context of the page. = This composition can happen deliberately (e.g., mashups, JS libraries) = or maliciously (XSS). Let me provide an example of each: >=20 > 1. Suppose I use jQuery to do pretty layout on my page. There's = nothing that actually constrains jQuery to only do layout. If jQuery is = out to get me, it could do something like overwrite = window.PeerConnection, so that all of the page's WebRTC calls go through = the jQuery library and are subject to its control. So if the = PeerConnection API exposes keys, jQuery can steal them. We've talked about that one before I think. If jQuery is out to get = you, it's game over. It's essentially equivalent to a malicious = web-server, except of course that the operator of the web-server isn't = intending to be malicious (which is an important distinction). But = again, not only does jQuery have access to information such as who = you're talking to and when, it can also redirect your media to a gateway = of its choosing to terminate the DTLS-SRTP and record it, by fiddling = with the JSON/SDP stuff. > 2. Suppose the overall page is loaded over HTTPS, but one of the = scripts is loaded over HTTP. Then the overall security context for the = page is HTTPS, but if an attacker can hijack that HTTP load to introduce = a script, in which case he can do the same bad stuff that jQuery could = in the above example. (This is why we have the following sentence in = draft-ietf-rtcweb-security-arch: "It is RECOMMENDED that browsers which = allow active mixed content nevertheless disable RTCWEB functionality in = mixed content settings." Right, and I think we've talked about that before too in the context of = SDES: I think people were ok with limiting it further for SDES with a = statement saying it must not be used in mixed content settings if one of = the scripts came in on HTTP. (although I could be wrong on whether any = consensus was reached on that point - it was a long time ago and I have = a memory leak) > There are mitigations to a lot of these sorts of issues, but some are = still being developed. And of course, there's no guarantee that a given = site will follow all the best practices. So it seems sensible to limit = the damage that an injected script can do. Right, and I'm hoping the Browser vendors can tell us if browsers can = safely know whether all the JS running on a given page is from HTTPS or = not, and not allow SDES if the JS is not all from (signed) HTTPS. If = not, then I agree that's another negative downside for SDES. In fact I = think it's even a problem for DTLS-SRTP. I don't know why we'd be ok = with using HTTP at all, if we're *truly* concerned about MitM and = malicious 3rd party JS attacks.=20 -hadriel From bossiel@yahoo.fr Fri Jun 21 02:40:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBB021E80BA for ; Fri, 21 Jun 2013 02:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzhvvE6EWQqP for ; Fri, 21 Jun 2013 02:40:17 -0700 (PDT) Received: from nm30.bullet.mail.ir2.yahoo.com (nm30.bullet.mail.ir2.yahoo.com [212.82.96.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8890511E8171 for ; Fri, 21 Jun 2013 02:40:07 -0700 (PDT) Received: from [212.82.98.58] by nm30.bullet.mail.ir2.yahoo.com with NNFMP; 21 Jun 2013 09:40:03 -0000 Received: from [212.82.108.112] by tm11.bullet.mail.ir2.yahoo.com with NNFMP; 21 Jun 2013 09:40:01 -0000 Received: from [127.0.0.1] by omp1021.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 09:40:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 73731.57410.bm@omp1021.mail.ird.yahoo.com Received: (qmail 43390 invoked by uid 60001); 21 Jun 2013 09:40:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1371807600; bh=TqYwFZ1zXluEgqAjKb9u8gWrQRBJ67ZErJor0rekRlk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RO0ho5P5QDvhDxNcA4FlOBnxEC+HCcioahfgX7lLjnhjTc16gmeaAHpEU9MNfpwpw3FclcnIoL4ZTdmgE/uWB4ioKHDMSEt+SZp8BYmBi+47vWvK3t11r2RFGyePYDx/6DWrhOEgQwjIFDZEPg0gekivBF++UiQpgqPdGiThhSA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RtdrpwatDjvPqDSOmCqiUYZrFICCI2KYdRw+hk6FdcyPyv39j16dS63aI6FgECZwxtxvUxsr3b4KUW6zpFxoskcLoSjmE/r3DV3pEDgxk6IGr72tHcYM8HR5PCU0DhzqKSuJ6sByeh2romTpA25+blYSSDnztffgA4yge/AFlL4=; X-YMail-OSG: rlMLxjkVM1lykAkCRLhOkXEC8fAMvVKfkQ8NB8SLEVqro_K c8lBQKPTvT3FNzl1o2H2BN75UNZ7OvBzxHweo.0CNXNZmVp8lqm1PqlEqVrL pRQ0xAGEPTtw0onDdHPRxTi_wnbUW2T16FlpQLN_A89c86G2zP8F3JRD6X2N NL9AdoLvjFhqdJ0cIZJYZYCPV7lYA.7USnGsEP7kAL55lZ2Mg49lROGkIFvr mCbw8xVa_cs7ZerkO61gEq0179278MgR3bqzR8qxgCHzmzRhidQR1NL36vYO yt176IiSU.cGgNco79nWhF7URxFQkNYM8lrLWVFoFFGPsG0SnylxTKx_IYxu 6CwBiZZvmhD6cYwkGYc7GawL2ycJkrV7lIfpPmyQq61Go2HzGx7EThoKYxqq WzNlq5MCxOgKdIccQbxH2X.CZhjOVMtoW776nVBkbHXlb6VOeZ3eyz_NQ.oB A1E7w7MZ9HSrcIdrToXHAI_ZxL3xGYwPaE7J5AIPfA7v8aaLAmPG9403ABf6 Xyiw9RFlswutAjaWPHXgoGoDWpVT6kv.wSflmvNWsOjUfznq77ZZo3gzH2_p 1WunyAV58WT48q3vNC0VqF4VH1.n1.6.JCUgKbT_alz67Pj1S_tFtbKiYHkA lU4ALjYU5yiOzQrIwp1SToCjdvx9lYCL.lWcF358tSh8oW14TRmPTZJXyWrl CzexF63sLR_Vk7aa2DXy8V0nD18cNKfROOg-- Received: from [88.179.39.5] by web171301.mail.ir2.yahoo.com via HTTP; Fri, 21 Jun 2013 10:40:00 BST X-Rocket-MIMEInfo: 002.001, SGVsbG8sCgpJJ20gcmVnaXN0ZXJlZCBvbiB0aGlzIGdyb3VwIHNpbmNlIHRoZSBiZWdpbm5pbmcgYnV0IHRoaXMgaXMgbXkgZmlyc3QgcG9zdCBvbiB0aGlzIHRocmVhZC4gU28sIEkgcHJlc2VudGUgbXlzZWxmOiBNYW1hZG91IERJT1AgYW5kIEknbSB3b3JraW5nIGZvciBEb3ViYW5nbyBUZWxlY29tIHdoZXJlIHdlJ3JlIGJ1aWxkaW5nIFNJUCBlbmRwb2ludHMsIGdhdGV3YXlzLCBUZWxlUHJlc2VuY2UvVGVsZW1lZGljaW5lIHN5c3RlbXMuLi4gYWxsIGZvY3VzZWQgb24gU0lQL0lNUy9MVEUvUkNTLWUgYW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.554 References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> Message-ID: <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> Date: Fri, 21 Jun 2013 10:40:00 +0100 (BST) From: Bossiel thioriguel To: "diopmamadou@doubango.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="862858767-718295900-1371807600=:23131" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bossiel thioriguel List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 09:40:24 -0000 --862858767-718295900-1371807600=:23131 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello,=0A=0AI'm registered on this group since the beginning but this is my= first post on this thread. So, I presente myself: Mamadou DIOP and I'm wor= king for Doubango Telecom where we're building SIP endpoints, gateways, Tel= ePresence/Telemedicine systems... all focused on SIP/IMS/LTE/RCS-e and open= source.=0A=0AWhat I'm talking about is not just feeling but something I've= experienced.=0A=0AUsing the current WebRTC we have managed to *easily* bui= ld almost all kind of applications: click-to-call, SIP/IMS clients, gateway= s to PSTN, MCUs, Telemedicine systems...and haven't seen any major issue. I= t's true that it's not natural to "hack" a blob SDP to implement features l= ike hold/resume, media update, early media ... but it works and there are d= emo applications showing it. If there is something more beautiful we just w= ant to see it in action and test it.=0A=0AMany participants here have said = that what they want is something close to CU-RTC-WEB. Don't really know if = they tried to build applications using it or not but in my case I have.=0AM= y reference:=A0http://html5labs.interoperabilitybridges.com/prototypes/cu-r= tc-web-roaming/cu-rtc-web-roaming/info=0AFirst on Windows 8 but haven't gon= e far as there is no documentation to get started. Then, OSX and=A0luckily= =A0there was a readme with two links for testing (only one work). You need = to open 3 pages (1 master, 2 slaves) and check "send audio" on both slaves = to header sound. Many javascript files and no documentation. It's said on t= hese blogs that interop with SIP networks is easy but it's not my feeling .= ..I just want to see one :)=0A=0AI don't really understand the issue with t= he O/A model. SDP or not SDP you'll always offer something and answer somet= hing. I'm I missing?=0A=0AFor the current WebRTC, Google open sourced their= engine, produced drafts, a working implementation in chrome, a=A0mailing-l= ist to help developers, demo applications, documentation... we just want to= see the same from any company asking to rewrite everything.=0A=0AI'm not s= aying the current WebRTC implementation is perfect but I have seen my 14 ye= ar old=A0nephew developing an audio/video chat for his homework :)=0A=0AReg= ards=0A=0A=0A________________________________=0A De=A0: I=F1aki Baz Castill= o =0A=C0=A0: Emil Ivov =0ACc=A0: "rtcweb@i= etf.org" =0AEnvoy=E9 le : Vendredi 21 juin 2013 1h24=0AOb= jet=A0: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened=0A = =0A=0A2013/6/21 Emil Ivov :=0A>=0A> On 20.06.13, 23:49, I= =F1aki Baz Castillo wrote:=0A>>=0A>> In JsSIP we are getting frustrated try= ing to implement the "hold" /=0A>> "unhold" feature because it requires SDP= parsing and mangling. Sending=0A>> a re-INVITE with a modified SDP (now wi= th a video track enabled) seems=0A>> to work (after lot of pain) but we sti= ll miss a reliable API to know=0A>> what the new SDP means. Instead we need= to parse the SDP to detect=0A>> global (or per m=3D) line attributes like = "a=3Dinactive" or "a=3Dsendonly"=0A>> etc etc. It's really painful.=0A>=0A>= =0A> I am having a problem following what you are trying to achieve here. I= n=0A> JsSIP you seem to be going for a full SIP implementation in the brows= er. If=0A> this is true and if this WG decides to remove SDP from the API s= urface, then=0A> you would need to completely parse SDP in the JS and then = convert it into=0A> API calls. Similarly, when creating offers and answers = you would need to=0A> construct SDP all by yourself.=0A=0AAnd we will do it= very happily because then we will know what=0A*exactly* we are sending on-= the-wire.=0A=0A=0A=0A=0A> So I am not sure why the SDP parsing in the curre= nt situation is so much of=0A> a blocker for your use case.=0A=0ABecause re= gardless I am a SIP-guy, I understand that the main mission=0Aof WebRTC is = to provide realtime communications *for* the WWW, and not=0Ato enable a new= interface for like-telephony-bussines.=0A=0AToday I'm doing SIP. Tomorrow = I may be doing=0A[[put_here_a_future_RTC_protocol_not_based_on_SDP]] and th= en I don't=0Awant to be constrained by decisions made today that force any = future=0ARTC protocol to deal with SDP O/A model.=0A=0A:)=0A=0A=0A=0A>> BTW= I don't know wheter you support PlanA, PlanB or NoPlan, but I did=0A>> a q= uestion (in this case about NoPlan) for which I got no response,=0A>> and h= onestly I would like to see it replied regardless the solution=0A>> uses Pl= anA, PlanB or NoPlan model:=0A>>=0A>> http://www.ietf.org/mail-archive/web/= rtcweb/current/msg07871.html=0A>>=0A> The other option would be indeed to d= o the same thing in JS. I believe this=0A> is JsSIP's use case. In that cas= e however, regardless of whether you choose=0A> Plan A, Plan B, No Plan or = CU-RTC-Web, you will inevitably be exposed to a=0A> fair amount of complexi= ty, parsing and JS magic.=0A>=0A> You are, after all, building a SIP stack.= =0A=0AYes, but JsSIP creates its own SIP messages to be sent in the wire, s= o=0Awe have full control over *what* we create and send. Those SIP=0Amessag= es are not provided by the WebRTC API. But for the SDP=0Acomponent, JsSIP r= etreives a SDP blob string from the PC.=0A=0A=0A=0A=0A=0A=0A=0A>=0A> In the= above mail you also say:=0A>=0A>> Another example:=0A>>=0A>> * I am a powe= rful SIP conference server which properly implements=0A>> WebRTC. I initiat= e a call to 5 users (running JS SIP app in their=0A>> browsers). The initia= l INVITE has SSRC/MSID fields in the SDP=0A>> identifying all the participa= nts, am I right?=0A>=0A>=0A> No, with No Plan there are no SSRCs and MSIDs = in the SDP that comes from the=0A> browser.=0A=0AOK=0A=0A=0A>> * Later, dur= ing the conference, I call to another 6th participant and=0A>> enter him in= to the conference, so I need to send a re-INVITE to every=0A>> participant = with a modified version of the SDP (note that this is SIP=0A>> protocol, so= I need to use SIP messages to carry the new info about=0A>> SSRC/MSID and = so on).=0A>=0A>=0A> That's the thing. You don't need that. In Jitsi we do e= xactly this operation=0A> with no Offer/Answer signalling. RTP carries enou= gh information to process=0A> streams and we use upper layer signalling (45= 75) for things such as mapping=0A> SSRCs to users and announcing current pa= rticipant list.=0A=0AThat is much better than Plan A and Plan B.=0A=0A=0A= =0ABTW: What would happen in NoPlan if the remote (i.e. a SIP=0Agateway/end= poing) sends you a re-INVITE for "hold" purposes and you=0Apass the SDP to = your PC? or you should not pass the SDP to your PC?=0Aand if so, what about= if the SDP contains updated ICE candidates due=0Ato remote peer network mo= bility?=0A=0A=0A=0AThanks a lot for your response.=0A=0A--=0AI=F1aki Baz Ca= stillo=0A=0A_______________________________________________= =0Artcweb mailing list=0Artcweb@ietf.org=0Ahttps://www.ietf.org/mailman/lis= tinfo/rtcweb --862858767-718295900-1371807600=:23131 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    = Hello,

    I'm= registered on this group since the beginning but this is my first post on = this thread. So, I presente myself: Mamadou DIOP and I'm working for Douban= go Telecom where we're building SIP endpoints, gateways, TelePresence/Telem= edicine systems... all focused on SIP/IMS/LTE/RCS-e and open source.=

    What I'm talking a= bout is not just feeling but something I've experienced.

    Using the current WebRTC we = have managed to *easily* build almost all kind of applications: click-to-ca= ll, SIP/IMS clients, gateways to PSTN, MCUs, Telemedicine systems...and hav= en't seen any major issue. It's true that it's not natural to "hack" a blob SDP to implement features like hold/resume, media update, early media= ... but it works and there are demo applications showing it. If there is s= omething more beautiful we just want to see it in action and test it.

    Many participan= ts here have said that what they want is something close to CU-RTC-WEB. Don= 't really know if they tried to build applications using it or not but in m= y case I have.
    My reference: http://html5labs.interoperabilitybridges.com/prototypes/cu= -rtc-web-roaming/cu-rtc-web-roaming/info
    First on Windows 8 but haven't gone far as th= ere is no documentation to get started. Then, OSX and luckily the= re was a readme with two links for testing (only one work). You need to ope= n 3 pages (1 master, 2 slaves) and check "send audio" on both slaves to hea= der sound. Many javascript files and no documentation. It's said on these b= logs that interop with SIP networks is easy but it's not my feeling ...I ju= st want to see one :)

    I don't really understand the issue with the O/A model. SDP= or not SDP you'll always offer something and answer something. I'm I missi= ng?

    For the current WebRTC, Google open sourced the= ir engine, produced drafts, a working implementation in chrome, a mail= ing-list to help developers, demo applications, documentation... we just wa= nt to see the same from any company asking to rewrite everything.

    I'm not sayin= g the current WebRTC implementation is perfect but I have seen my 14 year o= ld nephew developing an audio/video chat for his homework :)

    Regards

    De : I=F1aki Baz Castillo <= ibc@aliax.net>
    =C0 : Emil Ivov <emcho@jitsi.org>
    Cc : "rtcweb@ietf.org" <rtcweb@ietf.org>
    = Envoy=E9 le : Vendredi 21= juin 2013 1h24
    Objet : Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
    =

    2013/6/21 Emil Ivov <<= a ymailto=3D"mailto:emcho@jitsi.org" href=3D"mailto:emcho@jitsi.org">emcho@= jitsi.org>:
    >
    > On 20.06.13, 23:49, I=F1aki Baz Castillo= wrote:
    >>
    >> In JsSIP we are getting frustrated trying t= o implement the "hold" /
    >> "unhold" feature because it requires S= DP parsing and mangling. Sending
    >> a re-INVITE with a modified SD= P (now with a video track enabled) seems
    >> to work (after lot of pain) but we = still miss a reliable API to know
    >> what the new SDP means. Inste= ad we need to parse the SDP to detect
    >> global (or per m=3D) line= attributes like "a=3Dinactive" or "a=3Dsendonly"
    >> etc etc. It's= really painful.
    >
    >
    > I am having a problem following wh= at you are trying to achieve here. In
    > JsSIP you seem to be going fo= r a full SIP implementation in the browser. If
    > this is true and if = this WG decides to remove SDP from the API surface, then
    > you would = need to completely parse SDP in the JS and then convert it into
    > API= calls. Similarly, when creating offers and answers you would need to
    &g= t; construct SDP all by yourself.

    And we will do it very happily bec= ause then we will know what
    *exactly* we are sending on-the-wire.



    > So I am not sure why the SDP parsing in the current situation is so much of
    > a blocker for your use case.

    Becaus= e regardless I am a SIP-guy, I understand that the main mission
    of WebRT= C is to provide realtime communications *for* the WWW, and not
    to enable= a new interface for like-telephony-bussines.

    Today I'm doing SIP. T= omorrow I may be doing
    [[put_here_a_future_RTC_protocol_not_based_on_SDP= ]] and then I don't
    want to be constrained by decisions made today that = force any future
    RTC protocol to deal with SDP O/A model.

    :)
    <= br>

    >> BTW I don't know wheter you support PlanA, PlanB or NoP= lan, but I did
    >> a question (in this case about NoPlan) for which= I got no response,
    >> and honestly I would like to see it replied= regardless the solution
    >> uses PlanA, PlanB or NoPlan model:
    = >>
    >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg0= 7871.html
    >>
    > The other option would be indeed to do th= e same thing in JS. I believe this
    > is JsSIP's use case. In that cas= e however, regardless of whether you choose
    > Plan A, Plan B, No Plan= or CU-RTC-Web, you will inevitably be exposed to a
    > fair amount of = complexity, parsing and JS magic.
    >
    > You are, after all, build= ing a SIP stack.

    Yes, but JsSIP creates its own SIP messages to be s= ent in the wire, so
    we have full control over *what* we create and send.= Those SIP
    messages are not provided by the WebRTC API. But for the SDP<= br>component, JsSIP retreives a SDP blob string from the PC.






    >
    > In the above mail you also say:
    >
    &g= t;> Another example:
    >>
    >> * I am a powerful SIP confe= rence server which properly implements
    >> WebRTC. I initiate a call to 5 users (running JS SIP app in their
    >> browsers). The = initial INVITE has SSRC/MSID fields in the SDP
    >> identifying all = the participants, am I right?
    >
    >
    > No, with No Plan ther= e are no SSRCs and MSIDs in the SDP that comes from the
    > browser.
    OK


    >> * Later, during the conference, I call to anoth= er 6th participant and
    >> enter him into the conference, so I need= to send a re-INVITE to every
    >> participant with a modified versi= on of the SDP (note that this is SIP
    >> protocol, so I need to use= SIP messages to carry the new info about
    >> SSRC/MSID and so on).=
    >
    >
    > That's the thing. You don't need that. In Jitsi we= do exactly this operation
    > with no Offer/Answer signalling. RTP car= ries enough information to process
    > streams and we use upper layer s= ignalling (4575) for things such as mapping
    > SSRCs to users and announcing current participant list.

    That is much better than P= lan A and Plan B.



    BTW: What would happen in NoPlan if the re= mote (i.e. a SIP
    gateway/endpoing) sends you a re-INVITE for "hold" purp= oses and you
    pass the SDP to your PC? or you should not pass the SDP to = your PC?
    and if so, what about if the SDP contains updated ICE candidate= s due
    to remote peer network mobility?



    Thanks a lot for y= our response.

    --
    I=F1aki Baz Castillo
    <ibc@aliax.net>
    ____= ___________________________________________
    rtcweb mailing list
    rtcweb@iet= f.org
    https://www.ietf.org/mailman/listinfo/rtcweb


    --862858767-718295900-1371807600=:23131-- From bossiel@yahoo.fr Fri Jun 21 02:56:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AD421F8F4F for ; Fri, 21 Jun 2013 02:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP0mV+AYoYHC for ; Fri, 21 Jun 2013 02:56:13 -0700 (PDT) Received: from nm17-vm1.bullet.mail.ird.yahoo.com (nm17-vm1.bullet.mail.ird.yahoo.com [77.238.189.206]) by ietfa.amsl.com (Postfix) with ESMTP id 1F69C21F8EEA for ; Fri, 21 Jun 2013 02:56:12 -0700 (PDT) Received: from [77.238.189.238] by nm17.bullet.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 09:56:12 -0000 Received: from [212.82.108.132] by tm19.bullet.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 09:56:12 -0000 Received: from [127.0.0.1] by omp1037.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 09:56:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 220716.60730.bm@omp1037.mail.ird.yahoo.com Received: (qmail 86117 invoked by uid 60001); 21 Jun 2013 09:56:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1371808572; bh=UIMzzM70ZodASZzcXJMQi11tLR364ceF45ObEUy4aXo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ilDqNEZ9iDk+wjkPnpqFp6CxC4jeiiCqodNk8gYwlHxoqPHX4mM3ntgpDZwaOxloMlA0vFVKeL8Vkt51HNs0ZDdH2YRTeqSU8catczWSkZwn98S8614ErMi8ERhrJzG7YMNFnG0p6qoVAVHlIPCYAMtolDbiFRRIU0ZrA6b0/gU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KJP7uYV1X2DAJC0BUKfq4FvZF5SCNn6mdLkQLDWyhMhxk2ZMS2LeaDe2tOtJZd839wQzqIMGJepN9tl64opWzNFwlUTix9StY9rU6tnxsLj+RKZF2ojIbmH31zT+wjWdA1niTDKvCqzxfog2kxA/SgxnO9Ole4HnCQeaaCiMCmM=; X-YMail-OSG: EhZ7YY8VM1k10aIdzzPZZWnSZAh_rZIR3s5YqpCYkotA6bS gq62KaQZiF6iOJaDw4xw3y5G9gwcecCM1MKHsjJ0w4G6gwBmE78O6WiKczJ2 pBXWU2QGD0byS9QfmSN.6spRO4_HYDibVpUe2PqFBIAiBIru6nWWWkIOIj8w JiFWbhwxQoFdY_qWdgq4Qeh3YhJIptawHP1XL06fYYiISR0pfnTonBoTae23 l84iwdZ0s7IS3Tm8by_ctobq.GROgMIcB7RjbTRjr4c2UkET4v2Juw9fDLkE Jr7AUGpxrgNeNefbEmU5ZoZFSIwNdc2NAftqS7mx9z_Nmfr56Rt0o9aUxtSu EfBv42zkkO5Y9zeeLKSlRyIxkH9nd6bBar7cha67_MOqZFut8ECmJ.xDcACa M_vTHK.ytHz1d04nsni31LmdrNLea6zDi.CW.TZn_QmKdYQbcRG4KwdJXk6k MqYLJvU665BS5E2xIFdM969IhoTkOJ2mx2flhgMyECAV9aIP_EskH0SjCbkz GLn5x65nE2qS4ADnxhC0O.nyUob2eykUcUVMQ9Hygrk9.MyP0VS_Dysm4ps0 wAPfy2g6TYbCEtCFaxxzPL6n4GfZswKwV6UHtDBi5qMJ2NDG5odjWDC5C5YR zAsVNxJeFF9NJZrYEECKbo5hrrKBAX0i5.WbIdHsZMO2bTYLo9k1XFCQsWwE WzmBQol6WyNltZQDHlM1ythJR7UGRkruHEw-- Received: from [88.179.39.5] by web171304.mail.ir2.yahoo.com via HTTP; Fri, 21 Jun 2013 10:56:11 BST X-Rocket-MIMEInfo: 002.001, Rm9yZ290IHRvIGFkZDoKV2UncmUgd2lsbGluZyB0byBwcm92aWRlIGFuIG9wZW4gc291cmNlIGdhdGV3YXkgdG8gU0lQL0lNUyB3b3JsZCBhbmQgZmVlZGJhY2tzIGZvciBhbnkgbmV3wqBpbXBsZW1lbnRhdGlvbsKgdG8gc2hvdyAiaG93IGdvb2QiIG9yICJob3cgYmFkIiBpdCBpcyA6KQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBEZcKgOiBCb3NzaWVsIHRoaW9yaWd1ZWwgPGJvc3NpZWxAeWFob28uZnI.CsOAwqA6ICJkaW9wbWFtYWRvdUBkb3ViYW5nby5vcmciIDxkaW9wbWFtYWRvdUABMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.554 References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> Message-ID: <1371808571.86034.YahooMailNeo@web171304.mail.ir2.yahoo.com> Date: Fri, 21 Jun 2013 10:56:11 +0100 (BST) From: Bossiel thioriguel To: Bossiel thioriguel , "diopmamadou@doubango.org" In-Reply-To: <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1470824145-1261249343-1371808571=:86034" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bossiel thioriguel List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 09:56:19 -0000 ---1470824145-1261249343-1371808571=:86034 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Forgot to add:=0AWe're willing to provide an open source gateway to SIP/IMS= world and feedbacks for any new=A0implementation=A0to show "how good" or "= how bad" it is :)=0A=0A=0A________________________________=0A De=A0: Bossie= l thioriguel =0A=C0=A0: "diopmamadou@doubango.org" =0ACc=A0: "rtcweb@ietf.org" =0AEnvoy= =E9 le : Vendredi 21 juin 2013 11h40=0AObjet=A0: Re: [rtcweb] Requesting "S= DP or not SDP" debate to be re-opened=0A =0A=0A=0AHello,=0A=0AI'm registere= d on this group since the beginning but this is my first post on this threa= d. So, I presente myself: Mamadou DIOP and I'm working for Doubango Telecom= where we're building SIP endpoints, gateways, TelePresence/Telemedicine sy= stems... all focused on SIP/IMS/LTE/RCS-e and open source.=0A=0AWhat I'm ta= lking about is not just feeling but something I've experienced.=0A=0AUsing = the current WebRTC we have managed to *easily* build almost all kind of app= lications: click-to-call, SIP/IMS clients, gateways to PSTN, MCUs, Telemedi= cine systems...and haven't seen any major issue. It's true that it's not na= tural to "hack" a blob SDP to implement features like hold/resume, media up= date, early media ... but it works and there are demo applications showing = it. If there is something more beautiful we just want to see it in action a= nd test it.=0A=0AMany participants here have said that what they want is so= mething close to CU-RTC-WEB. Don't really know if they tried to build appli= cations using it or not but in my case I have.=0AMy reference:=A0http://htm= l5labs.interoperabilitybridges.com/prototypes/cu-rtc-web-roaming/cu-rtc-web= -roaming/info=0AFirst on Windows 8 but haven't gone far as there is no docu= mentation to get started. Then, OSX and=A0luckily=A0there was a readme with= two links for testing (only one work). You need to open 3 pages (1 master,= 2 slaves) and check "send audio" on both slaves to header sound. Many java= script files and no documentation. It's said on these blogs that interop wi= th SIP networks is easy but it's not my feeling ...I just want to see one := )=0A=0AI don't really understand the issue with the O/A model. SDP or not S= DP you'll always offer something and answer something. I'm I missing?=0A=0A= For the current WebRTC, Google open sourced their engine, produced drafts, = a working implementation in chrome, a=A0mailing-list to help developers, de= mo applications, documentation... we just want to see the same from any com= pany asking to rewrite everything.=0A=0AI'm not saying the current WebRTC i= mplementation is perfect but I have seen my 14 year old=A0nephew developing= an audio/video chat for his homework :)=0A=0ARegards=0A=0A=0A_____________= ___________________=0A De=A0: I=F1aki Baz Castillo =0A=C0=A0= : Emil Ivov =0ACc=A0: "rtcweb@ietf.org" = =0AEnvoy=E9 le : Vendredi 21 juin 2013 1h24=0AObjet=A0: Re: [rtcweb] Reque= sting "SDP or not SDP" debate to be re-opened=0A =0A=0A2013/6/21 Emil Ivov = :=0A>=0A> On 20.06.13, 23:49, I=F1aki Baz Castillo wrote:= =0A>>=0A>> In JsSIP we are getting frustrated trying to implement the "hold= " /=0A>> "unhold" feature because it requires SDP parsing and mangling. Sen= ding=0A>> a re-INVITE with a modified SDP (now with a=0A video track enable= d) seems=0A>> to work (after lot of pain) but we still miss a reliable API = to know=0A>> what the new SDP means. Instead we need to parse the SDP to de= tect=0A>> global (or per m=3D) line attributes like "a=3Dinactive" or "a=3D= sendonly"=0A>> etc etc. It's really painful.=0A>=0A>=0A> I am having a prob= lem following what you are trying to achieve here. In=0A> JsSIP you seem to= be going for a full SIP implementation in the browser. If=0A> this is true= and if this WG decides to remove SDP from the API surface, then=0A> you wo= uld need to completely parse SDP in the JS and then convert it into=0A> API= calls. Similarly, when creating offers and answers you would need to=0A> c= onstruct SDP all by yourself.=0A=0AAnd we will do it very happily because t= hen we will know what=0A*exactly* we are sending on-the-wire.=0A=0A=0A=0A= =0A> So I am not sure why the SDP parsing in the current=0A situation is so= much of=0A> a blocker for your use case.=0A=0ABecause regardless I am a SI= P-guy, I understand that the main mission=0Aof WebRTC is to provide realtim= e communications *for* the WWW, and not=0Ato enable a new interface for lik= e-telephony-bussines.=0A=0AToday I'm doing SIP. Tomorrow I may be doing=0A[= [put_here_a_future_RTC_protocol_not_based_on_SDP]] and then I don't=0Awant = to be constrained by decisions made today that force any future=0ARTC proto= col to deal with SDP O/A model.=0A=0A:)=0A=0A=0A=0A>> BTW I don't know whet= er you support PlanA, PlanB or NoPlan, but I did=0A>> a question (in this c= ase about NoPlan) for which I got no response,=0A>> and honestly I would li= ke to see it replied regardless the solution=0A>> uses PlanA, PlanB or NoPl= an model:=0A>>=0A>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg= 07871.html=0A>>=0A> The other option would be indeed to do the same thing i= n JS. I believe this=0A> is JsSIP's use case. In that case however, regardl= ess of whether you choose=0A> Plan A, Plan B, No Plan or CU-RTC-Web, you wi= ll inevitably be exposed to a=0A> fair amount of complexity, parsing and JS= magic.=0A>=0A> You are, after all, building a SIP stack.=0A=0AYes, but JsS= IP creates its own SIP messages to be sent in the wire, so=0Awe have full c= ontrol over *what* we create and send. Those SIP=0Amessages are not provide= d by the WebRTC API. But for the SDP=0Acomponent, JsSIP retreives a SDP blo= b string from the PC.=0A=0A=0A=0A=0A=0A=0A=0A>=0A> In the above mail you al= so say:=0A>=0A>> Another example:=0A>>=0A>> * I am a powerful SIP conferenc= e server which properly implements=0A>> WebRTC. I initiate=0A a call to 5 u= sers (running JS SIP app in their=0A>> browsers). The initial INVITE has SS= RC/MSID fields in the SDP=0A>> identifying all the participants, am I right= ?=0A>=0A>=0A> No, with No Plan there are no SSRCs and MSIDs in the SDP that= comes from the=0A> browser.=0A=0AOK=0A=0A=0A>> * Later, during the confere= nce, I call to another 6th participant and=0A>> enter him into the conferen= ce, so I need to send a re-INVITE to every=0A>> participant with a modified= version of the SDP (note that this is SIP=0A>> protocol, so I need to use = SIP messages to carry the new info about=0A>> SSRC/MSID and so on).=0A>=0A>= =0A> That's the thing. You don't need that. In Jitsi we do exactly this ope= ration=0A> with no Offer/Answer signalling. RTP carries enough information = to process=0A> streams and we use upper layer signalling (4575) for things = such as mapping=0A> SSRCs to users=0A and announcing current participant li= st.=0A=0AThat is much better than Plan A and Plan B.=0A=0A=0A=0ABTW: What w= ould happen in NoPlan if the remote (i.e. a SIP=0Agateway/endpoing) sends y= ou a re-INVITE for "hold" purposes and you=0Apass the SDP to your PC? or yo= u should not pass the SDP to your PC?=0Aand if so, what about if the SDP co= ntains updated ICE candidates due=0Ato remote peer network mobility?=0A=0A= =0A=0AThanks a lot for your response.=0A=0A--=0AI=F1aki Baz Castillo=0A=0A_______________________________________________=0Artcweb mail= ing list=0Artcweb@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/rtcweb= =0A=0A=0A=0A_______________________________________________=0Artcweb mailin= g list=0Artcweb@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/rtcweb ---1470824145-1261249343-1371808571=:86034 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    = Forgot to add:
    We're willing to provide an open source gateway to SIP/IMS world and fe= edbacks for any new implementation to show "how good" or "how bad= " it is :)

    = De : Bossiel thiorigue= l <bossiel@yahoo.fr>
    =C0&nb= sp;: "diopmamadou@doubango.org" <diopmamadou@doubango.org>
    Cc : "rtcweb@ietf.org" <rtcw= eb@ietf.org>
    Envoy=E9 le : Vendredi 21 juin 2013 11h40
    Objet : Re: [rtcweb] Requesting "SDP or not SDP" debate= to be re-opened

    Hello,

    I'm registered on this group since the = beginning but this is my first post on this thread. So, I presente myself: = Mamadou DIOP and I'm working for Doubango Telecom where we're building SIP = endpoints, gateways, TelePresence/Telemedicine systems... all focused on SI= P/IMS/LTE/RCS-e and open source.

    <= /div>
    What I'm talking about is not just feeling but somet= hing I've experienced.

    Using the current WebRTC we have managed to *easily* bui= ld almost all kind of applications: click-to-call, SIP/IMS clients, gateway= s to PSTN, MCUs, Telemedicine systems...and haven't seen any major issue. I= t's true that it's not natural to "hack" a=0A blob SDP to implement feature= s like hold/resume, media update, early media ... but it works and there ar= e demo applications showing it. If there is something more beautiful we jus= t want to see it in action and test it.

    <= /span>
    Many participants here have said that what th= ey want is something close to CU-RTC-WEB. Don't really know if they tried t= o build applications using it or not but in my case I have.
    My=0A reference: http://html5labs.interoperabilitybridg= es.com/prototypes/cu-rtc-web-roaming/cu-rtc-web-roaming/info
    First on Windows 8 but hav= en't gone far as there is no documentation to get started. Then, OSX and&nb= sp;luckily there was a readme with two links for testing (only one wor= k). You need to open 3 pages (1 master, 2 slaves) and check "send audio" on= both slaves to header sound. Many javascript files and no documentation. I= t's said on these blogs that interop with SIP networks is easy but it's not= my feeling ...I just want to see one :)

    =
    I don't really understand the issue with the O/A model. SDP= or not SDP you'll always offer something and answer something. I'm I missi= ng?

    For the current WebRTC, Google open sourced thei= r engine, produced drafts, a working implementation in chrome, a maili= ng-list to help developers, demo applications, documentation... we just wan= t to see the same from any company asking to rewrite everything.

    I'm not saying the current= WebRTC implementation is perfect but I have seen my 14 year old nephe= w developing an audio/video chat for his homework :)
    Regards

    De : I=F1aki Baz Castillo <= ibc@aliax.net>
    =C0 : Emil Ivov <emcho@jitsi.org>
    Cc : "rtcweb@ietf.org" <rtcweb@ietf.org>
    <= b>Envoy=E9 le : Vendredi 21 ju= in 2013 1h24
    Objet : Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

    2013/6/21 Emil I= vov <emcho@jitsi.org>:
    >
    &= gt; On 20.06.13, 23:49, I=F1aki Baz Castillo wrote:
    >>
    >>= In JsSIP we are getting frustrated trying to implement the "hold" /
    >= ;> "unhold" feature because it requires SDP parsing and mangling. Sendin= g
    >> a re-INVITE with a modified SDP (now with a=0A video track enabled) seems>> to work (after lot of pain) but we still miss a reliable API to k= now
    >> what the new SDP means. Instead we need to parse the SDP to= detect
    >> global (or per m=3D) line attributes like "a=3Dinactive= " or "a=3Dsendonly"
    >> etc etc. It's really painful.
    >
    &g= t;
    > I am having a problem following what you are trying to achieve h= ere. In
    > JsSIP you seem to be going for a full SIP implementation in= the browser. If
    > this is true and if this WG decides to remove SDP = from the API surface, then
    > you would need to completely parse SDP i= n the JS and then convert it into
    > API calls. Similarly, when creati= ng offers and answers you would need to
    > construct SDP all by yourse= lf.

    And we will do it very happily because then we will know what*exactly* we are sending on-the-wire.




    > So I am not = sure why the SDP parsing in the current=0A situation is so much of
    > = a blocker for your use case.

    Because regardless I am a SIP-guy, I un= derstand that the main mission
    of WebRTC is to provide realtime communic= ations *for* the WWW, and not
    to enable a new interface for like-telepho= ny-bussines.

    Today I'm doing SIP. Tomorrow I may be doing
    [[put_h= ere_a_future_RTC_protocol_not_based_on_SDP]] and then I don't
    want to be= constrained by decisions made today that force any future
    RTC protocol = to deal with SDP O/A model.

    :)



    >> BTW I don't k= now wheter you support PlanA, PlanB or NoPlan, but I did
    >> a ques= tion (in this case about NoPlan) for which I got no response,
    >> a= nd honestly I would like to see it replied regardless the solution
    >&= gt; uses PlanA, PlanB or NoPlan model:
    >>
    >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07871.html
    &= gt;>
    > The other option would be indeed to do the same thing in JS= . I believe this
    > is JsSIP's use case. In that case however, regardl= ess of whether you choose
    > Plan A, Plan B, No Plan or CU-RTC-Web, yo= u will inevitably be exposed to a
    > fair amount of complexity, parsin= g and JS magic.
    >
    > You are, after all, building a SIP stack.
    Yes, but JsSIP creates its own SIP messages to be sent in the wire, s= o
    we have full control over *what* we create and send. Those SIP
    mess= ages are not provided by the WebRTC API. But for the SDP
    component, JsSI= P retreives a SDP blob string from the PC.







    &= gt;
    > In the above mail you also say:
    >
    >> Another exa= mple:
    >>
    >> * I am a powerful SIP conference server which properly implements
    >> WebRTC. I initiate=0A a call to 5 us= ers (running JS SIP app in their
    >> browsers). The initial INVITE = has SSRC/MSID fields in the SDP
    >> identifying all the participant= s, am I right?
    >
    >
    > No, with No Plan there are no SSRCs = and MSIDs in the SDP that comes from the
    > browser.

    OK

    =
    >> * Later, during the conference, I call to another 6th particip= ant and
    >> enter him into the conference, so I need to send a re-I= NVITE to every
    >> participant with a modified version of the SDP (= note that this is SIP
    >> protocol, so I need to use SIP messages t= o carry the new info about
    >> SSRC/MSID and so on).
    >
    >= ;
    > That's the thing. You don't need that. In Jitsi we do exactly thi= s operation
    > with no Offer/Answer signalling. RTP carries enough inf= ormation to process
    > streams and we use upper layer signalling (4575= ) for things such as mapping
    > SSRCs to users=0A and announcing curre= nt participant list.

    That is much better than Plan A and Plan B.
    =


    BTW: What would happen in NoPlan if the remote (i.e. a SIP
    g= ateway/endpoing) sends you a re-INVITE for "hold" purposes and you
    pass = the SDP to your PC? or you should not pass the SDP to your PC?
    and if so= , what about if the SDP contains updated ICE candidates due
    to remote pe= er network mobility?



    Thanks a lot for your response.

    = --
    I=F1aki Baz Castillo
    <ibc@aliax.net>
    _______________________________________________
    rtcweb mailing= list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb



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


    = ---1470824145-1261249343-1371808571=:86034-- From ibc@aliax.net Fri Jun 21 03:19:26 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC9B11E817D for ; Fri, 21 Jun 2013 03:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7d7ij0GR4qp for ; Fri, 21 Jun 2013 03:19:25 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id B7CDE11E8173 for ; Fri, 21 Jun 2013 03:19:25 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id cm16so406779qab.7 for ; Fri, 21 Jun 2013 03:19:25 -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=MtLoh2viYD0ln4i65DhwIFhnGHvhn61tfUhUnNBFEXo=; b=Lzx4A+h1ks4VbMZhFyzAENOHYPVXV8VVFHRQkqfMoFcQEFiRvAuFU9QvRknf4bX+XM HF7t+eWJHqWi8MnIkA2NbnfGk8qpLKUBrMhYJ1ud7n491LUMMgFqeVqeH1bOWbYixuqZ vg8K5dyzbxopf+wuQsx2S7ZgASMfYNjhQr96doUmx/9s9BfMK7X7t4zhEVGnWUXPFJhQ pF20U1QLaYBkC/0jNLM/Zl9GvXXyayRFqIrTn2HVKAHcd2U4wsfl/LjUvDkEpQz+D5OC AvpokSLZrh2x0c9ro+L8xfbzjzP5t2msjo6nlL/8YfZ8rlIYuuGTusuzwvuCbn/DjThk E8eQ== X-Received: by 10.49.24.52 with SMTP id r20mr13600675qef.54.1371809965230; Fri, 21 Jun 2013 03:19:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Fri, 21 Jun 2013 03:19:05 -0700 (PDT) In-Reply-To: <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 21 Jun 2013 12:19:05 +0200 Message-ID: To: Bossiel thioriguel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn5py/R3IQTq6PqnxpoMG0er+5jzSpHSfXlKerMR8IO+MFeLB9OkNysz/z4JLMU1JkL+Vy/ Cc: "diopmamadou@doubango.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 10:19:26 -0000 2013/6/21 Bossiel thioriguel : > Using the current WebRTC we have managed to *easily* build almost all kin= d > of applications: click-to-call, SIP/IMS clients, gateways to PSTN, MCUs, > Telemedicine systems...and haven't seen any major issue. It's true that i= t's > not natural to "hack" a blob SDP to implement features like hold/resume, > media update, early media ... but it works and there are demo application= s > showing it. Hi Bossiel, Current WebRTC is based on SDP mainly for "SIP interoperability", so obviously it is "easy" to build like-SIP-based applications. Anyhow in most of the apps you mean I'm pretty sure that there are just a few SDP exchanges, probably just the initial SDP offer/answer and some other for "hold" / "unhold" purposes (which requires SDP mangling). Now let's assume that WebRTC is much more than SIP-business-into-the-web, let's assume that WebRTC is RTC for the Web rather than Web for RTC. > For the current WebRTC, Google open sourced their engine, produced drafts= , a working implementation in chrome, a mailing-list to help developers, de= mo applications, documentation... we just want to see the same from any com= pany asking to rewrite everything. A company? AFAIK this is a IETF WG, not a company. I am not speaking on behalf of any company or business. Is there anyone not involved in SIP/PSTN business which feels comfortable with the SDP-based specs of WebRTC? Best regards. -- I=C3=B1aki Baz Castillo From andrew.hutton@siemens-enterprise.com Fri Jun 21 03:32:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A89D21F9F81 for ; Fri, 21 Jun 2013 03:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFifB2TAmwbK for ; Fri, 21 Jun 2013 03:32:33 -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 10A4411E8112 for ; Fri, 21 Jun 2013 03:32:33 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id E357023F0456; Fri, 21 Jun 2013 12:32:31 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Fri, 21 Jun 2013 12:32:31 +0200 From: "Hutton, Andrew" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Bossiel thioriguel" Thread-Topic: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Thread-Index: AQHObmjByY7ZqkO+CkSPIPqSfmn6rpk/9zkg Date: Fri, 21 Jun 2013 10:32:31 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115D4A59@MCHP04MSX.global-ad.net> References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> 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: "diopmamadou@doubango.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 10:32:38 -0000 T246IDIxIEp1bmUgMjAxMyAxMToxOSBJw7Fha2kgQmF6IENhc3RpbGxvIFdyb3RlOg0KPiANCj4g DQo+IElzIHRoZXJlIGFueW9uZSBub3QgaW52b2x2ZWQgaW4gU0lQL1BTVE4gYnVzaW5lc3Mgd2hp Y2ggZmVlbHMNCj4gY29tZm9ydGFibGUgd2l0aCB0aGUgU0RQLWJhc2VkIHNwZWNzIG9mIFdlYlJU Qz8NCj4gDQpJdCBzZWVtcyB0aGF0IEJvc3NpZWwncyAxNCB5ZWFyIG9sZCBuZXBoZXcgaXMgcXVp dGUgY29tZm9ydGFibGUgd2l0aCBpdC4NCg0KV2hpY2ggbWVhbnMgd2UgaGF2ZSBub3QgYmVlbiBh cyB1bnN1Y2Nlc3NmdWwgYXMgcGVvcGxlIHNlZW0gdG8gdGhpbmsuDQoNCkFuZHkNCg== From andrew.hutton@siemens-enterprise.com Fri Jun 21 03:55:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189BB21E80EE for ; Fri, 21 Jun 2013 03:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhLq8VJXAkYj for ; Fri, 21 Jun 2013 03:55:14 -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 A6BE311E8115 for ; Fri, 21 Jun 2013 03:55:13 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id C0D431EB85C8; Fri, 21 Jun 2013 12:55:12 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Fri, 21 Jun 2013 12:55:12 +0200 From: "Hutton, Andrew" To: Bossiel thioriguel , "diopmamadou@doubango.org" Thread-Topic: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Thread-Index: AQHObmNMyY7ZqkO+CkSPIPqSfmn6rpk/+Oug Date: Fri, 21 Jun 2013 10:55:12 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115D4A97@MCHP04MSX.global-ad.net> References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> In-Reply-To: <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 10:55:18 -0000 Thanks for this message I especially like the part about your 14 year old n= ephew writing WebRTC applications and I think we should take this as a sign= of at least some success. I have seen over the last year many demo's of WebRTC based applications dev= eloped both by major companies and by individuals some of which I assume kn= ow either nothing or very little about SDP. The problems we are having in the IETF seem to be that we have lost sight o= f the original goals and got bogged down with the very complex requirements= of some IETF participants. I think it very likely that Bossiel's nephew i= s not very concerned about SSRC signaling and bundling and actually none of= the very innovative WebRTC applications I have seen over the last year hav= e needed these. However he probably will be concerned when his application = does not work from his hotel or his office when he starts work.=20 It just goes to show we have been diverted from what is really needed to co= mplete WebRTC 1.0. Let's concentrate on making sure all those innovative apps already written = deployable before we start trying to satisfy the requirements of the mega a= pplication developers. Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Bossiel thioriguel > Sent: 21 June 2013 10:40 > To: diopmamadou@doubango.org > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re- > opened >=20 > Hello, >=20 > I'm registered on this group since the beginning but this is my first > post on this thread. So, I presente myself: Mamadou DIOP and I'm > working for Doubango Telecom where we're building SIP endpoints, > gateways, TelePresence/Telemedicine systems... all focused on > SIP/IMS/LTE/RCS-e and open source. >=20 > What I'm talking about is not just feeling but something I've > experienced. >=20 > Using the current WebRTC we have managed to *easily* build almost all > kind of applications: click-to-call, SIP/IMS clients, gateways to PSTN, > MCUs, Telemedicine systems...and haven't seen any major issue. It's > true that it's not natural to "hack" a blob SDP to implement features > like hold/resume, media update, early media ... but it works and there > are demo applications showing it. If there is something more beautiful > we just want to see it in action and test it. >=20 > Many participants here have said that what they want is something close > to CU-RTC-WEB. Don't really know if they tried to build applications > using it or not but in my case I have. > My > reference:=A0http://html5labs.interoperabilitybridges.com/prototypes/cu- > rtc-web-roaming/cu-rtc-web-roaming/info > First on Windows 8 but haven't gone far as there is no documentation to > get started. Then, OSX and=A0luckily=A0there was a readme with two links > for testing (only one work). You need to open 3 pages (1 master, 2 > slaves) and check "send audio" on both slaves to header sound. Many > javascript files and no documentation. It's said on these blogs that > interop with SIP networks is easy but it's not my feeling ...I just > want to see one :) >=20 > I don't really understand the issue with the O/A model. SDP or not SDP > you'll always offer something and answer something. I'm I missing? >=20 > For the current WebRTC, Google open sourced their engine, produced > drafts, a working implementation in chrome, a=A0mailing-list to help > developers, demo applications, documentation... we just want to see the > same from any company asking to rewrite everything. >=20 > I'm not saying the current WebRTC implementation is perfect but I have > seen my 14 year old=A0nephew developing an audio/video chat for his > homework :) >=20 > Regards >=20 > ________________________________________ > De=A0: I=F1aki Baz Castillo > =C0=A0: Emil Ivov > Cc=A0: "rtcweb@ietf.org" > Envoy=E9 le : Vendredi 21 juin 2013 1h24 > Objet=A0: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened >=20 > 2013/6/21 Emil Ivov : > > > > On 20.06.13, 23:49, I=F1aki Baz Castillo wrote: > >> > >> In JsSIP we are getting frustrated trying to implement the "hold" / > >> "unhold" feature because it requires SDP parsing and mangling. > Sending > >> a re-INVITE with a modified SDP (now with a video track enabled) > seems > >> to work (after lot of pain) but we still miss a reliable API to know > >> what the new SDP means. Instead we need to parse the SDP to detect > >> global (or per m=3D) line attributes like "a=3Dinactive" or "a=3Dsendo= nly" > >> etc etc. It's really painful. > > > > > > I am having a problem following what you are trying to achieve here. > In > > JsSIP you seem to be going for a full SIP implementation in the > browser. If > > this is true and if this WG decides to remove SDP from the API > surface, then > > you would need to completely parse SDP in the JS and then convert it > into > > API calls. Similarly, when creating offers and answers you would need > to > > construct SDP all by yourself. >=20 > And we will do it very happily because then we will know what > *exactly* we are sending on-the-wire. >=20 >=20 >=20 >=20 > > So I am not sure why the SDP parsing in the current situation is so > much of > > a blocker for your use case. >=20 > Because regardless I am a SIP-guy, I understand that the main mission > of WebRTC is to provide realtime communications *for* the WWW, and not > to enable a new interface for like-telephony-bussines. >=20 > Today I'm doing SIP. Tomorrow I may be doing > [[put_here_a_future_RTC_protocol_not_based_on_SDP]] and then I don't > want to be constrained by decisions made today that force any future > RTC protocol to deal with SDP O/A model. >=20 > :) >=20 >=20 >=20 > >> BTW I don't know wheter you support PlanA, PlanB or NoPlan, but I > did > >> a question (in this case about NoPlan) for which I got no response, > >> and honestly I would like to see it replied regardless the solution > >> uses PlanA, PlanB or NoPlan model: > >> > >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07871.html > >> > > The other option would be indeed to do the same thing in JS. I > believe this > > is JsSIP's use case. In that case however, regardless of whether you > choose > > Plan A, Plan B, No Plan or CU-RTC-Web, you will inevitably be exposed > to a > > fair amount of complexity, parsing and JS magic. > > > > You are, after all, building a SIP stack. >=20 > Yes, but JsSIP creates its own SIP messages to be sent in the wire, so > we have full control over *what* we create and send. Those SIP > messages are not provided by the WebRTC API. But for the SDP > component, JsSIP retreives a SDP blob string from the PC. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > > > In the above mail you also say: > > > >> Another example: > >> > >> * I am a powerful SIP conference server which properly implements > >> WebRTC. I initiate a call to 5 users (running JS SIP app in their > >> browsers). The initial INVITE has SSRC/MSID fields in the SDP > >> identifying all the participants, am I right? > > > > > > No, with No Plan there are no SSRCs and MSIDs in the SDP that comes > from the > > browser. >=20 > OK >=20 >=20 > >> * Later, during the conference, I call to another 6th participant > and > >> enter him into the conference, so I need to send a re-INVITE to > every > >> participant with a modified version of the SDP (note that this is > SIP > >> protocol, so I need to use SIP messages to carry the new info about > >> SSRC/MSID and so on). > > > > > > That's the thing. You don't need that. In Jitsi we do exactly this > operation > > with no Offer/Answer signalling. RTP carries enough information to > process > > streams and we use upper layer signalling (4575) for things such as > mapping > > SSRCs to users and announcing current participant list. >=20 > That is much better than Plan A and Plan B. >=20 >=20 >=20 > BTW: What would happen in NoPlan if the remote (i.e. a SIP > gateway/endpoing) sends you a re-INVITE for "hold" purposes and you > pass the SDP to your PC? or you should not pass the SDP to your PC? > and if so, what about if the SDP contains updated ICE candidates due > to remote peer network mobility? >=20 >=20 >=20 > Thanks a lot for your response. >=20 > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From robin@hookflash.com Fri Jun 21 05:18:21 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B1721E80FF for ; Fri, 21 Jun 2013 05:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNJGObr36CUI for ; Fri, 21 Jun 2013 05:18:19 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF2D21E8104 for ; Fri, 21 Jun 2013 05:18:14 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id a13so18369017iee.6 for ; Fri, 21 Jun 2013 05:18: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:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=Vml3u1mFJ3NaexhCXc3l/5u8FXMJnlNtusZg6aD2f3g=; b=Jm7+hM9Sxz49YVkri3mGxIEONF8eTKZucmo+iOj5QeFGVZcpn03yviOxFhSDpodxEp gRQSUNd7MM3OuLAZ9MrrsO83iOuctwjq2qdSAr+eLX6V0J4Jgy5AbZFwpkCuvxabS3Mh e7yZXneL9Xct8nLtOB/6v6sN07WYtborlGV3NOkBMuTOxYQJdxXBLvS12WfhoWsO8F8Z 5s6HwpFI0Pcq3ktNp9kihGo3MGt5YstU1ywiJk3L8Phc6tM9zmQkxNv2oRmipTumGJmM XRsgJGbB/SNxGxvfLVDGCdAdFFUg5uNEygGqFVMlfM0nIWt2Zu/rF11CJ81C6pspTJ2u yQCQ== X-Received: by 10.43.51.68 with SMTP id vh4mr5872894icb.52.1371817087667; Fri, 21 Jun 2013 05:18:07 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id j3sm4876655igv.4.2013.06.21.05.18.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 05:18:06 -0700 (PDT) Message-ID: <51C4447B.6020709@hookflash.com> Date: Fri, 21 Jun 2013 08:18:03 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Bossiel thioriguel References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> In-Reply-To: <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> Content-Type: multipart/alternative; boundary="------------060508040202090902020409" X-Gm-Message-State: ALoCoQnZ7aJlQqUnFwfTnxlPRPBZuXbYO4iUApFVdeBIEIh83XSqLu6SI70tukGxoobznsjI5VLU Cc: "diopmamadou@doubango.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 12:18:21 -0000 This is a multi-part message in MIME format. --------------060508040202090902020409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Your point about it being easy to get a demo running I agree, or even interfacing with a SIP network. I can't comment on the difficulty or not of CU-RTCWeb's implementation. It does look like CU-RTCWeb has a lot of features/complexity out of the gate which is necessary to do a lot of alternative scenarios but might cause someone to through up their hands in frustration trying to figure out how it all works, especially if you are an integrator of SIP and not an implementer. I conquer whatever solution adopted must be equally as easy for SIP developers (even though that is not part of the mandate as I understand it). That's why I proposed that I would take it upon myself to lead an API proposal that could work for both. The simple "SIP/SDP" case being provided as a shim that you could write against if you are a SIP integrator (close to the current webrtc as reasonable) but something that doesn't break other non-SIP models. Let me explain why offer/answer breaks other models. Offer/answer negotiates akin to "I send out an offer, but whatever you agree on from my offer we will use together". Further "if you disagree with my offer, we'll roll back to the existing offer". Finally "if we both make an offer at the same time, we'll conflict and we'll have to use conflict resolution to change our offers". That was true of when I last authored X-Lite/X-PRO SIP softphone client so perhaps something has changed since then to which I'm not aware, but that's my gross simplification of offer/answer. However, that is absolutely _not_ the only way to negotiate. For example, Open Peer for example uses constraints based negotiation. This is akin to "if you send me anything, please send me this". The difference is that each side is allowed to change what it expects to receive without a round trip to the remote party agreeing and without risk of rollback. That makes it really easy to update and change what you expect without needing the complexities of an offer/answer state machine. If one is forced upon us, we'll have to find away around this offer/answer mechanism because negotiating is not an option for us - we simply don't do it at all. Whatever we do to hack around it will likely violate the offer/answer rules. Offer/answer is wholly not necessary to be mandated as part of WebRTC to fulfill the charter but it currently is mandated. I don't want something just for "me", but we are forcing an unneeded model of negotiation upon JavaScript developers that may not want to adhere to that model either (and likely will violate it too, albeit unintentionally). Skype has similar objections to offer/answer but I can't speak to their negotiation strategy or presume to speak on their behalf. If offer/answer were removed as a mandate, you can do so yourself in your JavaScript without browser enforcement. My other issue is that SDP has become an API surface for control, properties and extensions. We must remember that the consumer of what we produce must be acceptable to the W3C and their members (browser and JavaScript implementers) and not SIP integrators. If we are asking JavaScript developers to hack/mangle the SDP to do anything beyond "place/answer" a call, we are forcing them to learn an entirely new ill-defined language called SDP rather than just using a JavaScript API which is native to their language constructs. If we are saying "people shouldn't touch the SDP nor need to" then why not have a binary format for the blob exchange that is untouchable? The reason we don't encode to binary is because we _expect_ people to have to mangle the SDP. That's simply not acceptable in my mind to require JavaScript developers to learn SDP. Perhaps this is outside the charter, but I don't think it's inside the charter either to mandate learning SDP to perform common edge case actions either (e.g. putting media on hold). There's a huge gray area here and effectively we are coming up with their API for the W3C called "SDP". Should we fail to provide a respectable API, they will reject what we have anyway and likely they will not come up with SDP as their solution (plus WebRTC will take another delay and blow). The next issue is that SDP is not a well defined format. There is no 100% sure way to write SDP to be compatible. This means that if we do have to mangle SDP, we'll have to do browser, version and platform detection to pre-determine what exact formats the SDP will generate/parses and have compatibilities for each. We must or we will break. This goes against browser philosophy entirely. The IETF might not care about that but the W3C will care. But we should care too because we cannot be sure that the next browser version update on some random platform won't just suddenly break any implementation. What we write will expect a certain syntax, and will break and there's no mandate that browser vendors come back to us for approval of their extensions they want/need. This will make implementations brittle. The final thing that scares me is all the extensions being proposed to make this SDP, for example, BUNDLE. Nothing wrong with the concepts at all! But should some vendors start adopting some of these extensions (or fork the browser code base to support these extensions), we'll see environments where the SDP produced is massively complex, unknown and "special". This will be entirely legal since anything goes with SDP but will wholly break likely everything that doesn't know about those extensions, except those involved in producing those extensions. No longer will this be the open web, but a closed web tied to certain vendors via extensions. This isn't just some theoretical issue. This is already underway with an avalanche with many requests / demands being put upon the various browser vendors all with their own competing interests / alliances. With an API model, extensions can be added as additional API, without breaking anyone. If you use the "basic" API, you get the same behaviours you expect as always even if new features are added later. If you use additional APIs, only then do you get the advanced features for the API you know about. With SDP, you don't know because their's nothing restricting exactly what the SDP expresses locally in advance nor what you will receive from a remote party. Finally, by baking the SDP into the browser, you make it unchangeable. If there was issues with the SDP generated/parsing, you'll have to mangle the SDP from JavaScript (or from an SBC) to make it work (and you will need browser version detection to do that which is something the browser vendors are fighting hard to prevent). Were it instead written as a JavaScript shim, you could tweak the shim code yourself for whatever compatibility you need without waiting for the next browser update to fix the issue. Baked in the browser, you are out of luck. This is why I'm proposing we have a reasonable API for JavaScript using their language constructs they already know and are familiar that is extensible for the future without more SDP mangling/extensions. Those who want to do SDP extensions can do it inside an updatable shim, which can be tailored to your specific SIP environment to be 100% compatible with little to no risk the browser vendors will break you. I fully appreciate the need that whatever API is produced is not needlessly complex and to ensure the absolutely dead-easy implementation exist. I plan to satisfy the dead-easy situation by providing a shim written entirely in JavaScript that provides that "80%" of what people want, i.e. the current WebRTC API which is easy starting point for many SIP integrators. Those of us who in the 20% who don't use SIP can bypass (or modify) the shim to do what they want/need. So I ask you, if I were to propose such a solution (and provide examples), would you be open minded to using a shim that provides your easy use case rather than forcing SDP inside of SDP being baked into browser binary? Do you also understand my objections to using SDP with offer/answer? -Robin > Bossiel thioriguel > 21 June, 2013 5:40 AM > Hello, > > I'm registered on this group since the beginning but this is my first > post on this thread. So, I presente myself: Mamadou DIOP and I'm > working for Doubango Telecom where we're building SIP endpoints, > gateways, TelePresence/Telemedicine systems... all focused on > SIP/IMS/LTE/RCS-e and open source. > > What I'm talking about is not just feeling but something I've experienced. > > Using the current WebRTC we have managed to *easily* build almost all > kind of applications: click-to-call, SIP/IMS clients, gateways to > PSTN, MCUs, Telemedicine systems...and haven't seen any major issue. > It's true that it's not natural to "hack" a blob SDP to implement > features like hold/resume, media update, early media ... but it works > and there are demo applications showing it. If there is something more > beautiful we just want to see it in action and test it. > > Many participants here have said that what they want is something > close to CU-RTC-WEB. Don't really know if they tried to build > applications using it or not but in my case I have. > My > reference: http://html5labs.interoperabilitybridges.com/prototypes/cu-rtc-web-roaming/cu-rtc-web-roaming/info > First on Windows 8 but haven't gone far as there is no documentation > to get started. Then, OSX and luckily there was a readme with two > links for testing (only one work). You need to open 3 pages (1 master, > 2 slaves) and check "send audio" on both slaves to header sound. Many > javascript files and no documentation. It's said on these blogs that > interop with SIP networks is easy but it's not my feeling ...I just > want to see one :) > > I don't really understand the issue with the O/A model. SDP or not SDP > you'll always offer something and answer something. I'm I missing? > > For the current WebRTC, Google open sourced their engine, produced > drafts, a working implementation in chrome, a mailing-list to help > developers, demo applications, documentation... we just want to see > the same from any company asking to rewrite everything. > > I'm not saying the current WebRTC implementation is perfect but I have > seen my 14 year old nephew developing an audio/video chat for his > homework :) > > Regards > --------------060508040202090902020409 Content-Type: multipart/related; boundary="------------020401080905020609090604" --------------020401080905020609090604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    Your point about it being easy to get a demo running I agree, or even interfacing with a SIP network.

    I can't comment on the difficulty or not of CU-RTCWeb's implementation. It does look like CU-RTCWeb has a lot of features/complexity out of the gate which is necessary to do a lot of alternative scenarios but might cause someone to through up their hands in frustration trying to figure out how it all works, especially if you are an integrator of SIP and not an implementer.

    I conquer whatever solution adopted must be equally as easy for SIP developers (even though that is not part of the mandate as I understand it). That's why I proposed that I would take it upon myself to lead an API proposal that could work for both. The simple "SIP/SDP" case being provided as a shim that you could write against if you are a SIP integrator (close to the current webrtc as reasonable) but something that doesn't break other non-SIP models.

    Let me explain why offer/answer breaks other models. Offer/answer negotiates akin to "I send out an offer, but whatever you agree on from my offer we will use together". Further "if you disagree with my offer, we'll roll back to the existing offer". Finally "if we both make an offer at the same time, we'll conflict and we'll have to use conflict resolution to change our offers". That was true of when I last authored X-Lite/X-PRO SIP softphone client so perhaps something has changed since then to which I'm not aware, but that's my gross simplification of offer/answer.

    However, that is absolutely _not_ the only way to negotiate. For example, Open Peer for example uses constraints based negotiation. This is akin to "if you send me anything, please send me this". The difference is that each side is allowed to change what it expects to receive without a round trip to the remote party agreeing and without risk of rollback. That makes it really easy to update and change what you expect without needing the complexities of an offer/answer state machine. If one is forced upon us, we'll have to find away around this offer/answer mechanism because negotiating is not an option for us - we simply don't do it at all. Whatever we do to hack around it will likely violate the offer/answer rules.

    Offer/answer is wholly not necessary to be mandated as part of WebRTC to fulfill the charter but it currently is mandated. I don't want something just for "me", but we are forcing an unneeded model of negotiation upon JavaScript developers that may not want to adhere to that model either (and likely will violate it too, albeit unintentionally). Skype has similar objections to offer/answer but I can't speak to their negotiation strategy or presume to speak on their behalf. If offer/answer were removed as a mandate, you can do so yourself in your JavaScript without browser enforcement.

    My other issue is that SDP has become an API surface for control, properties and extensions. We must remember that the consumer of what we produce must be acceptable to the W3C and their members (browser and JavaScript implementers) and not SIP integrators. If we are asking JavaScript developers to hack/mangle the SDP to do anything beyond "place/answer" a call, we are forcing them to learn an entirely new ill-defined language called SDP rather than just using a JavaScript API which is native to their language constructs.

    If we are saying "people shouldn't touch the SDP nor need to" then why not have a binary format for the blob exchange that is untouchable? The reason we don't encode to binary is because we _expect_ people to have to mangle the SDP. That's simply not acceptable in my mind to require JavaScript developers to learn SDP. Perhaps this is outside the charter, but I don't think it's inside the charter either to mandate learning SDP to perform common edge case actions either (e.g. putting media on hold). There's a huge gray area here and effectively we are coming up with their API for the W3C called "SDP". Should we fail to provide a respectable API, they will reject what we have anyway and likely they will not come up with SDP as their solution (plus WebRTC will take another delay and blow).

    The next issue is that SDP is not a well defined format. There is no 100% sure way to write SDP to be compatible. This means that if we do have to mangle SDP, we'll have to do browser, version and platform detection to pre-determine what exact formats the SDP will generate/parses and have compatibilities for each. We must or we will break. This goes against browser philosophy entirely. The IETF might not care about that but the W3C will care. But we should care too because we cannot be sure that the next browser version update on some random platform won't just suddenly break any implementation. What we write will expect a certain syntax, and will break and there's no mandate that browser vendors come back to us for approval of their extensions they want/need. This will make implementations brittle.

    The final thing that scares me is all the extensions being proposed to make this SDP, for example, BUNDLE. Nothing wrong with the concepts at all! But should some vendors start adopting some of these extensions (or fork the browser code base to support these extensions), we'll see environments where the SDP produced is massively complex, unknown and "special". This will be entirely legal since anything goes with SDP but will wholly break likely everything that doesn't know about those extensions, except those involved in producing those extensions. No longer will this be the open web, but a closed web tied to certain vendors via extensions. This isn't just some theoretical issue. This is already underway with an avalanche with many requests / demands being put upon the various browser vendors all with their own competing interests / alliances.

    With an API model, extensions can be added as additional API, without breaking anyone. If you use the "basic" API, you get the same behaviours you expect as always even if new features are added later. If you use additional APIs, only then do you get the advanced features for the API you know about. With SDP, you don't know because their's nothing restricting exactly what the SDP expresses locally in advance nor what you will receive from a remote party.

    Finally, by baking the SDP into the browser, you make it unchangeable. If there was issues with the SDP generated/parsing, you'll have to mangle the SDP from JavaScript (or from an SBC) to make it work (and you will need browser version detection to do that which is something the browser vendors are fighting hard to prevent). Were it instead written as a JavaScript shim, you could tweak the shim code yourself for whatever compatibility you need without waiting for the next browser update to fix the issue. Baked in the browser, you are out of luck.

    This is why I'm proposing we have a reasonable API for JavaScript using their language constructs they already know and are familiar that is extensible for the future without more SDP mangling/extensions. Those who want to do SDP extensions can do it inside an updatable shim, which can be tailored to your specific SIP environment to be 100% compatible with little to no risk the browser vendors will break you.

    I fully appreciate the need that whatever API is produced is not needlessly complex and to ensure the absolutely dead-easy implementation exist. I plan to satisfy the dead-easy situation by providing a shim written entirely in JavaScript that provides that "80%" of what people want, i.e. the current WebRTC API which is easy starting point for many SIP integrators. Those of us who in the 20% who don't use SIP can bypass (or modify) the shim to do what they want/need.

    So I ask you, if I were to propose such a solution (and provide examples), would you be open minded to using a shim that provides your easy use case rather than forcing SDP inside of SDP being baked into browser binary? Do you also understand my objections to using SDP with offer/answer?

    -Robin

    21 June, 2013 5:40 AM
    Hello,

    I'm registered on this group since the beginning but this is my first post on this thread. So, I presente myself: Mamadou DIOP and I'm working for Doubango Telecom where we're building SIP endpoints, gateways, TelePresence/Telemedicine systems... all focused on SIP/IMS/LTE/RCS-e and open source.

    What I'm talking about is not just feeling but something I've experienced.

    Using the current WebRTC we have managed to *easily* build almost all kind of applications: click-to-call, SIP/IMS clients, gateways to PSTN, MCUs, Telemedicine systems...and haven't seen any major issue. It's true that it's not natural to "hack" a blob SDP to implement features like hold/resume, media update, early media ... but it works and there are demo applications showing it. If there is something more beautiful we just want to see it in action and test it.

    Many participants here have said that what they want is something close to CU-RTC-WEB. Don't really know if they tried to build applications using it or not but in my case I have.
    First on Windows 8 but haven't gone far as there is no documentation to get started. Then, OSX and luckily there was a readme with two links for testing (only one work). You need to open 3 pages (1 master, 2 slaves) and check "send audio" on both slaves to header sound. Many javascript files and no documentation. It's said on these blogs that interop with SIP networks is easy but it's not my feeling ...I just want to see one :)

    I don't really understand the issue with the O/A model. SDP or not SDP you'll always offer something and answer something. I'm I missing?

    For the current WebRTC, Google open sourced their engine, produced drafts, a working implementation in chrome, a mailing-list to help developers, demo applications, documentation... we just want to see the same from any company asking to rewrite everything.

    I'm not saying the current WebRTC implementation is perfect but I have seen my 14 year old nephew developing an audio/video chat for his homework :)

    Regards

    --------------020401080905020609090604 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------020401080905020609090604-- --------------060508040202090902020409-- From ibc@aliax.net Fri Jun 21 06:09:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5EE21E810E for ; Fri, 21 Jun 2013 06:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.662 X-Spam-Level: X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYVKPslL7jRI for ; Fri, 21 Jun 2013 06:09:17 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id AB38921E8106 for ; Fri, 21 Jun 2013 06:09:17 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id f14so524647qak.7 for ; Fri, 21 Jun 2013 06:09:16 -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=5Uh0KcJswBnWjp3zaXVxDo/3OcT+l1mTqW6dxZ+Sqtw=; b=CGDQ8fBN6Oe+15w8eHVf8ATTk0tkRWb18SUbi2u0eOwNXkyqENit7s6uiR8USXE5F+ v/66VJ39UFM6BXQDsQJYXXphPuL9KM+qRDXvZJRAr2ULubf5NTwFeshGdiU0BRxH5Wjh X5xzTcqq80BWGHujDLQRvs2BUPs/O5BU/umAfJVQ0BhqcciqskAAHmpArEiB7rAspXwu OdiVF/DbNlcmfnqEp3POjQgy95qNEWnldGsYrsOjEBWnzidG3enYpO4ATO+RViQW7dAZ r9qLzJkXYe77x7IpG/M2tPZbR95dvy/EDz2Oauk7MJc6HNE5RFQdjwtJgAsyRWnODr3l XTZw== X-Received: by 10.49.35.108 with SMTP id g12mr5481331qej.86.1371820156152; Fri, 21 Jun 2013 06:09:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Fri, 21 Jun 2013 06:08:55 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115D4A97@MCHP04MSX.global-ad.net> References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> <9F33F40F6F2CD847824537F3C4E37DDF115D4A97@MCHP04MSX.global-ad.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 21 Jun 2013 15:08:55 +0200 Message-ID: To: "Hutton, Andrew" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmie3/XHY/BBrrAdl/PMjUNc8/Pj65H6pX0q0k6uQ2Njxn86itVeJDA6O2BemMl1RQD3IQH Cc: "diopmamadou@doubango.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 13:09:18 -0000 2013/6/21 Hutton, Andrew : > Let's concentrate on making sure all those innovative apps already writte= n deployable before we start trying to satisfy the requirements of the mega= application developers. As said before, if WebRTC 1.0 borns with SDP O/A inside, WebRTC 2.0 will also (given the "backward compatibility" and given that WebRTC 1.0 will be a real standard, rather than the tons of draft we have today). -- I=C3=B1aki Baz Castillo From gonzalo.camarillo@ericsson.com Fri Jun 21 07:02:12 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7881A11E818C for ; Fri, 21 Jun 2013 07:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.065 X-Spam-Level: X-Spam-Status: No, score=-106.065 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEbtplKBwU0B for ; Fri, 21 Jun 2013 07:02:07 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C59F621F9BF6 for ; Fri, 21 Jun 2013 07:02:06 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-c5-51c45cdd1752 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 0B.C1.09795.DDC54C15; Fri, 21 Jun 2013 16:02:05 +0200 (CEST) Received: from [131.160.126.58] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Fri, 21 Jun 2013 16:02:05 +0200 Message-ID: <51C45CDC.1070401@ericsson.com> Date: Fri, 21 Jun 2013 17:02:04 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51C157BA.70509@ericsson.com> In-Reply-To: <51C157BA.70509@ericsson.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <51C157BA.70509@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3VvduzJFAg9t3pCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRl/3QaaC1cIVn55NZWxgfMTfxcjJISFgIvH8Sh8zhC0mceHe ejYQW0jgFKPEhn1cEPYaRonzGzRBbF4BbYmTJ38ydTFycLAIqEqcnusOEmYTsJDYcus+C4gt KhAlMWfdAzaIckGJkzOfgMVFBIQltr7qZQKxhQXsJVqXv2SCGK8p0fcWIs4poCUxd9tXVohz JCW2vGhnB1klIWAqsewP2CpmAT2JKVdbGCFseYntb+cwQ4zRllj+rIVlAqPQLCSbZyFpmYWk ZQEj8ypG9tzEzJz0cvNNjMCAPLjlt8EOxk33xQ4xSnOwKInzfjq1K1BIID2xJDU7NbUgtSi+ qDQntfgQIxMHp1QDo8D2/rnMhV+7tuW/kgzbkxaRvCX70e8Ip8I7v9+ra/Hu2ZyXUquqVHqJ lfFOSXpo6w2NTMUlKwSDntYeyn6o+2vOh/gO02X7b1zyDPsTLNd5mt1wh9nm7EdTzq/PPiKl IB0m8/uUQELfXk7t9TO7c1MnTi5r3Z9XIfKB7dNvy8Jfx47nnlymqcRSnJFoqMVcVJwIAHmc Is0WAgAA Subject: [rtcweb] Fwd: [RAI] RAI processes for handling work effectively X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 14:02:12 -0000 Folks, if you have any opinions on the following thread, which started with the email below, please send them to the RAI list: http://www.ietf.org/mail-archive/web/rai/current/msg01372.html Cheers, Gonzalo -------- Original Message -------- Subject: [RAI] RAI processes for handling work effectively Date: Wed, 19 Jun 2013 10:03:22 +0300 From: Gonzalo Camarillo To: Folks, as you know, in the RAI area we have always considered having effective processes to help us produce relevant and timely specifications a very important issue. When our environment has changed, we have sometimes modified or fine tuned our processes in order to continue being effective. A few examples (among many others) of such changes were the introduction of mentors, the old SIPPING process, P headers, and the current DISPATCH process. It is time for us to look at the current state of affairs and discuss whether or not we need to do certain things in a different way. In particular, we currently have a few groups (e.g., RTCWeb and CLUE) that work on higher-level constructions, which use elements developed in other working groups. For example, CLUE could potentially specify a mechanism that used mechanisms developed in MMUSIC or AVTEXT such as the offer/answer model and a number of RTP extensions. Note that what we called "higher-level constructions" above are referred to by different names by different people: architectures, applications, frameworks, etc. It does not really matter how we call them because this discussion is not about terminology and it is fairly clear what this type of work is about. The way this type of work is currently done in RAI requires the high-level WGs and the WGs developing the individual pieces to communicate often. Those communications are not always easy, since different WGs sometimes have different views on priorities, requirements, use cases, etc. What we would like to get your feedback on is: do we need a better way to handle this type of work in RAI or our current process is as good as it gets? Note that we are interested in getting constructive feedback and ideas on how to improve things. Please, focus your feedback on those aspects. Thanks, Gonzalo (on behalf of both RAI ADs) _______________________________________________ RAI mailing list RAI@ietf.org https://www.ietf.org/mailman/listinfo/rai From pthatcher@google.com Fri Jun 21 07:42:37 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5832F21F9EDC for ; Fri, 21 Jun 2013 07:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVjhwNZMMCx5 for ; Fri, 21 Jun 2013 07:42:36 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0064C21F9BC1 for ; Fri, 21 Jun 2013 07:42:35 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so7919545pab.27 for ; Fri, 21 Jun 2013 07:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UbUqiOoWaeEEMaawcWynskR7/a6N/lo1ptGAF/wyLeQ=; b=ClQuPAxldUfoe1r9CD9dSoIxmam2nOrPtHQRmgruXdTGXfi4U2yfCjBL2wHBdJb+WK T0yF9Um2ey0i+na+00uOMGMN4UXXIM5hWeDDRywWXb0HOInnd1npJEz3S5kGYObqi0UM UEsi4bpALpvCt6UqYnaBtVsHGdSR+2KqksI4MhzbfXGovt9Elf41wJ+Z+VPCl5NGI1b1 oEflDN/WKe/H+huLkGTdIj+Tu4WCWtCzlqYZZV6dRB3SwCRtrYSvCACzcsffoAEqwuhu S0FtMT35S8yzstsloQPH0wYbvho0vnp4UlGEwNLOhJiaJT0Uy/D/RdrFSpIg36Sqj8s2 LdAQ== 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=UbUqiOoWaeEEMaawcWynskR7/a6N/lo1ptGAF/wyLeQ=; b=X85tmXvaZV08B6o/uNeQH4lQNGWrPQ0+AcDQ28Vf5jSBYyXcZXiZPIdnkX4ZLHG0fR Aoqh26sCp01A1PlhY7Tey3GwwpGIPXk3zcqbEka81KlajVivfecrqinGRbkw123EDOV2 LDesAD0Hdxtaq1unDR+e3N1i3ZL3iOWHmGBa+YbqciEmckG4YYDxM5f57peRQ+CSttSa mrSVcSOtQ/63z42HsMWqTOePc/1iH/GxoB0hCJIii5AzDgol7At706LhAYZ1+96QKqw7 ui+FDlH9523kRRNlSjHZOCAPgGOo6YK6JJiF8rGax+IiHuMIYs1Te2NMI1J0AgmcPxwi 8pTg== MIME-Version: 1.0 X-Received: by 10.66.251.202 with SMTP id zm10mr16743232pac.53.1371825755271; Fri, 21 Jun 2013 07:42:35 -0700 (PDT) Received: by 10.66.88.8 with HTTP; Fri, 21 Jun 2013 07:42:35 -0700 (PDT) Received: by 10.66.88.8 with HTTP; Fri, 21 Jun 2013 07:42:35 -0700 (PDT) In-Reply-To: <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> Date: Fri, 21 Jun 2013 07:42:35 -0700 Message-ID: From: Peter Thatcher To: Bossiel thioriguel Content-Type: multipart/alternative; boundary=047d7b15a385d6479604dfab1227 X-Gm-Message-State: ALoCoQmwXDGD4xu4MHgGgBWeuiBw70DxCSN9Z/UwspoGz254rS0deVNH2IO3w+VnXtus9Fz0mvNqwTLtP7m+YTGN4LUu08CyHG4SuTx1ZPJw+haj6/GFBcI7PPw68oseWQFKO5NDLgtXua8k5sSRDI2RYJ/UAT1ZbUyTXpkLrJqorzvrdW0lPrJQabcE/GM+SDH0HsH0MeII Cc: diopmamadou@doubango.org, rtcweb@ietf.org Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 14:42:37 -0000 --047d7b15a385d6479604dfab1227 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Do you work with video or just audio? Do you work with multiple streams/tracks, both send and receive? Do you use features such as rtx, fec, and simulcast? Simple, single-track, audio-only clients that use SDP for signalling over the wire are fairly well served by the current API, as are clients only using the data channel. But doing more advanced things, such as those I mention, require significant SDP munging which can be a very slow and error-prone experience. Your experience may differ from others because they are trying to do things that require a lot more SDP munging, which can be quite painful. On Jun 21, 2013 2:40 AM, "Bossiel thioriguel" wrote: > Hello, > > I'm registered on this group since the beginning but this is my first pos= t > on this thread. So, I presente myself: Mamadou DIOP and I'm working for > Doubango Telecom where we're building SIP endpoints, gateways, > TelePresence/Telemedicine systems... all focused on SIP/IMS/LTE/RCS-e and > open source. > > What I'm talking about is not just feeling but something I've experienced= . > > Using the current WebRTC we have managed to *easily* build almost all kin= d > of applications: click-to-call, SIP/IMS clients, gateways to PSTN, MCUs, > Telemedicine systems...and haven't seen any major issue. It's true that > it's not natural to "hack" a blob SDP to implement features like > hold/resume, media update, early media ... but it works and there are dem= o > applications showing it. If there is something more beautiful we just wan= t > to see it in action and test it. > > Many participants here have said that what they want is something close t= o > CU-RTC-WEB. Don't really know if they tried to build applications using i= t > or not but in my case I have. > My reference: > http://html5labs.interoperabilitybridges.com/prototypes/cu-rtc-web-roamin= g/cu-rtc-web-roaming/info > First on Windows 8 but haven't gone far as there is no documentation to > get started. Then, OSX and luckily there was a readme with two links for > testing (only one work). You need to open 3 pages (1 master, 2 slaves) an= d > check "send audio" on both slaves to header sound. Many javascript files > and no documentation. It's said on these blogs that interop with SIP > networks is easy but it's not my feeling ...I just want to see one :) > > I don't really understand the issue with the O/A model. SDP or not SDP > you'll always offer something and answer something. I'm I missing? > > For the current WebRTC, Google open sourced their engine, produced drafts= , > a working implementation in chrome, a mailing-list to help developers, de= mo > applications, documentation... we just want to see the same from any > company asking to rewrite everything. > > I'm not saying the current WebRTC implementation is perfect but I have > seen my 14 year old nephew developing an audio/video chat for his homewor= k > :) > > Regards > > ------------------------------ > *De :* I=C3=B1aki Baz Castillo > *=C3=80 :* Emil Ivov > *Cc :* "rtcweb@ietf.org" > *Envoy=C3=A9 le :* Vendredi 21 juin 2013 1h24 > *Objet :* Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened > > 2013/6/21 Emil Ivov : > > > > On 20.06.13, 23:49, I=C3=B1aki Baz Castillo wrote: > >> > >> In JsSIP we are getting frustrated trying to implement the "hold" / > >> "unhold" feature because it requires SDP parsing and mangling. Sending > >> a re-INVITE with a modified SDP (now with a video track enabled) seems > >> to work (after lot of pain) but we still miss a reliable API to know > >> what the new SDP means. Instead we need to parse the SDP to detect > >> global (or per m=3D) line attributes like "a=3Dinactive" or "a=3Dsendo= nly" > >> etc etc. It's really painful. > > > > > > I am having a problem following what you are trying to achieve here. In > > JsSIP you seem to be going for a full SIP implementation in the browser= . > If > > this is true and if this WG decides to remove SDP from the API surface, > then > > you would need to completely parse SDP in the JS and then convert it in= to > > API calls. Similarly, when creating offers and answers you would need t= o > > construct SDP all by yourself. > > And we will do it very happily because then we will know what > *exactly* we are sending on-the-wire. > > > > > > So I am not sure why the SDP parsing in the current situation is so muc= h > of > > a blocker for your use case. > > Because regardless I am a SIP-guy, I understand that the main mission > of WebRTC is to provide realtime communications *for* the WWW, and not > to enable a new interface for like-telephony-bussines. > > Today I'm doing SIP. Tomorrow I may be doing > [[put_here_a_future_RTC_protocol_not_based_on_SDP]] and then I don't > want to be constrained by decisions made today that force any future > RTC protocol to deal with SDP O/A model. > > :) > > > > >> BTW I don't know wheter you support PlanA, PlanB or NoPlan, but I did > >> a question (in this case about NoPlan) for which I got no response, > >> and honestly I would like to see it replied regardless the solution > >> uses PlanA, PlanB or NoPlan model: > >> > >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07871.html > >> > > The other option would be indeed to do the same thing in JS. I believe > this > > is JsSIP's use case. In that case however, regardless of whether you > choose > > Plan A, Plan B, No Plan or CU-RTC-Web, you will inevitably be exposed t= o > a > > fair amount of complexity, parsing and JS magic. > > > > You are, after all, building a SIP stack. > > Yes, but JsSIP creates its own SIP messages to be sent in the wire, so > we have full control over *what* we create and send. Those SIP > messages are not provided by the WebRTC API. But for the SDP > component, JsSIP retreives a SDP blob string from the PC. > > > > > > > > > > > In the above mail you also say: > > > >> Another example: > >> > >> * I am a powerful SIP conference server which properly implements > >> WebRTC. I initiate a call to 5 users (running JS SIP app in their > >> browsers). The initial INVITE has SSRC/MSID fields in the SDP > >> identifying all the participants, am I right? > > > > > > No, with No Plan there are no SSRCs and MSIDs in the SDP that comes fro= m > the > > browser. > > OK > > > >> * Later, during the conference, I call to another 6th participant and > >> enter him into the conference, so I need to send a re-INVITE to every > >> participant with a modified version of the SDP (note that this is SIP > >> protocol, so I need to use SIP messages to carry the new info about > >> SSRC/MSID and so on). > > > > > > That's the thing. You don't need that. In Jitsi we do exactly this > operation > > with no Offer/Answer signalling. RTP carries enough information to > process > > streams and we use upper layer signalling (4575) for things such as > mapping > > SSRCs to users and announcing current participant list. > > That is much better than Plan A and Plan B. > > > > BTW: What would happen in NoPlan if the remote (i.e. a SIP > gateway/endpoing) sends you a re-INVITE for "hold" purposes and you > pass the SDP to your PC? or you should not pass the SDP to your PC? > and if so, what about if the SDP contains updated ICE candidates due > to remote peer network mobility? > > > > Thanks a lot for your response. > > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b15a385d6479604dfab1227 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    Do you work with video or just audio?

    Do you work with multiple streams/tracks, both send and rece= ive?

    Do you use features such as rtx, fec, and simulcast?

    Simple, single-track, audio-only clients that use SDP for si= gnalling over the wire are fairly well served by the current API, as are cl= ients only using the data channel.=C2=A0 But doing more advanced things, su= ch as those I mention, require significant SDP munging which can be a very = slow and error-prone experience.=C2=A0

    Your experience may differ from others because they are tryi= ng to do things that require a lot more SDP munging, which can be quite pai= nful.

    On Jun 21, 2013 2:40 AM, "Bossiel thiorigue= l" <bossiel@yahoo.fr> wr= ote:
    Hello,

    I'm registered on this group since the beginni= ng but this is my first post on this thread. So, I presente myself: Mamadou= DIOP and I'm working for Doubango Telecom where we're building SIP= endpoints, gateways, TelePresence/Telemedicine systems... all focused on S= IP/IMS/LTE/RCS-e and open source.

    What I'm talking about is not just feeling but something I've= experienced.

    Using the current WebRTC we have managed to *easil= y* build almost all kind of applications: click-to-call, SIP/IMS clients, g= ateways to PSTN, MCUs, Telemedicine systems...and haven't seen any majo= r issue. It's true that it's not natural to "hack" a blob SDP to implement features like hold/resume, media update, early media= ... but it works and there are demo applications showing it. If there is s= omething more beautiful we just want to see it in action and test it.

    Many participants here have said that what they want is something clo= se to CU-RTC-WEB. Don't really know if they tried to build applications= using it or not but in my case I have.
    First on Windows 8 but ha= ven't gone far as there is no documentation to get started. Then, OSX a= nd=C2=A0luckily=C2=A0there was a readme with two links for testing (only on= e work). You need to open 3 pages (1 master, 2 slaves) and check "send= audio" on both slaves to header sound. Many javascript files and no d= ocumentation. It's said on these blogs that interop with SIP networks i= s easy but it's not my feeling ...I just want to see one :)

    I don't really understand the issue with the O/A model. SDP or no= t SDP you'll always offer something and answer something. I'm I mis= sing?

    Fo= r the current WebRTC, Google open sourced their engine, produced drafts, a = working implementation in chrome, a=C2=A0mailing-list to help developers, d= emo applications, documentation... we just want to see the same from any co= mpany asking to rewrite everything.

    I'm not saying the current WebRTC impleme= ntation is perfect but I have seen my 14 year old=C2=A0nephew developing an= audio/video chat for his homework :)

    Regards

    De=C2=A0: I=C3=B1aki= Baz Castillo <ibc@al= iax.net>
    =C3=80=C2=A0: Emil Ivov <= ;emcho@jitsi.org&g= t;
    Cc=C2=A0: "rtcweb@ietf.org" &= lt;rtcweb@ietf.org= >
    Envoy=C3=A9 le : Vendredi 2= 1 juin 2013 1h24
    Objet=C2=A0: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-op= ened

    2013/6/21 Emil Ivov <emcho@jitsi.org>:
    >
    > On 20.06.13, 23:49, I= =C3=B1aki Baz Castillo wrote:
    >>
    >> In JsSIP we are getti= ng frustrated trying to implement the "hold" /
    >> "unhold" feature because it requires SDP parsing and man= gling. Sending
    >> a re-INVITE with a modified SDP (now with a video track enabled) seems
    >> to work (after lot of pain) but we = still miss a reliable API to know
    >> what the new SDP means. Inste= ad we need to parse the SDP to detect
    >> global (or per m=3D) line= attributes like "a=3Dinactive" or "a=3Dsendonly"
    >> etc etc. It's really painful.
    >
    >
    > I am hav= ing a problem following what you are trying to achieve here. In
    > JsS= IP you seem to be going for a full SIP implementation in the browser. If > this is true and if this WG decides to remove SDP from the API surface= , then
    > you would need to completely parse SDP in the JS and then co= nvert it into
    > API calls. Similarly, when creating offers and answer= s you would need to
    > construct SDP all by yourself.

    And we will do it very happily b= ecause then we will know what
    *exactly* we are sending on-the-wire.
    <= br>


    > So I am not sure why the SDP parsing in the current situation is so much of
    > a blocker for your use case.

    Becaus= e regardless I am a SIP-guy, I understand that the main mission
    of WebRT= C is to provide realtime communications *for* the WWW, and not
    to enable= a new interface for like-telephony-bussines.

    Today I'm doing SIP. Tomorrow I may be doing
    [[put_here_a_future= _RTC_protocol_not_based_on_SDP]] and then I don't
    want to be constra= ined by decisions made today that force any future
    RTC protocol to deal = with SDP O/A model.

    :)



    >> BTW I don't know wheter you support Plan= A, PlanB or NoPlan, but I did
    >> a question (in this case about No= Plan) for which I got no response,
    >> and honestly I would like to= see it replied regardless the solution
    >> uses PlanA, PlanB or NoPlan model:
    >>
    >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07871.= html
    >>
    > The other option would be indeed to do the same thing in J= S. I believe this
    > is JsSIP's use case. In that case however, re= gardless of whether you choose
    > Plan A, Plan B, No Plan or CU-RTC-We= b, you will inevitably be exposed to a
    > fair amount of complexity, parsing and JS magic.
    >
    > You a= re, after all, building a SIP stack.

    Yes, but JsSIP creates its own = SIP messages to be sent in the wire, so
    we have full control over *what*= we create and send. Those SIP
    messages are not provided by the WebRTC API. But for the SDP
    component, = JsSIP retreives a SDP blob string from the PC.






    <= br>>
    > In the above mail you also say:
    >
    >> Another= example:
    >>
    >> * I am a powerful SIP conference server which properly= implements
    >> WebRTC. I initiate a call to 5 users (running JS SIP app in their
    >> browsers). The = initial INVITE has SSRC/MSID fields in the SDP
    >> identifying all = the participants, am I right?
    >
    >
    > No, with No Plan ther= e are no SSRCs and MSIDs in the SDP that comes from the
    > browser.

    OK


    >> * Later, during the conference,= I call to another 6th participant and
    >> enter him into the confe= rence, so I need to send a re-INVITE to every
    >> participant with = a modified version of the SDP (note that this is SIP
    >> protocol, so I need to use SIP messages to carry the new info abou= t
    >> SSRC/MSID and so on).
    >
    >
    > That's the = thing. You don't need that. In Jitsi we do exactly this operation
    > with no Offer/Answer signalling. RTP carries enough information to pro= cess
    > streams and we use upper layer signalling (4575) for things su= ch as mapping
    > SSRCs to users and announcing current participant list.

    That is much better than P= lan A and Plan B.



    BTW: What would happen in NoPlan if the re= mote (i.e. a SIP
    gateway/endpoing) sends you a re-INVITE for "hold&= quot; purposes and you
    pass the SDP to your PC? or you should not pass the SDP to your PC?
    and = if so, what about if the SDP contains updated ICE candidates due
    to remo= te peer network mobility?



    Thanks a lot for your response.
    --
    I=C3=B1aki Baz Castillo
    <ibc@aliax.net>
    _________________________________= ______________
    rtcweb mailing list
    rtcweb@ietf.org
    = https://www.ietf.org/mailman/listinfo/rtcweb


    <= /div>

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

    --047d7b15a385d6479604dfab1227-- From bossiel@yahoo.fr Fri Jun 21 07:50:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AB321E812B for ; Fri, 21 Jun 2013 07:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xli5XWZu3GdR for ; Fri, 21 Jun 2013 07:50:24 -0700 (PDT) Received: from nm3-vm0.bullet.mail.ird.yahoo.com (nm3-vm0.bullet.mail.ird.yahoo.com [77.238.189.213]) by ietfa.amsl.com (Postfix) with SMTP id 16BAC21E8126 for ; Fri, 21 Jun 2013 07:50:12 -0700 (PDT) Received: from [77.238.189.52] by nm3.bullet.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 14:50:00 -0000 Received: from [212.82.109.128] by tm5.bullet.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 14:50:00 -0000 Received: from [127.0.0.1] by omp1020.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 14:50:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 509436.5444.bm@omp1020.mail.ird.yahoo.com Received: (qmail 50102 invoked by uid 60001); 21 Jun 2013 14:50:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1371826200; bh=UOcP4L/CEtY1PjZnuCo2Rlb/ixvk57atMtIAx9nbtBc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=XLYeSUvjvTGkgO9JEaZtIWFDu+TbVwgm5FZKpChJ2hzbpFALhV0WGjnFgLrNr28uZ6VDzqhNudjO/xIW2guSCLD87WqZLF5m5IPafn2DGllXv1uzpRLDF0hqjvtk8UoCcOvzIEME+anrN7obUlDXlCsSTs2WqUhtCZdS8yHWgTU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nIYv30rG/6eJEO3V6/J23+In7iQsuc6H5KqrWS/mjIKv5yCXQx6BfRm8n8lxakWASCQymVJkNetDJiqTfwXkcxt7FTSPr0lUKYsJfuNYTX6PmLWoqq3pM/stcc0HyQRuXAtamEuTkXNlK/uv4ZjkcAQiNflr4j/7z/H1OL4VaSc=; X-YMail-OSG: oXPIV2EVM1k8zYTQKVyoVXznGBFMweBUyb6JZPuKuLs2nC_ wh03MwUNkLsfITKaN8ehdWJKSyObW6mlZiIqo4xK1mrnT5ZazLvSCRjcREGh AhqPUaBZroRPXD1CP2nMiLup3EcRMqs8KSXLa87mTZTnUocF48grLlMipOHo 2EfgY4DKEQPh.n3zmJr9VgCAia4r3M0PEZerFKYRIwx8XQ9OXoSnPwFoK0d6 iTGki1IEIvRiZ4MhzUXKxsxxzv5huSRWn6GHua4HHnC21Nku5aipaMfoyH6d Z4jaPpSfgQ48RW3OQ9w8syDNDpe9_PuDEH7uImswcYyiBM4uk507LIEiNs9h RqRiH9FdGOvTcCONpk3aguixsJF4JR2apWoWL.JU0tNPMvQr5SHZkS4a8MHI RVifDI_YyPhg0Hsy2.yFXRpVn_JJMmGM_unF_a9n19Fw5RXDyJHdyVhL58ZI xP1g90XMLH0Sw.fFGJ_5jL3uFX7w8MbgQeS0DucDH8rDLeSnTMqcdqY8yLY_ fWwUVc1vPkX1wlXF3TIykYFEAiRvq4ga8MoPFUypZ892RzKIfMuCVJWcZXTF i4uiuMceiNCcWqDkJpVT3m0mWqb3HTfp3eR4n6AFsl0a2PRQnLfBD_UXr_UN _mGs_xhr.7SskR.ngCULcvanJRDFfUjprRqfYStmnPgekD4fwUL_jEWDdsrS 3H_37qRI4FhnI8vYY4EUHDUQrFIIXJhwJtWa5 Received: from [88.179.39.5] by web171304.mail.ir2.yahoo.com via HTTP; Fri, 21 Jun 2013 15:49:59 BST X-Rocket-MIMEInfo: 002.001, QFBldGVyCkJvdGggYXVkaW8gYW5kIHZpZGVvLgpZZXMgd2UncmUgZG9pbmcgYWxsIHlvdSdyZSBsaXN0aW5nIGhlcmUgYW5kIGV2ZW4gbW9yZS4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRGXCoDogUGV0ZXIgVGhhdGNoZXIgPHB0aGF0Y2hlckBnb29nbGUuY29tPgrDgMKgOiBCb3NzaWVsIHRoaW9yaWd1ZWwgPGJvc3NpZWxAeWFob28uZnI.IApDY8KgOiBkaW9wbWFtYWRvdUBkb3ViYW5nby5vcmc7IHJ0Y3dlYkBpZXRmLm9yZyAKRW52b3nDqSBsZSA6IFZlbmRyZWRpIDIxIGp1aW4gMjABMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.554 References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> Message-ID: <1371826199.49975.YahooMailNeo@web171304.mail.ir2.yahoo.com> Date: Fri, 21 Jun 2013 15:49:59 +0100 (BST) From: Bossiel thioriguel To: Peter Thatcher In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1470824145-1251447167-1371826199=:49975" Cc: "diopmamadou@doubango.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bossiel thioriguel List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 14:50:29 -0000 ---1470824145-1251447167-1371826199=:49975 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable @Peter=0ABoth audio and video.=0AYes we're doing all you're listing here an= d even more.=0A=0A=0A________________________________=0A De=A0: Peter Thatc= her =0A=C0=A0: Bossiel thioriguel = =0ACc=A0: diopmamadou@doubango.org; rtcweb@ietf.org =0AEnvoy=E9 le : Vendre= di 21 juin 2013 16h42=0AObjet=A0: Re: [rtcweb] Requesting "SDP or not SDP" = debate to be re-opened=0A =0A=0A=0ADo you work with video or just audio?=0A= Do you work with multiple streams/tracks, both send and receive?=0ADo you u= se features such as rtx, fec, and simulcast?=0A=0ASimple, single-track, aud= io-only clients that use SDP for signalling over the wire are fairly well s= erved by the current API, as are clients only using the data channel.=A0 Bu= t doing more advanced things, such as those I mention, require significant = SDP munging which can be a very slow and error-prone experience.=A0 =0AYour= experience may differ from others because they are trying to do things tha= t require a lot more SDP munging, which can be quite painful.=0AOn Jun 21, = 2013 2:40 AM, "Bossiel thioriguel" wrote:=0A=0AHello,=0A= >=0A>=0A>I'm registered on this group since the beginning but this is my fi= rst post on this thread. So, I presente myself: Mamadou DIOP and I'm workin= g for Doubango Telecom where we're building SIP endpoints, gateways, TelePr= esence/Telemedicine systems... all focused on SIP/IMS/LTE/RCS-e and open so= urce.=0A>=0A>=0A>What I'm talking about is not just feeling but something I= 've experienced.=0A>=0A>=0A>Using the current WebRTC we have managed to *ea= sily* build almost all kind of applications: click-to-call, SIP/IMS clients= , gateways to PSTN, MCUs, Telemedicine systems...and haven't seen any major= issue. It's true that it's not natural to "hack" a blob SDP to implement f= eatures like hold/resume, media update, early media ... but it works and th= ere are demo applications showing it. If there is something more beautiful = we just want to see it in action and test it.=0A>=0A>=0A>Many participants = here have said that what they want is something close to CU-RTC-WEB. Don't = really know if they tried to build applications using it or not but in my c= ase I have.=0A>My reference:=A0http://html5labs.interoperabilitybridges.com= /prototypes/cu-rtc-web-roaming/cu-rtc-web-roaming/info=0A>First on Windows = 8 but haven't gone far as there is no documentation to get started. Then, O= SX and=A0luckily=A0there was a readme with two links for testing (only one = work). You need to open 3 pages (1 master, 2 slaves) and check "send audio"= on both slaves to header sound. Many javascript files and no documentation= . It's said on these blogs that interop with SIP networks is easy but it's = not my feeling ...I just want to see one :)=0A>=0A>=0A>I don't really under= stand the issue with the O/A model. SDP or not SDP you'll always offer some= thing and answer something. I'm I missing?=0A>=0A>=0A>For the current WebRT= C, Google open sourced their engine, produced drafts, a working implementat= ion in chrome, a=A0mailing-list to help developers, demo applications, docu= mentation... we just want to see the same from any company asking to rewrit= e everything.=0A>=0A>=0A>I'm not saying the current WebRTC implementation i= s perfect but I have seen my 14 year old=A0nephew developing an audio/video= chat for his homework :)=0A>=0A>=0A>Regards=0A>=0A>=0A>=0A>_______________= _________________=0A> De=A0: I=F1aki Baz Castillo =0A>=C0=A0= : Emil Ivov =0A>Cc=A0: "rtcweb@ietf.org" =0A>Envoy=E9 le : Vendredi 21 juin 2013 1h24=0A>Objet=A0: Re: [rtcweb] Re= questing "SDP or not SDP" debate to be re-opened=0A> =0A>=0A>2013/6/21 Emil= Ivov :=0A>>=0A>> On 20.06.13, 23:49, I=F1aki Baz Castillo= wrote:=0A>>>=0A>>> In JsSIP we are getting frustrated trying to implement = the "hold" /=0A>>> "unhold" feature because it requires SDP parsing and man= gling. Sending=0A>>> a re-INVITE with a modified SDP (now with a=0A video t= rack enabled) seems=0A>>> to work (after lot of pain) but we still miss a r= eliable API to know=0A>>> what the new SDP means. Instead we need to parse = the SDP to detect=0A>>> global (or per m=3D) line attributes like "a=3Dinac= tive" or "a=3Dsendonly"=0A>>> etc etc. It's really painful.=0A>>=0A>>=0A>> = I am having a problem following what you are trying to achieve here. In=0A>= > JsSIP you seem to be going for a full SIP implementation in the browser. = If=0A>> this is true and if this WG decides to remove SDP from the API surf= ace, then=0A>> you would need to completely parse SDP in the JS and then co= nvert it into=0A>> API calls. Similarly, when creating offers and answers y= ou would need to=0A>> construct SDP all by yourself.=0A>=0A>And we will do = it very happily because then we will know what=0A>*exactly* we are sending = on-the-wire.=0A>=0A>=0A>=0A>=0A>> So I am not sure why the SDP parsing in t= he current=0A situation is so much of=0A>> a blocker for your use case.=0A>= =0A>Because regardless I am a SIP-guy, I understand that the main mission= =0A>of WebRTC is to provide realtime communications *for* the WWW, and not= =0A>to enable a new interface for like-telephony-bussines.=0A>=0A>Today I'm= doing SIP. Tomorrow I may be doing=0A>[[put_here_a_future_RTC_protocol_not= _based_on_SDP]] and then I don't=0A>want to be constrained by decisions mad= e today that force any future=0A>RTC protocol to deal with SDP O/A model.= =0A>=0A>:)=0A>=0A>=0A>=0A>>> BTW I don't know wheter you support PlanA, Pla= nB or NoPlan, but I did=0A>>> a question (in this case about NoPlan) for wh= ich I got no response,=0A>>> and honestly I would like to see it replied re= gardless the solution=0A>>> uses PlanA, PlanB or NoPlan model:=0A>>>=0A>>> = http://www.ietf.org/mail-archive/web/rtcweb/current/msg07871.html=0A>>>=0A>= > The other option would be indeed to do the same thing in JS. I believe th= is=0A>> is JsSIP's use case. In that case however, regardless of whether yo= u choose=0A>> Plan A, Plan B, No Plan or CU-RTC-Web, you will inevitably be= exposed to a=0A>> fair amount of complexity, parsing and JS magic.=0A>>=0A= >> You are, after all, building a SIP stack.=0A>=0A>Yes, but JsSIP creates = its own SIP messages to be sent in the wire, so=0A>we have full control ove= r *what* we create and send. Those SIP=0A>messages are not provided by the = WebRTC API. But for the SDP=0A>component, JsSIP retreives a SDP blob string= from the PC.=0A>=0A>=0A>=0A>=0A>=0A>=0A>=0A>>=0A>> In the above mail you a= lso say:=0A>>=0A>>> Another example:=0A>>>=0A>>> * I am a powerful SIP conf= erence server which properly implements=0A>>> WebRTC. I initiate=0A a call = to 5 users (running JS SIP app in their=0A>>> browsers). The initial INVITE= has SSRC/MSID fields in the SDP=0A>>> identifying all the participants, am= I right?=0A>>=0A>>=0A>> No, with No Plan there are no SSRCs and MSIDs in t= he SDP that comes from the=0A>> browser.=0A>=0A>OK=0A>=0A>=0A>>> * Later, d= uring the conference, I call to another 6th participant and=0A>>> enter him= into the conference, so I need to send a re-INVITE to every=0A>>> particip= ant with a modified version of the SDP (note that this is SIP=0A>>> protoco= l, so I need to use SIP messages to carry the new info about=0A>>> SSRC/MSI= D and so on).=0A>>=0A>>=0A>> That's the thing. You don't need that. In Jits= i we do exactly this operation=0A>> with no Offer/Answer signalling. RTP ca= rries enough information to process=0A>> streams and we use upper layer sig= nalling (4575) for things such as mapping=0A>> SSRCs to users=0A and announ= cing current participant list.=0A>=0A>That is much better than Plan A and P= lan B.=0A>=0A>=0A>=0A>BTW: What would happen in NoPlan if the remote (i.e. = a SIP=0A>gateway/endpoing) sends you a re-INVITE for "hold" purposes and yo= u=0A>pass the SDP to your PC? or you should not pass the SDP to your PC?=0A= >and if so, what about if the SDP contains updated ICE candidates due=0A>to= remote peer network mobility?=0A>=0A>=0A>=0A>Thanks a lot for your respons= e.=0A>=0A>--=0A>I=F1aki Baz Castillo=0A>=0A>________________= _______________________________=0A>rtcweb mailing list=0A>rtcweb@ietf.org= =0A>https://www.ietf.org/mailman/listinfo/rtcweb=0A>=0A>=0A>=0A>___________= ____________________________________=0A>rtcweb mailing list=0A>rtcweb@ietf.= org=0A>https://www.ietf.org/mailman/listinfo/rtcweb=0A>=0A> ---1470824145-1251447167-1371826199=:49975 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    @Peter
    Both audio and video.
    Yes we're doing all you're listing = here and even more.

    <= div dir=3D"ltr">
    De : Peter Thatcher <pthatc= her@google.com>
    =C0 : Bossiel thioriguel <bossiel@yahoo.fr>
    Cc : diopmamadou@doubango.org; rtcweb@ie= tf.org
    Envoy=E9 le : Vendredi 21= juin 2013 16h42
    Objet : Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
    =

    Do you work with video or just audio?
    =0A
    Do you work with multiple streams/tracks, both send and receive?=0A
    Do you use features such as rtx, fec, and simulcast= ?
    =0A
    Simple, single-track, audio-only clients tha= t use SDP for signalling over the wire are fairly well served by the curren= t API, as are clients only using the data channel.  But doing more adv= anced things, such as those I mention, require significant SDP munging whic= h can be a very slow and error-prone experience. 
    =0A=0A
    Your experience may differ from others because they are trying to = do things that require a lot more SDP munging, which can be quite painful.<= /div>=0A
    On Jun 21, 2013 2:40 AM, "B= ossiel thioriguel" <bossiel@yahoo.fr= > wrote:
    =0A
    Hello,
    =0A
    I'm registered on this group since the beginnin= g but this is my first post on this thread. So, I presente myself: Mamadou = DIOP and I'm working for Doubango Telecom where we're building SIP endpoint= s, gateways, TelePresence/Telemedicine systems... all focused on SIP/IMS/LT= E/RCS-e and open source.
    =0A

    =0AWhat I'm talking about is not just feeling but something I've experience= d.
    =0A
    Using the current WebR= TC we have managed to *easily* build almost all kind of applications: click= -to-call, SIP/IMS clients, gateways to PSTN, MCUs, Telemedicine systems...a= nd haven't seen any major issue. It's true that it's not natural to "hack" = a=0A blob SDP to implement features like hold/resume, media update, early m= edia ... but it works and there are demo applications showing it. If there = is something more beautiful we just want to see it in action and test it.
    =0A

    =0AMany participants here = have said that what they want is something close to CU-RTC-WEB. Don't reall= y know if they tried to build applications using it or not but in my case I= have.
    =0A
    First o= n Windows 8 but haven't gone far as there is no documentation to get starte= d. Then, OSX and luckily there was a readme with two links for te= sting (only one work). You need to open 3 pages (1 master, 2 slaves) and ch= eck "send audio" on both slaves to header sound. Many javascript files and = no documentation. It's said on these blogs that interop with SIP networks i= s easy but it's not my feeling ...I just want to see one :)
    =0A=

    =0AI don't really understand the issue w= ith the O/A model. SDP or not SDP you'll always offer something and answer = something. I'm I missing?
    =0A
    For the current WebRTC, Google o= pen sourced their engine, produced drafts, a working implementation in chro= me, a mailing-list to help developers, demo applications, documentatio= n... we just want to see the same from any company asking to rewrite everyt= hing.
    =0A

    I'm not saying th= e current WebRTC implementation is perfect but I have seen my 14 year old&n= bsp;nephew developing an audio/video chat for his homework :)
    = =0A

    =0ARegards

    =0A
    De : I=F1aki Baz C= astillo <    ibc@aliax.net>
    =0A =C0 : Emil Ivov <emcho@jitsi.org>
    Cc : "rtcweb@ietf.o= rg" <rtcweb@ietf.org>
    =0A= Envoy=E9 le : Vendredi 21 = juin 2013 1h24
    Objet := Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
    =0A

    2013/6/21 Emil Ivov <emcho@jitsi.org>:
    >
    > On 20.06.13, 23:49, I=F1aki Ba= z Castillo wrote:
    >>
    >> In JsSIP we are getting frustrate= d trying to implement the "hold" /
    =0A>> "unhold" feature because = it requires SDP parsing and mangling. Sending
    >> a re-INVITE with = a modified SDP (now with a=0A video track enabled) seems
    >> to wor= k (after lot of pain) but we still miss a reliable API to know
    >> = what the new SDP means. Instead we need to parse the SDP to detect
    >&= gt; global (or per m=3D) line attributes like "a=3Dinactive" or "a=3Dsendon= ly"
    =0A>> etc etc. It's really painful.
    >
    >
    > I = am having a problem following what you are trying to achieve here. In
    &g= t; JsSIP you seem to be going for a full SIP implementation in the browser.= If
    =0A> this is true and if this WG decides to remove SDP from the A= PI surface, then
    > you would need to completely parse SDP in the JS a= nd then convert it into
    > API calls. Similarly, when creating offers = and answers you would need to
    =0A> construct SDP all by yourself.
    =
    And we will do it very happily because then we will know what
    *exact= ly* we are sending on-the-wire.




    > So I am not sure wh= y the SDP parsing in the current=0A situation is so much of
    > a block= er for your use case.

    Because regardless I am a SIP-guy, I understan= d that the main mission
    of WebRTC is to provide realtime communications = *for* the WWW, and not
    to enable a new interface for like-telephony-buss= ines.
    =0A
    Today I'm doing SIP. Tomorrow I may be doing
    [[put_here_= a_future_RTC_protocol_not_based_on_SDP]] and then I don't
    want to be con= strained by decisions made today that force any future
    RTC protocol to d= eal with SDP O/A model.
    =0A
    :)



    >> BTW I don't kn= ow wheter you support PlanA, PlanB or NoPlan, but I did
    >> a quest= ion (in this case about NoPlan) for which I got no response,
    >> an= d honestly I would like to see it replied regardless the solution
    =0A>= ;> uses PlanA, PlanB or NoPlan model:
    >>
    >> http://www.ietf.org/mail-archive/web/rtcweb/cur= rent/msg07871.html
    =0A>>
    > The other option would be ind= eed to do the same thing in JS. I believe this
    > is JsSIP's use case.= In that case however, regardless of whether you choose
    > Plan A, Pla= n B, No Plan or CU-RTC-Web, you will inevitably be exposed to a
    =0A> = fair amount of complexity, parsing and JS magic.
    >
    > You are, a= fter all, building a SIP stack.

    Yes, but JsSIP creates its own SIP m= essages to be sent in the wire, so
    we have full control over *what* we c= reate and send. Those SIP
    =0Amessages are not provided by the WebRTC API= . But for the SDP
    component, JsSIP retreives a SDP blob string from the = PC.







    >
    > In the above mail you also = say:
    >
    >> Another example:
    =0A>>
    >> * I am= a powerful SIP conference server which properly implements
    >> Web= RTC. I initiate=0A a call to 5 users (running JS SIP app in their
    >&g= t; browsers). The initial INVITE has SSRC/MSID fields in the SDP
    >>= ; identifying all the participants, am I right?
    >
    >
    > No,= with No Plan there are no SSRCs and MSIDs in the SDP that comes from the=0A> browser.

    OK


    >> * Later, during the confer= ence, I call to another 6th participant and
    >> enter him into the = conference, so I need to send a re-INVITE to every
    >> participant = with a modified version of the SDP (note that this is SIP
    =0A>> pr= otocol, so I need to use SIP messages to carry the new info about
    >&g= t; SSRC/MSID and so on).
    >
    >
    > That's the thing. You don'= t need that. In Jitsi we do exactly this operation
    =0A> with no Offer= /Answer signalling. RTP carries enough information to process
    > strea= ms and we use upper layer signalling (4575) for things such as mapping
    &= gt; SSRCs to users=0A and announcing current participant list.

    That = is much better than Plan A and Plan B.



    BTW: What would happe= n in NoPlan if the remote (i.e. a SIP
    gateway/endpoing) sends you a re-I= NVITE for "hold" purposes and you
    =0Apass the SDP to your PC? or you sho= uld not pass the SDP to your PC?
    and if so, what about if the SDP contai= ns updated ICE candidates due
    to remote peer network mobility?


    Thanks a lot for your response.
    =0A
    --
    I=F1aki Baz Castillo<= br><ibc@aliax.net>
    _________________= ______________________________
    rtcweb mailing list
    rtcweb@ietf.org
    =0Ahttps://www.ietf.org= /mailman/listinfo/rtcweb


    <= br>_______________________________________________
    =0Artcweb mailing lis= t
    =0Artcweb@ietf.org
    =0Ahttps://www.ietf.org/mailman/listinfo/rtcweb
    =0A


    ---1470824145-1251447167-1371826199=:49975-- From bossiel@yahoo.fr Fri Jun 21 07:58:58 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEA611E8199 for ; Fri, 21 Jun 2013 07:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNFyB-OxKzmL for ; Fri, 21 Jun 2013 07:58:53 -0700 (PDT) Received: from nm14-vm1.bullet.mail.ird.yahoo.com (nm14-vm1.bullet.mail.ird.yahoo.com [77.238.189.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7861111E8198 for ; Fri, 21 Jun 2013 07:58:52 -0700 (PDT) Received: from [77.238.189.233] by nm14.bullet.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 14:58:49 -0000 Received: from [212.82.108.112] by tm14.bullet.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 14:58:49 -0000 Received: from [127.0.0.1] by omp1021.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 14:58:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 158072.91868.bm@omp1021.mail.ird.yahoo.com Received: (qmail 60700 invoked by uid 60001); 21 Jun 2013 14:58:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1371826728; bh=0cl65c/AKH+wLz64xqVgWbub1kkdgDND1XKjIQ+PSZ0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=G+cqUqK6er/y++jPnGIJfZTJC91j5/WYnqtVlxFJ/TXute/ZQql3/Ic7Y2ht4haUfsVjkcyRZhJz4gxmYwPcbrcNRDuTmTfLiqQzNhZ7RajXcGcxZX+voVpKa4e0I6Uz/GNFyNXodl5wqfODyPsBzlSyKG7xb5cIyib9HLoWe0c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GkQfqddMhoSWI/IXdhUJCUAvhCHtxAQ0byG/olP1e3JnlGSVH3yBQM7S6stWzyDRq2Lkh01OtBw6sWybyOOqEPGsdtuoVfNapPAP4FyAsGoSvmMb9YbI4yC1w2JfgBwDEP0dxjcKJ1/JkVltixFe1jjhiPRntBoE1g0+0VKYcKQ=; X-YMail-OSG: Unzq3FUVM1lChGYoamD8KJR.1OcwJio062oRgvfIBxDrn6f lMBW8NPvsSaqHA86WVytmYT6WXIU0qavZIBVD1mOyHsJecEXy3LHPuX2g15O qjrDE7eS29a6q__rDRsBB8.nIn6Zcz4kV.rY81YKSbvcfORSrYTj9XjfCQ_K 5GfRJ8I53bk1_78loEz5sAFGTlT62anyzWWwixwlhpS97vwB0LzswiHB9Iki wysVdSfj3mphC6inOImgTt5BkcBPmIAQ_ifjonl4gQ5ncwCZkAjwKrYoagTt AEI5UKkLLbq9XUsyucKdH66b3Frl1aC1d9uTNN7TaKwZh.44sbZcuOwU5xIn aD51FcHrZE1_gFqVpuWztOQo6Tkr3sYTw1GFUhDOKj0nJ4iIrm5wqBMSRP97 IFie7dfNm9J2fZum7WyjW0axDYNvhIkSBSdAWprbMVS754ZblKQVTBaWpDHb XRkYuNKtZ2RvjY7Qxj.AUN1keLqFYM71nKyGmYhjO8GN47i5_ApbE1MKdgYU l3r4tII38LBrr_9qTamsfkXotHopxnSISOnswaTNGEC.GRcU4h7QWzh.ZfR_ 82lZ_XKHwOSGRHzNEX5vovw9HzfagV2rQCWIjiAO5zwKZ5lJ36J2Y5tGCtOt i48K8QNpOiKtcaFvqXgQe7ZetqWTQP.zDaxDblK9pNOadhG.F1GhihjYNr0s 7mF3NQgAu3uoPvr4d3YJoE0VYfOw- Received: from [88.179.39.5] by web171304.mail.ir2.yahoo.com via HTTP; Fri, 21 Jun 2013 15:58:48 BST X-Rocket-MIMEInfo: 002.001, QFJvYmluClllcyB3ZSdsbCB1c2Ugc3VjaCBBUEkgKGFscmVhZHkgc2FpZCBpdCBvbiBhbm90aGVyIHRocmVhZCkuIFdoYXQgSSdtIG5vdCBzdXBwb3J0aW5nIGlzICJyZW1vdmUgU0RQIGFuZCBzdGFydCBmcm9tIHplcm8iLgpXaGF0IHlvdSdyZSBwcm9wb3NpbmcgaGVyZSByZXByZXNlbnTCoGh1Z2UgYW1vdW50IG9mIHdvcmsuIEkgZ3Vlc3MgeW91IGFscmVhZHkga25vdyBpdCA6KQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBEZcKgOiBSb2JpbiBSYXltb25kIDxyb2JpbkBob29rZmxhc2gBMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.554 References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> <51C4447B.6020709@hookflash .com> Message-ID: <1371826728.58934.YahooMailNeo@web171304.mail.ir2.yahoo.com> Date: Fri, 21 Jun 2013 15:58:48 +0100 (BST) From: Bossiel thioriguel To: Robin Raymond In-Reply-To: <51C4447B.6020709@hookflash.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1470824145-821007945-1371826728=:58934" Cc: "diopmamadou@doubango.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bossiel thioriguel List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 14:58:58 -0000 ---1470824145-821007945-1371826728=:58934 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable @Robin=0AYes we'll use such API (already said it on another thread). What I= 'm not supporting is "remove SDP and start from zero".=0AWhat you're propos= ing here represent=A0huge amount of work. I guess you already know it :)=0A= =0A=0A________________________________=0A De=A0: Robin Raymond =0A=C0=A0: Bossiel thioriguel =0ACc=A0: "diopma= madou@doubango.org" ; "rtcweb@ietf.org" =0AEnvoy=E9 le : Vendredi 21 juin 2013 14h18=0AObjet=A0: Re: [rtcw= eb] Requesting "SDP or not SDP" debate to be re-opened=0A =0A=0A=0A=0AYour = point about it being easy to get a demo running I agree, or even =0Ainterfa= cing with a SIP network.=0A=0AI can't comment on the difficulty or not of C= U-RTCWeb's implementation. =0AIt does look like CU-RTCWeb has a lot of feat= ures/complexity out of the =0Agate which is necessary to do a lot of altern= ative scenarios but might =0Acause someone to through up their hands in fru= stration trying to figure =0Aout how it all works, especially if you are an= integrator of SIP and not=0A an implementer.=0A=0AI conquer whatever solut= ion adopted must be equally as easy for SIP =0Adevelopers (even though that= is not part of the mandate as I understand =0Ait). That's why I proposed t= hat I would take it upon myself to lead an =0AAPI proposal that could work = for both. The simple "SIP/SDP" case being =0Aprovided as a shim that you co= uld write against if you are a SIP =0Aintegrator (close to the current webr= tc as reasonable) but something =0Athat doesn't break other non-SIP models.= =0A=0ALet me explain why offer/answer breaks other models. Offer/answer =0A= negotiates akin to "I send out an offer, but whatever you agree on from =0A= my offer we will use together". Further "if you disagree with my offer, =0A= we'll roll back to the existing offer". Finally "if we both make an =0Aoffe= r at the same time, we'll conflict and we'll have to use conflict =0Aresolu= tion to change our offers". That was true of when I last authored =0AX-Lite= /X-PRO SIP softphone client so perhaps something has changed since=0A then = to which I'm not aware, but that's my gross simplification of =0Aoffer/answ= er.=0A=0AHowever, that is absolutely _not_ the only way to negotiate. For = =0Aexample, Open Peer for example uses constraints based negotiation. This = =0Ais akin to "if you send me anything, please send me this". The =0Adiffer= ence is that each side is allowed to change what it expects to =0Areceive w= ithout a round trip to the remote party agreeing and without =0Arisk of rol= lback. That makes it really easy to update and change what =0Ayou expect wi= thout needing the complexities of an offer/answer state =0Amachine. If one = is forced upon us, we'll have to find away around this =0Aoffer/answer mech= anism because negotiating is not an option for us - we =0Asimply don't do i= t at all. Whatever we do to hack around it will likely =0Aviolate the offer= /answer rules.=0A=0AOffer/answer is wholly not necessary to be mandated as = part of WebRTC to=0A fulfill the charter but it currently is mandated. I do= n't want =0Asomething just for "me", but we are forcing an unneeded model o= f =0Anegotiation upon JavaScript developers that may not want to adhere to = =0Athat model either (and likely will violate it too, albeit =0Aunintention= ally). Skype has similar objections to offer/answer but I =0Acan't speak to= their negotiation strategy or presume to speak on their =0Abehalf. If offe= r/answer were removed as a mandate, you can do so =0Ayourself in your JavaS= cript without browser enforcement.=0A=0AMy other issue is that SDP has beco= me an API surface for control, =0Aproperties and extensions. We must rememb= er that the consumer of what we=0A produce must be acceptable to the W3C an= d their members (browser and =0AJavaScript implementers) and not SIP integr= ators. If we are asking =0AJavaScript developers to hack/mangle the SDP to = do anything beyond =0A"place/answer" a call, we are forcing them to learn a= n entirely new =0Aill-defined language called SDP rather than just using a = JavaScript API =0Awhich is native to their language constructs.=0A=0AIf we = are saying "people shouldn't touch the SDP nor need to" then why =0Anot hav= e a binary format for the blob exchange that is untouchable? The =0Areason = we don't encode to binary is because we _expect_ people to have =0Ato mangl= e the SDP. That's simply not acceptable in my mind to require =0AJavaScript= developers to learn SDP. Perhaps this is outside the charter,=0A but I don= 't think it's inside the charter either to mandate learning =0ASDP to perfo= rm common edge case actions either (e.g. putting media on =0Ahold). There's= a huge gray area here and effectively we are coming up =0Awith their API f= or the W3C called "SDP". Should we fail to provide a =0Arespectable API, th= ey will reject what we have anyway and likely they =0Awill not come up with= SDP as their solution (plus WebRTC will take =0Aanother delay and blow).= =0A=0AThe next issue is that SDP is not a well defined format. There is no = =0A100% sure way to write SDP to be compatible. This means that if we do = =0Ahave to mangle SDP, we'll have to do browser, version and platform =0Ade= tection to pre-determine what exact formats the SDP will =0Agenerate/parses= and have compatibilities for each. We must or we will =0Abreak. This goes = against browser philosophy entirely. The IETF might not=0A care about that = but the W3C will care. But we should care too because =0Awe cannot be sure = that the next browser version update on some random =0Aplatform won't just = suddenly break any implementation. What we write =0Awill expect a certain s= yntax, and will break and there's no mandate that=0A browser vendors come b= ack to us for approval of their extensions they =0Awant/need. This will mak= e implementations brittle.=0A=0AThe final thing that scares me is all the e= xtensions being proposed to =0Amake this SDP, for example, BUNDLE. Nothing = wrong with the concepts at =0Aall! But should some vendors start adopting s= ome of these extensions (or=0A fork the browser code base to support these = extensions), we'll see =0Aenvironments where the SDP produced is massively = complex, unknown and =0A"special". This will be entirely legal since anythi= ng goes with SDP but =0Awill wholly break likely everything that doesn't kn= ow about those =0Aextensions, except those involved in producing those exte= nsions. No =0Alonger will this be the open web, but a closed web tied to ce= rtain =0Avendors via extensions. This isn't just some theoretical issue. Th= is is =0Aalready underway with an avalanche with many requests / demands be= ing =0Aput upon the various browser vendors all with their own competing = =0Ainterests / alliances.=0A=0AWith an API model, extensions can be added a= s additional API, without =0Abreaking anyone. If you use the "basic" API, y= ou get the same behaviours=0A you expect as always even if new features are= added later. If you use =0Aadditional APIs, only then do you get the advan= ced features for the API =0Ayou know about. With SDP, you don't know becaus= e their's nothing =0Arestricting exactly what the SDP expresses locally in = advance nor what =0Ayou will receive from a remote party.=0A=0AFinally, by = baking the SDP into the browser, you make it unchangeable. =0AIf there was = issues with the SDP generated/parsing, you'll have to =0Amangle the SDP fro= m JavaScript (or from an SBC) to make it work (and you=0A will need browser= version detection to do that which is something the =0Abrowser vendors are= fighting hard to prevent). Were it instead written =0Aas a JavaScript shim= , you could tweak the shim code yourself for =0Awhatever compatibility you = need without waiting for the next browser =0Aupdate to fix the issue. Baked= in the browser, you are out of luck.=0A=0AThis is why I'm proposing we hav= e a reasonable API for JavaScript using =0Atheir language constructs they a= lready know and are familiar that is =0Aextensible for the future without m= ore SDP mangling/extensions. Those =0Awho want to do SDP extensions can do = it inside an updatable shim, which =0Acan be tailored to your specific SIP = environment to be 100% compatible =0Awith little to no risk the browser ven= dors will break you.=0A=0AI fully appreciate the need that whatever API is = produced is not =0Aneedlessly complex and to ensure the absolutely dead-eas= y implementation=0A exist. I plan to satisfy the dead-easy situation by pro= viding a shim =0Awritten entirely in JavaScript that provides that "80%" of= what people =0Awant, i.e. the current WebRTC API which is easy starting po= int for many =0ASIP integrators. Those of us who in the 20% who don't use S= IP can bypass=0A (or modify) the shim to do what they want/need.=0A=0ASo I = ask you, if I were to propose such a solution (and provide =0Aexamples), wo= uld you be open minded to using a shim that provides your =0Aeasy use case = rather than forcing SDP inside of SDP being baked into =0Abrowser binary? D= o you also understand my objections to using SDP with =0Aoffer/answer?=0A= =0A-Robin=0A=0A=0ABossiel thioriguel=0A>21 June, 2013 =0A5:40 AM=0A>Hello,= =0A>=0A>=0A>I'm registered on this group since the beginning but this is my= first post =0Aon this thread. So, I presente myself: Mamadou DIOP and I'm = working for =0ADoubango Telecom where we're building SIP endpoints, gateway= s, =0ATelePresence/Telemedicine systems... all focused on SIP/IMS/LTE/RCS-e= =0Aand open source.=0A>=0A>=0A>What I'm talking about is not just feeling = but something I've experienced.=0A>=0A>=0A>Using the current WebRTC we have= managed to *easily* build almost all kind of applications: click-to-call, = SIP/IMS clients, gateways to PSTN, MCUs, =0ATelemedicine systems...and have= n't seen any major issue. It's true that =0Ait's not natural to "hack" a bl= ob SDP to implement features like hold/resume, media update, early =0Amedia= ... but it works and there are demo applications showing it. If =0Athere i= s something more beautiful we just want to see it in action and =0Atest it.= =0A>=0A>=0A>Many participants here have said that what =0Athey want is some= thing close to CU-RTC-WEB. Don't really know if they =0Atried to build appl= ications using it or not but in my case I have.=0A>My reference:=A0http://h= tml5labs.interoperabilitybridges.com/prototypes/cu-rtc-web-roaming/cu-rtc-w= eb-roaming/info=0A>First on Windows 8 but =0Ahaven't gone far as there is n= o documentation to get started. Then, OSX =0Aand=A0luckily=A0there was a re= adme with two links for testing (only one =0Awork). You need to open 3 page= s (1 master, 2 slaves) and check "send =0Aaudio" on both slaves to header s= ound. Many javascript files and no =0Adocumentation. It's said on these blo= gs that interop with SIP networks =0Ais easy but it's not my feeling ...I j= ust want to see one :)=0A>=0A>=0A>I don't really understand the issue with = the O/A model. =0ASDP or not SDP you'll always offer something and answer s= omething. I'm I missing?=0A>=0A>=0A>For the current WebRTC, =0AGoogle open = sourced their engine, produced drafts, a working =0Aimplementation in chrom= e, a=A0mailing-list to help developers, demo =0Aapplications, documentation= ... we just want to see the same from any =0Acompany asking to rewrite ever= ything.=0A>=0A>=0A>I'm not =0Asaying the current WebRTC implementation is p= erfect but I have seen my =0A14 year old=A0nephew developing an audio/video= chat for his homework :)=0A>=0A>=0A>Regards=0A> ---1470824145-821007945-1371826728=:58934 Content-Type: multipart/related; boundary="-1470824145-266750018-1371826728=:58934" ---1470824145-266750018-1371826728=:58934 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    @Robin
    Yes we'll use such API (already said it on anoth= er thread). What I'm not supporting is "remove SDP and start from zero".
    What you're proposing here represent huge = amount of work. I guess you already know it :)

    =
    De : = Robin Raymond <robin@hookflash.com>
    =C0 : Bossiel thioriguel <bossiel@yahoo.fr> =
    Cc : "diopmamadou= @doubango.org" <diopmamadou@doubango.org>; "rtcweb@ietf.org" <rtcw= eb@ietf.org>
    Envoy=E9 le : Vendredi 21 juin 2013 14h18
    Objet : Re: [rtcweb] Requesting "SDP or not SDP" debate= to be re-opened

    =0A =0A

    =0AYour point about it being easy to = get a demo running I agree, or even =0Ainterfacing with a SIP network.
    = =0A
    =0AI can't comment on the difficulty or not of CU-RTCWeb's implement= ation. =0AIt does look like CU-RTCWeb has a lot of features/complexity out = of the =0Agate which is necessary to do a lot of alternative scenarios but = might =0Acause someone to through up their hands in frustration trying to f= igure =0Aout how it all works, especially if you are an integrator of SIP a= nd not=0A an implementer.
    =0A
    =0AI conquer whatever solution adopted = must be equally as easy for SIP =0Adevelopers (even though that is not part= of the mandate as I understand =0Ait). That's why I proposed that I would = take it upon myself to lead an =0AAPI proposal that could work for both. Th= e simple "SIP/SDP" case being =0Aprovided as a shim that you could write ag= ainst if you are a SIP =0Aintegrator (close to the current webrtc as reason= able) but something =0Athat doesn't break other non-SIP models.
    =0A
    = =0ALet me explain why offer/answer breaks other models. Offer/answer =0Aneg= otiates akin to "I send out an offer, but whatever you agree on from =0Amy = offer we will use together". Further "if you disagree with my offer, =0Awe'= ll roll back to the existing offer". Finally "if we both make an =0Aoffer a= t the same time, we'll conflict and we'll have to use conflict =0Aresolutio= n to change our offers". That was true of when I last authored =0AX-Lite/X-= PRO SIP softphone client so perhaps something has changed since=0A then to = which I'm not aware, but that's my gross simplification of =0Aoffer/answer.=
    =0A
    =0AHowever, that is absolutely _not_ the only way to negotiate. = For =0Aexample, Open Peer for example uses constraints based negotiation. T= his =0Ais akin to "if you send me anything, please send me this". The =0Adi= fference is that each side is allowed to change what it expects to =0Arecei= ve without a round trip to the remote party agreeing and without =0Arisk of= rollback. That makes it really easy to update and change what =0Ayou expec= t without needing the complexities of an offer/answer state =0Amachine. If = one is forced upon us, we'll have to find away around this =0Aoffer/answer = mechanism because negotiating is not an option for us - we =0Asimply don't = do it at all. Whatever we do to hack around it will likely =0Aviolate the o= ffer/answer rules.
    =0A
    =0AOffer/answer is wholly not necessary to be = mandated as part of WebRTC to=0A fulfill the charter but it currently is ma= ndated. I don't want =0Asomething just for "me", but we are forcing an unne= eded model of =0Anegotiation upon JavaScript developers that may not want t= o adhere to =0Athat model either (and likely will violate it too, albeit = =0Aunintentionally). Skype has similar objections to offer/answer but I =0A= can't speak to their negotiation strategy or presume to speak on their =0Ab= ehalf. If offer/answer were removed as a mandate, you can do so =0Ayourself= in your JavaScript without browser enforcement.
    =0A
    =0AMy other issu= e is that SDP has become an API surface for control, =0Aproperties and exte= nsions. We must remember that the consumer of what we=0A produce must be ac= ceptable to the W3C and their members (browser and =0AJavaScript implemente= rs) and not SIP integrators. If we are asking =0AJavaScript developers to h= ack/mangle the SDP to do anything beyond =0A"place/answer" a call, we are f= orcing them to learn an entirely new =0Aill-defined language called SDP rat= her than just using a JavaScript API =0Awhich is native to their language c= onstructs.
    =0A
    =0AIf we are saying "people shouldn't touch the SDP no= r need to" then why =0Anot have a binary format for the blob exchange that = is untouchable? The =0Areason we don't encode to binary is because we _expe= ct_ people to have =0Ato mangle the SDP. That's simply not acceptable in my= mind to require =0AJavaScript developers to learn SDP. Perhaps this is out= side the charter,=0A but I don't think it's inside the charter either to ma= ndate learning =0ASDP to perform common edge case actions either (e.g. putt= ing media on =0Ahold). There's a huge gray area here and effectively we are= coming up =0Awith their API for the W3C called "SDP". Should we fail to pr= ovide a =0Arespectable API, they will reject what we have anyway and likely= they =0Awill not come up with SDP as their solution (plus WebRTC will take= =0Aanother delay and blow).
    =0A
    =0AThe next issue is that SDP is not= a well defined format. There is no =0A100% sure way to write SDP to be com= patible. This means that if we do =0Ahave to mangle SDP, we'll have to do b= rowser, version and platform =0Adetection to pre-determine what exact forma= ts the SDP will =0Agenerate/parses and have compatibilities for each. We mu= st or we will =0Abreak. This goes against browser philosophy entirely. The = IETF might not=0A care about that but the W3C will care. But we should care= too because =0Awe cannot be sure that the next browser version update on s= ome random =0Aplatform won't just suddenly break any implementation. What w= e write =0Awill expect a certain syntax, and will break and there's no mand= ate that=0A browser vendors come back to us for approval of their extension= s they =0Awant/need. This will make implementations brittle.
    =0A
    =0AT= he final thing that scares me is all the extensions being proposed to =0Ama= ke this SDP, for example, BUNDLE. Nothing wrong with the concepts at =0Aall= ! But should some vendors start adopting some of these extensions (or=0A fo= rk the browser code base to support these extensions), we'll see =0Aenviron= ments where the SDP produced is massively complex, unknown and =0A"special"= . This will be entirely legal since anything goes with SDP but =0Awill whol= ly break likely everything that doesn't know about those =0Aextensions, exc= ept those involved in producing those extensions. No =0Alonger will this be= the open web, but a closed web tied to certain =0Avendors via extensions. = This isn't just some theoretical issue. This is =0Aalready underway with an= avalanche with many requests / demands being =0Aput upon the various brows= er vendors all with their own competing =0Ainterests / alliances.
    =0A=0AWith an API model, extensions can be added as additional API, without = =0Abreaking anyone. If you use the "basic" API, you get the same behaviours= =0A you expect as always even if new features are added later. If you use = =0Aadditional APIs, only then do you get the advanced features for the API = =0Ayou know about. With SDP, you don't know because their's nothing =0Arest= ricting exactly what the SDP expresses locally in advance nor what =0Ayou w= ill receive from a remote party.
    =0A
    =0AFinally, by baking the SDP in= to the browser, you make it unchangeable. =0AIf there was issues with the S= DP generated/parsing, you'll have to =0Amangle the SDP from JavaScript (or = from an SBC) to make it work (and you=0A will need browser version detectio= n to do that which is something the =0Abrowser vendors are fighting hard to= prevent). Were it instead written =0Aas a JavaScript shim, you could tweak= the shim code yourself for =0Awhatever compatibility you need without wait= ing for the next browser =0Aupdate to fix the issue. Baked in the browser, = you are out of luck.
    =0A
    =0AThis is why I'm proposing we have a reaso= nable API for JavaScript using =0Atheir language constructs they already kn= ow and are familiar that is =0Aextensible for the future without more SDP m= angling/extensions. Those =0Awho want to do SDP extensions can do it inside= an updatable shim, which =0Acan be tailored to your specific SIP environme= nt to be 100% compatible =0Awith little to no risk the browser vendors will= break you.
    =0A
    =0AI fully appreciate the need that whatever API is p= roduced is not =0Aneedlessly complex and to ensure the absolutely dead-easy= implementation=0A exist. I plan to satisfy the dead-easy situation by prov= iding a shim =0Awritten entirely in JavaScript that provides that "80%" of = what people =0Awant, i.e. the current WebRTC API which is easy starting poi= nt for many =0ASIP integrators. Those of us who in the 20% who don't use SI= P can bypass=0A (or modify) the shim to do what they want/need.
    =0A
    = =0ASo I ask you, if I were to propose such a solution (and provide =0Aexamp= les), would you be open minded to using a shim that provides your =0Aeasy u= se case rather than forcing SDP inside of SDP being baked into =0Abrowser b= inary? Do you also understand my objections to using SDP with =0Aoffer/answ= er?
    =0A
    =0A-Robin
    =0A
    =0A
    =0A
    =09
    =0A 21 June, 2013 =0A5:40 AM
    <= /div>
    =0A
    Hello,=

    I'm=0A registere= d on this group since the beginning but this is my first post =0Aon this th= read. So, I presente myself: Mamadou DIOP and I'm working for =0ADoubango T= elecom where we're building SIP endpoints, gateways, =0ATelePresence/Teleme= dicine systems... all focused on SIP/IMS/LTE/RCS-e =0Aand open source.

    What=0A I'm ta= lking about is not just feeling but something I've experienced.

    Using=0A the current = WebRTC we have managed to *easily* build almost all kind of=0A applications= : click-to-call, SIP/IMS clients, gateways to PSTN, MCUs, =0ATelemedicine s= ystems...and haven't seen any major issue. It's true that =0Ait's not natur= al to "hack" a=0A blob SDP to implement features like hold/resume, media up= date, early =0Amedia ... but it works and there are demo applications showi= ng it. If =0Athere is something more beautiful we just want to see it in ac= tion and =0Atest it.

    = First on Windows 8 but =0Ahaven't gone far as there is no documentati= on to get started. Then, OSX =0Aand luckily there was a readme wi= th two links for testing (only one =0Awork). You need to open 3 pages (1 ma= ster, 2 slaves) and check "send =0Aaudio" on both slaves to header sound. M= any javascript files and no =0Adocumentation. It's said on these blogs that= interop with SIP networks =0Ais easy but it's not my feeling ...I just wan= t to see one :)


    For the current WebRTC, =0AGoogle open sourced their = engine, produced drafts, a working =0Aimplementation in chrome, a mail= ing-list to help developers, demo =0Aapplications, documentation... we just= want to see the same from any =0Acompany asking to rewrite everything.

    I'm not =0Asayin= g the current WebRTC implementation is perfect but I have seen my =0A14 yea= r old nephew developing an audio/video chat for his homework :)=

    Regards
    =0A
    =0A
    =0A
    =0A


    ---1470824145-266750018-1371826728=:58934 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-Id: <1.3795129437@web171304.mail.ir2.yahoo.com> Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= ---1470824145-266750018-1371826728=:58934-- ---1470824145-821007945-1371826728=:58934-- From ibc@aliax.net Fri Jun 21 08:01:32 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C5C21F940D for ; Fri, 21 Jun 2013 08:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.662 X-Spam-Level: X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI-d6KXjgVx5 for ; Fri, 21 Jun 2013 08:01:32 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E294721F93F8 for ; Fri, 21 Jun 2013 08:01:31 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id d13so633930qak.2 for ; Fri, 21 Jun 2013 08:01:31 -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=nsoKfB4T1MTZsfH5VpkxEpPNBtRNCmb/dSuiS6M5v4A=; b=Gg3nZLXHqVyMcsko+3GzcScFlar8DUQCZZ0b2sl2V2/lLxuI2LT9cV9cvNiU7xWOgX SkcbQZtmEObguYSXtugye7Y0nTs5t8Y1Fn2NGJ9u6y25B/HO4sFwf1yvrWePAYIuhSmn REb22SruodPmN+UjbO/8OX5sFowndCAAIxELPVzabB+NV+r/hRKZcAmYLJhnR3sHcu7l 9SWIqtAvhYNDemjPGJyJDmjrsITVkrzGdTUuynFkrTCZOy49zxlOBp1liXXHHhXYGKue zG9Z5YUvbed2+L8RRLTBzACvM6m9FDnf21XufozeO/h74RZfs63VZWdTWioLO/aBmiIk zo6g== X-Received: by 10.49.35.108 with SMTP id g12mr6029527qej.86.1371826891070; Fri, 21 Jun 2013 08:01:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Fri, 21 Jun 2013 08:01:10 -0700 (PDT) In-Reply-To: <1371826199.49975.YahooMailNeo@web171304.mail.ir2.yahoo.com> References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> <1371826199.49975.YahooMailNeo@web171304.mail.ir2.yahoo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 21 Jun 2013 17:01:10 +0200 Message-ID: To: Bossiel thioriguel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmS3UylYDhnLaZZ64/p/0VUoBYJdJ/nXQ8AihjK2jOQZihW1q+c/wuK6EjPSAgOfun1wvxp Cc: "diopmamadou@doubango.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:01:32 -0000 2013/6/21 Bossiel thioriguel : > Both audio and video. > Yes we're doing all you're listing here and even more. How much SDP parsing/mangling? -- I=C3=B1aki Baz Castillo From martin.thomson@gmail.com Fri Jun 21 08:58:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C9111E81A0 for ; Fri, 21 Jun 2013 08:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uUjriB9dXrl for ; Fri, 21 Jun 2013 08:58:27 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7A44A21F9FDA for ; Fri, 21 Jun 2013 08:58:25 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t59so6405733wes.6 for ; Fri, 21 Jun 2013 08:58:24 -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=T/B5uMkX54SVVliR8u5EpoLGQ9p1K5jb1a0Kicanw70=; b=bgN9NXz8zAA3J7G+yXVO8FhXXkyBwJBJlzxjiH7zrpvxvxSVtLtswoUivOF/YBtlW4 HIqWKYsUr6Uul7FvvQml/0LXRn05NkZBj8eKpipg/E/JweXDkMYqXi5NSQ59NmSPOaJp V0+oEhMMq4ZqnfBhPp/e+M9MqNkdFHvGT/rjVOug783jqFN0A51AoFMZ1ZtabFHjxdZF iweR4dhnv6FIzl++933Mm5mPoHhIyxKfVtaYju0TB/7R4XZ2/1MG8RSe9E6ZEJrVGTtm xLLv4trdHhmr7SRq4BCpUkgjyVj89jPiVFARhHt6NLbP6sLlon3Isrx0DV4rWrjyGdRf mUFQ== MIME-Version: 1.0 X-Received: by 10.180.9.212 with SMTP id c20mr2732180wib.65.1371830304466; Fri, 21 Jun 2013 08:58:24 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Fri, 21 Jun 2013 08:58:24 -0700 (PDT) In-Reply-To: <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> Date: Fri, 21 Jun 2013 08:58:24 -0700 Message-ID: From: Martin Thomson To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:58:27 -0000 On 20 June 2013 18:11, Hadriel Kaplan wrote: > criminals, drug dealers, mobsters, casinos, news organizations, political parties, and governments I assume that large corporations fit in this list in several places, so you chose to omit specific mention of those. There seems to be a fair amount of overlap in those categories as it stands. From roman@telurix.com Fri Jun 21 08:58:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E116821F9FB6 for ; Fri, 21 Jun 2013 08:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.704 X-Spam-Level: X-Spam-Status: No, score=-1.704 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NXW50sZCJgP for ; Fri, 21 Jun 2013 08:58:47 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id BAF5021E8133 for ; Fri, 21 Jun 2013 08:58:42 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so6533059wgh.6 for ; Fri, 21 Jun 2013 08:58:42 -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=Pshpph95MQtGgt9ACIlqhz0W/nBwBvwG2itzLdERuns=; b=DMa9Sj6C9MtOS1vxr9gfPacXgtaB47EpHdy9qiJQpmJ3iHHaBfjNkTEhhNlyBH/Yt0 0iJNFYbFDfT8r77QESK9lS0kNYFDuKNk51UMAAyp/bx9GYz7hygUwXR9ouo9GzPinDpt YyFyLSNWmy27ZFJrReEcGPLg7UVmqgR7WV+bn9MZagEOElcLLNnS8nZmb6/O49KS6mus X06f/oa+M1fLFKUQfCTO3Y5mWJSh86f2RTqb3x8KijmN4idvvp6sWuthgXRcBGGCUre2 xodIxAyGzCIGwqFYsLWANdkb2EkqGOz4nnhcMH0Q6MdZGLvLOlE7ucyu0D57HnpV56c5 H5Gg== X-Received: by 10.180.85.195 with SMTP id j3mr3255405wiz.26.1371830322049; Fri, 21 Jun 2013 08:58:42 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [2a00:1450:400c:c03::236]) by mx.google.com with ESMTPSA id o14sm23852506wiv.3.2013.06.21.08.58.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 08:58:40 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p60so6649851wes.27 for ; Fri, 21 Jun 2013 08:58:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.21.209 with SMTP id x17mr3170521wie.47.1371830319777; Fri, 21 Jun 2013 08:58:39 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Fri, 21 Jun 2013 08:58:39 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> Date: Fri, 21 Jun 2013 11:58:39 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b874000e70f8004dfac228f X-Gm-Message-State: ALoCoQmwZeOvQurKJslF9w64oPqdZ1L6Z8LypSJKm+atvPmmJRgeihxK2F8X3zEhS5pzoGzUM+0B Cc: "diopmamadou@doubango.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:58:48 -0000 --047d7b874000e70f8004dfac228f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jun 21, 2013 at 6:19 AM, I=F1aki Baz Castillo wrote= : > Is there anyone not involved in SIP/PSTN business which feels > comfortable with the SDP-based specs of WebRTC? > I am involved with SIP/PSTN and I am not comfortable with current WebRTC. What is trivial to implement is a server based gateway that will terminate and transcode media and signaling connection from WebRTC and connect WebRTC to anything. For this you take the open source code which implements WebRTC in Chrome, put it in your server and put a real SIP stack/media engine on the other side. This way all the SDP negotiation and media decoding is done using the same code as in the browser, and SIP/SDP negotiation on the SIP/PSTN side is done using normal SIP stack. By normal SIP stack I mean something that has been used with PSTN for significant period of time and has all the interop issues resolved, and all the necessary configuration parameters needed to work with SIP network implemented. Issues like hold do not matter, since they are handled on the SIP side and not passed to WebRTC side at all. Codec support, DTLS, ICE do not matter since they are handled by the WebRTC engine in the server. If this is what you want you have achieved your goal, but this is not a standard. There is no guarantee that this will work in 5 years or even in 6 month, since SDP produced by WebRTC can change. There is no guarantee that this will work with all the WebRTC implementations, since the standard is loose enough that significant things can be different while still being standard compliant. Finally, and most importantly, this will not work if you want to pass SDP and media produced by WebRTC to the outside world without transcoding it. P.S. Not to offend anybody, but if you create a system any idiot can use, only idiots will. _____________ Roman Shpount --047d7b874000e70f8004dfac228f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Fri, Jun 21, 2013 at 6:19 AM, I=F1aki Baz Cas= tillo <ibc@aliax.net> wrote:
    Is there anyone not involved in SIP/PSTN business which feels
    comfortable with the SDP-based specs of WebRTC?

    I am involved with SIP/PSTN and I am not comfortable with current = WebRTC.

    What is trivial to implement is a server b= ased gateway that will terminate and transcode media and signaling connecti= on from WebRTC and connect WebRTC to anything. For this you take the open s= ource code which implements WebRTC in Chrome, put it in your server and put= a real SIP stack/media engine on the other side. This way all the SDP nego= tiation and media decoding is done using the same code as in the browser, a= nd SIP/SDP negotiation on the SIP/PSTN side is done using normal SIP stack.= By normal SIP stack I mean something that has been used with PSTN for sign= ificant period of time and has all the interop issues resolved, and all the= necessary configuration parameters needed to work with SIP network impleme= nted. Issues like hold do not matter, since they are handled on the SIP sid= e and not passed to WebRTC side at all. Codec support, DTLS, ICE do not mat= ter since they are handled by the WebRTC engine in the server. If this is w= hat you want you have achieved your goal, but this is not a standard. There= is no guarantee that this will work in 5 years or even in 6 month, since S= DP produced by WebRTC can change. There is no guarantee that this will work= with all the WebRTC implementations, since the standard is loose enough th= at significant things can be different while still being standard compliant= . Finally, and most importantly, this will not work if you want to pass SDP= and media produced by WebRTC to the outside world without transcoding it.<= /div>

    P.S. Not to offend anybody, but if you create a system = any idiot can use, only idiots will.
    _____________
    Roman Shpou= nt
    =A0
    --047d7b874000e70f8004dfac228f-- From roman@telurix.com Fri Jun 21 09:01:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E954E21F9A93 for ; Fri, 21 Jun 2013 09:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9Oakuy0fNsS for ; Fri, 21 Jun 2013 09:01:44 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1797821F9BAC for ; Fri, 21 Jun 2013 09:01:41 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so6720417wgh.30 for ; Fri, 21 Jun 2013 09:01:41 -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=vs4ZF26a+0TyKavkmhcR+0w4IrwGiriAqLUyf/jBWT0=; b=Ql451JzInfRBYjoXhCnIGaUMnqB8abD0li3nDNruJ7sk2GPcXNCu70JRU/74xT+NfC XZcxa28ZFqkvVzEhKrxh58/VkoOmyB26x0Nac79Kb2XbgGqlDNy1+AcFoqufhFWcewhe wetY5VNdEC7NnUty6A8bkiIHNIxGlZ8itjVS0mL+jdQSECEsFCzGShm6bO1EIUP0b3CV uyVhvjrRMu91pZvD1BKPqJb22he5l09yE2+IVqDwvz4grC7/qS62i9BwLEt3DUlUCnNF bwnIaMWu0WCo/fkYa53FQi615u1eRcxUNEDkStHHIII6XsXs5Y36Mkxt0xvPAufhUogX jGCw== X-Received: by 10.180.183.104 with SMTP id el8mr3197571wic.43.1371830501247; Fri, 21 Jun 2013 09:01:41 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [2a00:1450:400c:c05::22a]) by mx.google.com with ESMTPSA id ft10sm8160284wib.7.2013.06.21.09.01.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 09:01:40 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so854274wid.1 for ; Fri, 21 Jun 2013 09:01:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.185.133 with SMTP id fc5mr3261112wic.8.1371830499562; Fri, 21 Jun 2013 09:01:39 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Fri, 21 Jun 2013 09:01:39 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115D4A59@MCHP04MSX.global-ad.net> References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> <9F33F40F6F2CD847824537F3C4E37DDF115D4A59@MCHP04MSX.global-ad.net> Date: Fri, 21 Jun 2013 12:01:39 -0400 Message-ID: From: Roman Shpount To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=001a11c355fe9e5a9b04dfac2d24 X-Gm-Message-State: ALoCoQlZ9bLqGKDdkZq3zRKQ5JWeA1f8V/vV84p9KVLoBOp+uKL7BKKdEdvhhdoXJxOcz/TTaWpt Cc: "rtcweb@ietf.org" , "diopmamadou@doubango.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 16:01:45 -0000 --001a11c355fe9e5a9b04dfac2d24 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 21, 2013 at 6:32 AM, Hutton, Andrew < andrew.hutton@siemens-enterprise.com> wrote: > > Which means we have not been as unsuccessful as people seem to think. > If building a demo or a high school home work is your goal, then yes. If you want the commercial product then no. I am not sure if you are familiar with 80/20 rule, but normally 20% of features require 80% of time to implement. In case of WebRTC it is 20% of features require 99% to implement. In other words, you get something working quick, but getting it to complete product take an inordinate amount of work. _____________ Roman Shpount --001a11c355fe9e5a9b04dfac2d24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Fri, Jun 21, 2013 at 6:32 AM, = Hutton, Andrew <andrew.hutton@siemens-enterprise.com> wrote:

    Which means we have not been as unsuccessful as people seem to think.

    If building a demo or a high school home wor= k is your goal, then yes. If you want the commercial product then no. I am = not sure if you are familiar with 80/20 rule, but normally 20% of features = require 80% of time to implement. In case of WebRTC it is 20% of features r= equire 99% to implement. In other words, you get something working quick, b= ut getting it to complete product take an inordinate amount of work.
    _____________
    Roman Shpount
    =A0
    --001a11c355fe9e5a9b04dfac2d24-- From martin.thomson@gmail.com Fri Jun 21 09:06:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFA911E81A4 for ; Fri, 21 Jun 2013 09:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfNB1aVV-6qr for ; Fri, 21 Jun 2013 09:06:00 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id E40E221E8125 for ; Fri, 21 Jun 2013 09:05:55 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so758071wgg.2 for ; Fri, 21 Jun 2013 09:05: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=eLgPU6YNeafp6VGm8NQMtbiAqE2sjaWM12oNfp5X69g=; b=VmBhljyR39QvdmXSJ15zQGTMwEaxb+YXPsNGqnvK2FSuNznGhLhncHriFm9u7l2i22 9RtQdLlYj6RZe8dJibRcYMQnBczIKI8lCXOFCxy6pEkfjjcBt2oynuUM33GSxPUXrCYj VtU+S8Yj/+20f8oR33UuFZ6+yVGqCyJbYcdZLR7LSC5HTZV5G42sdo9/bsBpK3aNy83p FYIw8N4oMzsSuy2hljboI9wpIsyl3TVhxiJXv4AEXirNj94MzigbM10LVDEp1Ik689M+ 0KQKdLO8IadLOx5n+H+cgnKRFVTeuj5ex3Il9y0/WBt1gesZ0pqrxhT8zvUwPIdBLFQy DahA== MIME-Version: 1.0 X-Received: by 10.194.78.110 with SMTP id a14mr9633862wjx.84.1371830755058; Fri, 21 Jun 2013 09:05:55 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Fri, 21 Jun 2013 09:05:54 -0700 (PDT) In-Reply-To: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115D2D76@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF115D2E8D@MCHP04MSX.global-ad.net> Date: Fri, 21 Jun 2013 09:05:54 -0700 Message-ID: From: Martin Thomson To: Richard Barnes Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 16:06:00 -0000 On 20 June 2013 19:18, Richard Barnes wrote: > What interesting scenarios do you have in mind? I doubt that they are critical, but to give you some idea, Skype mixes audio on a peer for group calls. It avoids the need for a server or a full mesh. That's mixing, but it could also be switching (especially if it were for video). The the latter is something that CU-RTC-Web could do, we didn't go to the extent of doing pass-through without decrypt+decode, which is in optimization-land; I don't believe that it's v1 critical, mainly because we've never discussed this before, so it seems unlikely. One of the major concerns with the current API surface is how it precludes as many scenarios as it enables, and this is another... hang on, sorry, wrong thread. From dwing@cisco.com Fri Jun 21 09:45:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3463E11E8193 for ; Fri, 21 Jun 2013 09:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.276 X-Spam-Level: X-Spam-Status: No, score=-110.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWUgc+cN6P6M for ; Fri, 21 Jun 2013 09:45:42 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 130C721E8112 for ; Fri, 21 Jun 2013 09:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5236; q=dns/txt; s=iport; t=1371833139; x=1373042739; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RdOYkyA35aI/Cd/YVZcEJOLZ5xLUzAPQGIuNwhH0e4c=; b=NcD1GXjAy17OaL5pldvsuvBRKIHK5zU7ivGGDH1vh0CJWYJq4ViqD+dX gS8QZEOh5aJoo4uh9pqWFowHYQGy2c48qEoe0+Y8728qOk1ALsBsvlQN6 NhUIDh8s+MzAbdZs6iy4m5R8EYqkG6aZnso5L2WEHcWOfP42fNyAWvvYW 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAPOBxFGrRDoH/2dsb2JhbABSCYMJMb9+gQQWdIIjAQEBAwEBAQE3NAsQCxguJzAGE4gIBQ28SY4OBIEEMweDAGEDiSGOIpFEgy8cgS0 X-IronPort-AV: E=Sophos;i="4.87,914,1363132800"; d="scan'208";a="84075228" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 21 Jun 2013 16:45:36 +0000 Received: from sjc-vpn3-98.cisco.com (sjc-vpn3-98.cisco.com [10.21.64.98]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5LGjZlr015319; Fri, 21 Jun 2013 16:45:35 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <529DCF4E-2A8B-475F-8CCE-7E2ABC72EFB1@oracle.com> Date: Fri, 21 Jun 2013 09:45:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2C6DDF0C-201D-4CA3-8EB0-F14B8A2D5758@cisco.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> <529DCF4E-2A8B-475F-8CCE-7E2ABC72EFB1@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 16:45:47 -0000 On Jun 20, 2013, at 7:58 PM, Hadriel Kaplan = wrote: >=20 > On Jun 20, 2013, at 10:14 PM, Richard Barnes wrote: >=20 >>> It's more secure in the sense that JS can't access the key, so an = injected script can't grab the key and exfiltrate it. So the browser = user is better protected against XSS risks. >>=20 >> This part I'd like to understand better. Can you explain it? >> If a Browser cannot determine what server the JS being executed for = WebRTC API calls/callbacks came from, or cannot tell if it came from one = over HTTPS in particular, then using SDES might be a real problem. I = was under the impression browsers did know those things (or at least = that they're theoretically supposed to, ignoring that there are "bugs" = here and there). >>=20 >> As with many things in the web security model, the answer is "It's = complicated". The wikipedia article on XSS is pretty good. >> >>=20 >> The upshot is that your typical web page gets cobbled together out of = many pieces, often from different domains. Scripts from multiple = sources get imported into the overall security context of the page. = This composition can happen deliberately (e.g., mashups, JS libraries) = or maliciously (XSS). Let me provide an example of each: >>=20 >> 1. Suppose I use jQuery to do pretty layout on my page. There's = nothing that actually constrains jQuery to only do layout. If jQuery is = out to get me, it could do something like overwrite = window.PeerConnection, so that all of the page's WebRTC calls go through = the jQuery library and are subject to its control. So if the = PeerConnection API exposes keys, jQuery can steal them. >=20 > We've talked about that one before I think. If jQuery is out to get = you, it's game over. It's essentially equivalent to a malicious = web-server, except of course that the operator of the web-server isn't = intending to be malicious (which is an important distinction). But = again, not only does jQuery have access to information such as who = you're talking to and when, it can also redirect your media to a gateway = of its choosing to terminate the DTLS-SRTP and record it, by fiddling = with the JSON/SDP stuff. For the attacker to succeed with the redirection of DTLS-SRTP to a = server it controls, the attacker would also need to modify the SDP's = a=3Dfingerprint line which is as trivial as the attacker's other SDP = modifications. To prevent the attacker from succeeding with such = modification, we need cryptographic identity (to protect the = From/To/Date/a=3Dfingerprint and other fields), and need the browser = (not JS) to verify the identity using an external service (e.g., local = disk, IdP separate from the web server providing us the (compromised) JS = and the SDP). While it is true that today we don't have a way today to = provide that cryptographic identity (RFC4474 does not work, = draft-wing-rtcweb-identity-media written by me and Hadriel was met with = silence) DTLS-SRTP creates the foundation to build cryptographic = identity which can be verified by the browser itself. Such = cryptographic identity protects from this specific attack, and DTLS-SRTP = protects from other attacks. -d >=20 >=20 >> 2. Suppose the overall page is loaded over HTTPS, but one of the = scripts is loaded over HTTP. Then the overall security context for the = page is HTTPS, but if an attacker can hijack that HTTP load to introduce = a script, in which case he can do the same bad stuff that jQuery could = in the above example. (This is why we have the following sentence in = draft-ietf-rtcweb-security-arch: "It is RECOMMENDED that browsers which = allow active mixed content nevertheless disable RTCWEB functionality in = mixed content settings." >=20 > Right, and I think we've talked about that before too in the context = of SDES: I think people were ok with limiting it further for SDES with a = statement saying it must not be used in mixed content settings if one of = the scripts came in on HTTP. (although I could be wrong on whether any = consensus was reached on that point - it was a long time ago and I have = a memory leak) >=20 >=20 >> There are mitigations to a lot of these sorts of issues, but some are = still being developed. And of course, there's no guarantee that a given = site will follow all the best practices. So it seems sensible to limit = the damage that an injected script can do. >=20 > Right, and I'm hoping the Browser vendors can tell us if browsers can = safely know whether all the JS running on a given page is from HTTPS or = not, and not allow SDES if the JS is not all from (signed) HTTPS. If = not, then I agree that's another negative downside for SDES. In fact I = think it's even a problem for DTLS-SRTP. I don't know why we'd be ok = with using HTTP at all, if we're *truly* concerned about MitM and = malicious 3rd party JS attacks.=20 >=20 > -hadriel >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From andrew.hutton@siemens-enterprise.com Fri Jun 21 09:52:12 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A2A21F9D7B for ; Fri, 21 Jun 2013 09:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXhgB7+lKxUi for ; Fri, 21 Jun 2013 09:52:07 -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 CB11821F9E7D for ; Fri, 21 Jun 2013 09:52:03 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id D9E4D1EB85A9; Fri, 21 Jun 2013 18:52:01 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Fri, 21 Jun 2013 18:52:01 +0200 From: "Hutton, Andrew" To: Roman Shpount Thread-Topic: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Thread-Index: AQHObmjByY7ZqkO+CkSPIPqSfmn6rpk/9zkggAA7qICAAC+Z2w== Date: Fri, 21 Jun 2013 16:52:00 +0000 Message-ID: <4337C1D6-5D1E-4316-A96B-E6FBA2E647E7@siemens-enterprise.com> References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> <9F33F40F6F2CD847824537F3C4E37DDF115D4A59@MCHP04MSX.global-ad.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4337C1D65D1E4316A96BE6FBA2E647E7siemensenterprisecom_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "diopmamadou@doubango.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 16:52:12 -0000 --_000_4337C1D65D1E4316A96BE6FBA2E647E7siemensenterprisecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Now this is getting ridiculous. You do know that one of the goals is to build an API that web developers wi= thout knowledge of IETF protocols can use to build apps. I was only using t= his as an example where this has been achieved. I also think you know that there are many apps out there already which are = much more than high school projects. I believe we are simply making life difficult by trying to do too much at o= nce and we need to rethink what is really needed and deliver on what we ha= ve said we we will deliver please read the charter. Andy On 21 Jun 2013, at 17:01, "Roman Shpount" > wrote: On Fri, Jun 21, 2013 at 6:32 AM, Hutton, Andrew > wrote: Which means we have not been as unsuccessful as people seem to think. If building a demo or a high school home work is your goal, then yes. If yo= u want the commercial product then no. I am not sure if you are familiar wi= th 80/20 rule, but normally 20% of features require 80% of time to implemen= t. In case of WebRTC it is 20% of features require 99% to implement. In oth= er words, you get something working quick, but getting it to complete produ= ct take an inordinate amount of work. _____________ Roman Shpount --_000_4337C1D65D1E4316A96BE6FBA2E647E7siemensenterprisecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Now this is getting ridiculous.

    You do know that one of the goals is to build an API that web develope= rs without knowledge of IETF protocols can use to build apps. I was only us= ing this as an example where this has been achieved.

    I also think you know that there are many apps out there already which= are much more than high school projects.

    I believe we are simply making life difficult by trying to do too much= at once  and we need to rethink what is really needed and deliver on = what we have said we we will deliver please read the charter.

    Andy

    On Fri, Jun 21, 2013 at 6:32 AM, Hutton, Andrew = <andrew.hutton@siemens-enterprise.com> wrote:

    Which means we have not been as unsuccessful as people seem to think.

    If building a demo or a high school home work is your goal, then yes. = If you want the commercial product then no. I am not sure if you are famili= ar with 80/20 rule, but normally 20% of features require 80% of time to imp= lement. In case of WebRTC it is 20% of features require 99% to implement. In other words, you get somethin= g working quick, but getting it to complete product take an inordinate amou= nt of work.
    _____________
    Roman Shpount
     
    --_000_4337C1D65D1E4316A96BE6FBA2E647E7siemensenterprisecom_-- From hadriel.kaplan@oracle.com Fri Jun 21 09:56:46 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C2E21F9E21 for ; Fri, 21 Jun 2013 09:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRQCzVpbSM4B for ; Fri, 21 Jun 2013 09:56:40 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id DF2BF21F9C93 for ; Fri, 21 Jun 2013 09:56:37 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5LGuZPI010373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 16:56:35 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5LGuYw5014838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 16:56:34 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5LGuXH2022191; Fri, 21 Jun 2013 16:56:33 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 Jun 2013 09:56:33 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Fri, 21 Jun 2013 12:56:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <068A0A68-0E24-433E-92D9-CE85254DD620@oracle.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> To: Martin Thomson X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 16:56:46 -0000 On Jun 21, 2013, at 11:58 AM, Martin Thomson = wrote: > On 20 June 2013 18:11, Hadriel Kaplan = wrote: >> criminals, drug dealers, mobsters, casinos, news organizations, = political parties, and governments >=20 > I assume that large corporations fit in this list in several places, > so you chose to omit specific mention of those. =20 Yes I chose to omit them. Not because I think large corporations are = angels, but because I think there are fairly effective mechanisms in = place to keep large corporations from being malicious in terms of = recording audio/video you don't expect to be recorded: laws, law suits = and brand reputation. That's why I think even direct competitors of Cisco are willing to use = WebEx - and my last 4 employers all used WebEx and were all direct = competitors of Cisco - not because we think it's impossible for the = WebEx server to do it, nor because we believe they don't store keys or = whatever, but rather because we know if they got caught doing it on = purpose for malicious use then they'd be sued for blood, and the = reputation of WebEx would be so tarnished as to be put out of existence. Obviously there are some large corporations I won't name that my = employers probably feel couldn't be held accountable or in-check in = those ways - but we would never trust such large corporations no matter = what key-exchange mechanism WebRTC uses. In fact, even if WebRTC could = provide a key-exchange that no malicious MITM could bypass, we still = wouldn't trust such corporations - because the information in the JSON = is almost as important as the conversation audio/video: it identifies = who's communicating with whom, for how long, from where, and often even = on what subject. That's one of the reasons I was saying the other day: = if the web-server or JS is truly malicious or compromised, it's game = over. > There seems to be a > fair amount of overlap in those categories as it stands. I get the impression each one might not be a criminal in some = country-or-other's perspective. Arguably for some countries, *all* of them are "criminals". ;) -hadriel From hadriel.kaplan@oracle.com Fri Jun 21 10:15:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B324521F9FAB for ; Fri, 21 Jun 2013 10:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.255 X-Spam-Level: X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44v9lvWCodDB for ; Fri, 21 Jun 2013 10:15:05 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id DCFEE21F9FA0 for ; Fri, 21 Jun 2013 10:14:56 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5LHErc3029122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 17:14:53 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5LHEpq9026394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 17:14:52 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5LHEpew005119; Fri, 21 Jun 2013 17:14:51 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 Jun 2013 10:14:50 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <2C6DDF0C-201D-4CA3-8EB0-F14B8A2D5758@cisco.com> Date: Fri, 21 Jun 2013 13:14:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> <529DCF4E-2A8B-475F-8CCE-7E2ABC72EFB1@oracle.com> <2C6DDF0C-201D-4CA3-8EB0-F14B! 8A2D5758@cisco.com> To: Dan Wing X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:15:11 -0000 On Jun 21, 2013, at 12:45 PM, Dan Wing wrote: >> We've talked about that one before I think. If jQuery is out to get = you, it's game over. It's essentially equivalent to a malicious = web-server, except of course that the operator of the web-server isn't = intending to be malicious (which is an important distinction). But = again, not only does jQuery have access to information such as who = you're talking to and when, it can also redirect your media to a gateway = of its choosing to terminate the DTLS-SRTP and record it, by fiddling = with the JSON/SDP stuff. >=20 > For the attacker to succeed with the redirection of DTLS-SRTP to a = server it controls, the attacker would also need to modify the SDP's = a=3Dfingerprint line which is as trivial as the attacker's other SDP = modifications. To prevent the attacker from succeeding with such = modification, we need cryptographic identity (to protect the = From/To/Date/a=3Dfingerprint and other fields), and need the browser = (not JS) to verify the identity using an external service (e.g., local = disk, IdP separate from the web server providing us the (compromised) JS = and the SDP). While it is true that today we don't have a way today to = provide that cryptographic identity (RFC4474 does not work, = draft-wing-rtcweb-identity-media written by me and Hadriel was met with = silence) DTLS-SRTP creates the foundation to build cryptographic = identity which can be verified by the browser itself. Such = cryptographic identity protects from this specific attack, and DTLS-SRTP = protects from other attacks. I agree - when we have such a thing, using DTLS-SRTP will have much more = meaning. But (1) there is no such thing yet, and (2) it won't make = DTLS-SRTP nor DTLS-EKT any stronger than SDES for the SIP-gateway = scenarios we're talking about, since the DTLS isn't going end-to-end. = I.e., none of the calls would successfully authenticate using such an = out-of-band mechanism, even the good ones. [note though I'm not saying DTLS-SRTP is useless today - quite the = contrary, I hummed in favor of making it MTI back when that was decided, = and I still think it should be MTI] -hadriel From robin@hookflash.com Fri Jun 21 10:37:40 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57CA21F9CF6 for ; Fri, 21 Jun 2013 10:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rAwmmVBO-Ve for ; Fri, 21 Jun 2013 10:37:39 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 72E3A21F9D0A for ; Fri, 21 Jun 2013 10:37:35 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 9so19284493iec.5 for ; Fri, 21 Jun 2013 10:37:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=NNImlpzmF4srfOlexzdDV0qWgAtxzWSkf9ol9Nsvfks=; b=O68vu0CvgE13/IxZO0/OoDfN8mNpAFue4tk1C5s1+9QrkAUBH50JZgvV7I8mmqXIyB DIwFWa4R16m3V+L7MlOGUsJvym30aZ40Y/5+tMg+BsT4LQtGsNPzdd2ppIT1KY8Nr9Et XQm/AuKw048uOg4RmVm51GEk0Ka2nrY6z/sIzR45K4uJly2aFIqd87fq1y+7c8iaVJLy J8BF/Hx/Azi5eBHulM7sRdOscvhxwViRstW13GcwLHDfZ5iSiTauw6zS1m63AZB7VEKh oq9Tb8F5G7Z/LZlnPzxdei/Ul3Th6a7bYqUh0qfMiipnPnBTO3OKBb3RAiJGYs00/GVw Gtqg== X-Received: by 10.42.29.2 with SMTP id p2mr3085586icc.70.1371836239263; Fri, 21 Jun 2013 10:37:19 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id ir8sm6047772igb.6.2013.06.21.10.37.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 10:37:18 -0700 (PDT) Message-ID: <51C48F4A.9070707@hookflash.com> Date: Fri, 21 Jun 2013 13:37:14 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: "Hutton, Andrew" References: <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> <9F33F40F6F2CD847824537F3C4E37DDF115D4A59@MCHP04MSX.global-ad.net>, <4337C1D6-5D1E-4316-A96B-E6FBA2E647E7@siemens-enterprise.c om> In-Reply-To: <4337C1D6-5D1E-4316-A96B-E6FBA2E647E7@siemens-enterprise.com> Content-Type: multipart/alternative; boundary="------------030400070603000708070308" X-Gm-Message-State: ALoCoQk7gjeEPC8QLViAOv3PaEqeXN6QpC92LcuthUzsdsFRqu2v7an8SXQ1Xb5jlX6OS0Dd1LGt Cc: "diopmamadou@doubango.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:37:40 -0000 This is a multi-part message in MIME format. --------------030400070603000708070308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To me the issue is not easy of use but compatibility, as what is produced should increase compatibility not decrease it. That's one of the major drawbacks of SDP with offer/answer as I've described numerous times -- it increases incompatibility rather than decreases it. I too want to see an API where people don't need to understand a complex mechanism to be able to produce a suitable application. Unfortunately, the current SDP approach all too often requires learning SDP by JavaScript developers to perform normal edge case scenarios (e.g. putting media on/off hold). That's simply not acceptable in my mind. That's why I will drafting up an alternative approach which can have a reasonable non-SDP based API without offer/answer but I will provide a JavaScript shim on top that will provide the current "simple" approach, including being able perform offer/answer using SDP (as some people prefer). This should more than adequately satisfy the charter's limited 1.0 goals and responsibilities and give the non-SDP people a basis for moving forward where they can feel comfortable will satisfy their needs as well. -Robin > Hutton, Andrew > 21 June, 2013 12:52 PM > Now this is getting ridiculous. > > You do know that one of the goals is to build an API that web > developers without knowledge of IETF protocols can use to build apps. > I was only using this as an example where this has been achieved. > > I also think you know that there are many apps out there already which > are much more than high school projects. > > I believe we are simply making life difficult by trying to do too much > at once and we need to rethink what is really needed and deliver on > what we have said we we will deliver please read the charter. > > Andy > --------------030400070603000708070308 Content-Type: multipart/related; boundary="------------000301090800030703040306" --------------000301090800030703040306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    To me the issue is not easy of use but compatibility, as what is produced should increase compatibility not decrease it. That's one of the major drawbacks of SDP with offer/answer as I've described numerous times -- it increases incompatibility rather than decreases it.

    I too want to see an API where people don't need to understand a complex mechanism to be able to produce a suitable application. Unfortunately, the current SDP approach all too often requires learning SDP by JavaScript developers to perform normal edge case scenarios (e.g. putting media on/off hold). That's simply not acceptable in my mind.

    That's why I will drafting up an alternative approach which can have a reasonable non-SDP based API without offer/answer but I will provide a JavaScript shim on top that will provide the current "simple" approach, including being able perform offer/answer using SDP (as some people prefer). This should more than adequately satisfy the charter's limited 1.0 goals and responsibilities and give the non-SDP people a basis for moving forward where they can feel comfortable will satisfy their needs as well.

    -Robin



    21 June, 2013 12:52 PM
    Now this is getting ridiculous.

    You do know that one of the goals is to build an API that web developers without knowledge of IETF protocols can use to build apps. I was only using this as an example where this has been achieved.

    I also think you know that there are many apps out there already which are much more than high school projects.

    I believe we are simply making life difficult by trying to do too much at once  and we need to rethink what is really needed and deliver on what we have said we we will deliver please read the charter.

    Andy

    --------------000301090800030703040306 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------000301090800030703040306-- --------------030400070603000708070308-- From dwing@cisco.com Fri Jun 21 11:00:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135B911E81A7 for ; Fri, 21 Jun 2013 11:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.256 X-Spam-Level: X-Spam-Status: No, score=-110.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqUQ+iW7WdUT for ; Fri, 21 Jun 2013 10:59:56 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2942D11E8193 for ; Fri, 21 Jun 2013 10:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2730; q=dns/txt; s=iport; t=1371837596; x=1373047196; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=59K9AFcEnH8MXwMMrCgYoaMQbd9xv3/ETcn/bTs+et0=; b=gb0RLYU/kRG2UNlnk34CgPyEQ2SVmF6Jv+SXEUBS2frV6qQWqKNj//X4 5S0vnyTDHZnnZa07ZKgJWVoNcaq+9TSIcUOEakkfYefukZnd3xEPjH5BW h5n1g8yII/Jh/6Il8A5mZZt97yZ616UzcoW6AjXYdYyXfs/pCUU3BOqOh s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAD2UxFGrRDoI/2dsb2JhbABSCYMJwC+BBRZ0giMBAQEDATo/EAsYLlcGE4gIBbxXjg6BCDMHgwBhA4khjiKRRIMvHA X-IronPort-AV: E=Sophos;i="4.87,914,1363132800"; d="scan'208";a="80994055" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 21 Jun 2013 17:59:53 +0000 Received: from sjc-vpn3-98.cisco.com (sjc-vpn3-98.cisco.com [10.21.64.98]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5LHxrmr029720; Fri, 21 Jun 2013 17:59:53 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Fri, 21 Jun 2013 10:59:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <12C17BE5-2302-48E9-A745-5B7265E83E8E@cisco.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> <529DCF4E-2A8B-475F-8CCE-7E2ABC72EFB1@oracle.com> <2C6DDF0C-201D-4CA3-8EB0-F14B! 8A2D5758@cisco.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 18:00:02 -0000 On Jun 21, 2013, at 10:14 AM, Hadriel Kaplan = wrote: >=20 > On Jun 21, 2013, at 12:45 PM, Dan Wing wrote: >=20 >>> We've talked about that one before I think. If jQuery is out to get = you, it's game over. It's essentially equivalent to a malicious = web-server, except of course that the operator of the web-server isn't = intending to be malicious (which is an important distinction). But = again, not only does jQuery have access to information such as who = you're talking to and when, it can also redirect your media to a gateway = of its choosing to terminate the DTLS-SRTP and record it, by fiddling = with the JSON/SDP stuff. >>=20 >> For the attacker to succeed with the redirection of DTLS-SRTP to a = server it controls, the attacker would also need to modify the SDP's = a=3Dfingerprint line which is as trivial as the attacker's other SDP = modifications. To prevent the attacker from succeeding with such = modification, we need cryptographic identity (to protect the = From/To/Date/a=3Dfingerprint and other fields), and need the browser = (not JS) to verify the identity using an external service (e.g., local = disk, IdP separate from the web server providing us the (compromised) JS = and the SDP). While it is true that today we don't have a way today to = provide that cryptographic identity (RFC4474 does not work, = draft-wing-rtcweb-identity-media written by me and Hadriel was met with = silence) DTLS-SRTP creates the foundation to build cryptographic = identity which can be verified by the browser itself. Such = cryptographic identity protects from this specific attack, and DTLS-SRTP = protects from other attacks. >=20 > I agree - when we have such a thing, using DTLS-SRTP will have much = more meaning. But (1) there is no such thing yet, and (2) it won't make = DTLS-SRTP nor DTLS-EKT any stronger than SDES for the SIP-gateway = scenarios we're talking about, since the DTLS isn't going end-to-end. = I.e., none of the calls would successfully authenticate using such an = out-of-band mechanism, even the good ones. >=20 > [note though I'm not saying DTLS-SRTP is useless today - quite the = contrary, I hummed in favor of making it MTI back when that was decided, = and I still think it should be MTI] Will the existence of SDES prevent WebRTC from building this more secure = system with strong identity? That is, when we add cryptographic = identity will that be effective to prevent a bid-down attack from = DTLS-SRTP to SDES? I am thinking right now that when we add identity we = can prevent that bid-down, so at that time SDES could become a proper = second-class citizen. -d From martin.thomson@gmail.com Fri Jun 21 11:16:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9A721F9811 for ; Fri, 21 Jun 2013 11:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uT0ZX7hR9Ka5 for ; Fri, 21 Jun 2013 11:16:27 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4790D21F979E for ; Fri, 21 Jun 2013 11:16:27 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so902890wiv.8 for ; Fri, 21 Jun 2013 11:16: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:content-transfer-encoding; bh=518OThJwBxEXIAd8klhV/K5M6w7Ak4vJ2PLeuJ+3oL4=; b=pf9ZCs2FE6c5kncvP+cGgjn6ErFJ82tjtp/ELf4Ovr5kFNsW4B84ccWs1kYghff+gX HnG6JXY1FM+284N9QUP0ooAti02dbeY/o5Y5m7R1iyxdRaJs+PgdAjeEI1vqgYAjqQMH OPlQ+P9EVg7DYvC5rbhCiJkYS03g8OV/7mOtl7gbCJGJsjrb9OqS5CoYdnAaBXeQpSdu YnqLJHOeszV9aIWeUJIR0k7t9yH3B18+tfUWp8MWheRNN2n2TSXu0qZQwtFHNKbrZJUK ps+sbz1A6ToCOZUhvbeLaSBu9QlD+YSSSGnSyKPRrn0j5MBovhSkntakxbExMqWmMRNf X64Q== MIME-Version: 1.0 X-Received: by 10.180.20.46 with SMTP id k14mr3623942wie.14.1371838586447; Fri, 21 Jun 2013 11:16:26 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Fri, 21 Jun 2013 11:16:26 -0700 (PDT) In-Reply-To: <12C17BE5-2302-48E9-A745-5B7265E83E8E@cisco.com> References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> <529DCF4E-2A8B-475F-8CCE-7E2ABC72EFB1@oracle.com> <12C17BE5-2302-48E9-A745-5B7265E83E8E@cisco.com> Date: Fri, 21 Jun 2013 11:16:26 -0700 Message-ID: From: Martin Thomson To: Dan Wing Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 18:16:28 -0000 On 21 June 2013 10:59, Dan Wing wrote: > Will the existence of SDES prevent WebRTC from building this more secure = system with strong identity? That is, when we add cryptographic identity w= ill that be effective to prevent a bid-down attack from DTLS-SRTP to SDES? = I am thinking right now that when we add identity we can prevent that bid-= down, so at that time SDES could become a proper second-class citizen. I have thought about this a little and I can't work out a practical bid-down. That is, aside from the human factors/social engineering problems, which exist in all cases. From matthew.kaufman@skype.net Fri Jun 21 13:20:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E9021F9C45 for ; Fri, 21 Jun 2013 13:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enba+fF6fonN for ; Fri, 21 Jun 2013 13:20:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id C4C5821F9C21 for ; Fri, 21 Jun 2013 13:20:07 -0700 (PDT) Received: from BY2FFO11FD028.protection.gbl (10.1.15.201) by BY2FFO11HUB038.protection.gbl (10.1.14.121) with Microsoft SMTP Server (TLS) id 15.0.707.0; Fri, 21 Jun 2013 20:20:05 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD028.mail.protection.outlook.com (10.1.15.217) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Fri, 21 Jun 2013 20:20:05 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.171]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0136.001; Fri, 21 Jun 2013 20:19:51 +0000 From: "Matthew Kaufman (SKYPE)" To: Bossiel thioriguel , "diopmamadou@doubango.org" Thread-Topic: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Thread-Index: AQHObEI8XC7enqULikaWynaBYkCsupk76I4AgAACKQCAAB+igIAAApYAgAB4ZYCAABBRgIAABAmAgAB39oCAACnpgIAAAi8AgAADxACAABUlgIAAA5iAgAAerwCAAAIjgIABQzyAgAAL4ICAAA2ZgIAAT8mAgAAMcACAAA4FgIAArBEAgACxusA= Date: Fri, 21 Jun 2013 20:19:50 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> In-Reply-To: <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2E3F53TK5EX14MBXC273r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704005)(189002)(199002)(24454002)(479174003)(377454003)(63696002)(47736001)(51856001)(47976001)(33656001)(55846006)(44976004)(54316002)(81542001)(74876001)(49866001)(81342001)(56776001)(4396001)(74366001)(20776003)(71186001)(16297215004)(50986001)(80022001)(46102001)(76786001)(69226001)(65816001)(53806001)(66066001)(76482001)(15202345003)(76796001)(74706001)(54356001)(56816003)(31966008)(77096001)(16236675002)(59766001)(16406001)(79102001)(74662001)(47446002)(74502001)(6806003)(512934002)(77982001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB038; H:TK5EX14MLTC103.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0884AAA693 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 20:20:19 -0000 --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2E3F53TK5EX14MBXC273r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bossiel thioriguel : "I don't really understand the issue with the O/A mode= l. SDP or not SDP you'll always offer something and answer something. I'm I= missing?" What you are missing is that you *don't* "always offer something and answer= something. There is a completely different programming model where the ser= ver or program executing on the client is entirely in control of what happe= ns. As an example, if I say "draw a box that is 10 pixels wide and 10 pixels hi= gh" that's me telling the browser what to do. With offer/answer, I would sa= y "I would like a box, what size boxes can you draw?" and the browser would= respond with a list, and I would pick one of those. RTCWEB is the *only* case where someone is seriously proposing an API that = doesn't allow the programmer to directly control the behavior of the browse= r. Matthew Kaufman From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Bossiel thioriguel Sent: Friday, June 21, 2013 2:40 AM To: diopmamadou@doubango.org Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Hello, I'm registered on this group since the beginning but this is my first post = on this thread. So, I presente myself: Mamadou DIOP and I'm working for Dou= bango Telecom where we're building SIP endpoints, gateways, TelePresence/Te= lemedicine systems... all focused on SIP/IMS/LTE/RCS-e and open source. What I'm talking about is not just feeling but something I've experienced. Using the current WebRTC we have managed to *easily* build almost all kind = of applications: click-to-call, SIP/IMS clients, gateways to PSTN, MCUs, Te= lemedicine systems...and haven't seen any major issue. It's true that it's = not natural to "hack" a blob SDP to implement features like hold/resume, me= dia update, early media ... but it works and there are demo applications sh= owing it. If there is something more beautiful we just want to see it in ac= tion and test it. Many participants here have said that what they want is something close to = CU-RTC-WEB. Don't really know if they tried to build applications using it = or not but in my case I have. My reference: http://html5labs.interoperabilitybridges.com/prototypes/cu-rt= c-web-roaming/cu-rtc-web-roaming/info First on Windows 8 but haven't gone far as there is no documentation to get= started. Then, OSX and luckily there was a readme with two links for testi= ng (only one work). You need to open 3 pages (1 master, 2 slaves) and check= "send audio" on both slaves to header sound. Many javascript files and no = documentation. It's said on these blogs that interop with SIP networks is e= asy but it's not my feeling ...I just want to see one :) I don't really understand the issue with the O/A model. SDP or not SDP you'= ll always offer something and answer something. I'm I missing? For the current WebRTC, Google open sourced their engine, produced drafts, = a working implementation in chrome, a mailing-list to help developers, demo= applications, documentation... we just want to see the same from any compa= ny asking to rewrite everything. I'm not saying the current WebRTC implementation is perfect but I have seen= my 14 year old nephew developing an audio/video chat for his homework :) Regards ________________________________ De : I=F1aki Baz Castillo > =C0 : Emil Ivov > Cc : "rtcweb@ietf.org" > Envoy=E9 le : Vendredi 21 juin 2013 1h24 Objet : Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened 2013/6/21 Emil Ivov >: > > On 20.06.13, 23:49, I=F1aki Baz Castillo wrote: >> >> In JsSIP we are getting frustrated trying to implement the "hold" / >> "unhold" feature because it requires SDP parsing and mangling. Sending >> a re-INVITE with a modified SDP (now with a video track enabled) seems >> to work (after lot of pain) but we still miss a reliable API to know >> what the new SDP means. Instead we need to parse the SDP to detect >> global (or per m=3D) line attributes like "a=3Dinactive" or "a=3Dsendonl= y" >> etc etc. It's really painful. > > > I am having a problem following what you are trying to achieve here. In > JsSIP you seem to be going for a full SIP implementation in the browser. = If > this is true and if this WG decides to remove SDP from the API surface, t= hen > you would need to completely parse SDP in the JS and then convert it into > API calls. Similarly, when creating offers and answers you would need to > construct SDP all by yourself. And we will do it very happily because then we will know what *exactly* we are sending on-the-wire. > So I am not sure why the SDP parsing in the current situation is so much = of > a blocker for your use case. Because regardless I am a SIP-guy, I understand that the main mission of WebRTC is to provide realtime communications *for* the WWW, and not to enable a new interface for like-telephony-bussines. Today I'm doing SIP. Tomorrow I may be doing [[put_here_a_future_RTC_protocol_not_based_on_SDP]] and then I don't want to be constrained by decisions made today that force any future RTC protocol to deal with SDP O/A model. :) >> BTW I don't know wheter you support PlanA, PlanB or NoPlan, but I did >> a question (in this case about NoPlan) for which I got no response, >> and honestly I would like to see it replied regardless the solution >> uses PlanA, PlanB or NoPlan model: >> >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07871.html >> > The other option would be indeed to do the same thing in JS. I believe th= is > is JsSIP's use case. In that case however, regardless of whether you choo= se > Plan A, Plan B, No Plan or CU-RTC-Web, you will inevitably be exposed to = a > fair amount of complexity, parsing and JS magic. > > You are, after all, building a SIP stack. Yes, but JsSIP creates its own SIP messages to be sent in the wire, so we have full control over *what* we create and send. Those SIP messages are not provided by the WebRTC API. But for the SDP component, JsSIP retreives a SDP blob string from the PC. > > In the above mail you also say: > >> Another example: >> >> * I am a powerful SIP conference server which properly implements >> WebRTC. I initiate a call to 5 users (running JS SIP app in their >> browsers). The initial INVITE has SSRC/MSID fields in the SDP >> identifying all the participants, am I right? > > > No, with No Plan there are no SSRCs and MSIDs in the SDP that comes from = the > browser. OK >> * Later, during the conference, I call to another 6th participant and >> enter him into the conference, so I need to send a re-INVITE to every >> participant with a modified version of the SDP (note that this is SIP >> protocol, so I need to use SIP messages to carry the new info about >> SSRC/MSID and so on). > > > That's the thing. You don't need that. In Jitsi we do exactly this operat= ion > with no Offer/Answer signalling. RTP carries enough information to proces= s > streams and we use upper layer signalling (4575) for things such as mappi= ng > SSRCs to users and announcing current participant list. That is much better than Plan A and Plan B. BTW: What would happen in NoPlan if the remote (i.e. a SIP gateway/endpoing) sends you a re-INVITE for "hold" purposes and you pass the SDP to your PC? or you should not pass the SDP to your PC? and if so, what about if the SDP contains updated ICE candidates due to remote peer network mobility? Thanks a lot for your response. -- I=F1aki Baz Castillo > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2E3F53TK5EX14MBXC273r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Bossiel thi= origuel : “I don't really understand the issue with the O/A model. SDP or not SDP you'l= l always offer something and answer something. I'm I missing?”

     <= /p>

    What you are missing is t= hat you *don’t* “always offer something and answer somet= hing. There is a completely different programming model where the server or program executing on the client is entirely in control of what happens.=

     <= /p>

    As an example, if I say &= #8220;draw a box that is 10 pixels wide and 10 pixels high” that̵= 7;s me telling the browser what to do. With offer/answer, I would say ̶= 0;I would like a box, what size boxes can you draw?” and the browser would res= pond with a list, and I would pick one of those.

     <= /p>

    RTCWEB is the *only* case where someone is seriously proposing an API that doesn’t allo= w the programmer to directly control the behavior of the browser.

     <= /p>

    Matthew Kaufman

     <= /p>

    From: rtcweb= -bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bossiel thioriguel
    Sent: Friday, June 21, 2013 2:40 AM
    To: diopmamadou@doubango.org
    Cc: rtcweb@ietf.org
    Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate t= o be re-opened

     

    Hello,

     =

    I'm registered on this g= roup since the beginning but this is my first post on this thread. So, I pr= esente myself: Mamadou DIOP and I'm working for Doubango Telecom where we'r= e building SIP endpoints, gateways, TelePresence/Telemedicine systems... all focused on SIP/IMS/LTE/RCS-e and = open source.

     =

    What I'm talking about i= s not just feeling but something I've experienced.

     =

    Using the current WebRTC= we have managed to *easily* build almost all kind of applications: click-t= o-call, SIP/IMS clients, gateways to PSTN, MCUs, Telemedicine systems...and= haven't seen any major issue. It's true that it's not natural to "hack" a blob SDP to implement fea= tures like hold/resume, media update, early media ... but it works and ther= e are demo applications showing it. If there is something more beautiful we= just want to see it in action and test it.

     =

    Many participants here h= ave said that what they want is something close to CU-RTC-WEB. Don't really= know if they tried to build applications using it or not but in my case I = have.

    First on Windows 8 but h= aven't gone far as there is no documentation to get started. Then, OSX and&= nbsp;luckily there was a readme with two links for testing (only one w= ork). You need to open 3 pages (1 master, 2 slaves) and check "send audio" on both slaves to header sound. Many java= script files and no documentation. It's said on these blogs that interop wi= th SIP networks is easy but it's not my feeling ...I just want to see one := )

     =

    I don't really understan= d the issue with the O/A model. SDP or not SDP you'll always offer somethin= g and answer something. I'm I missing?

     =

    For the current WebRTC, = Google open sourced their engine, produced drafts, a working implementation= in chrome, a mailing-list to help developers, demo applications, docu= mentation... we just want to see the same from any company asking to rewrite everything.

     =

    I'm not saying the curre= nt WebRTC implementation is perfect but I have seen my 14 year old nep= hew developing an audio/video chat for his homework :)

     =

    Regards

     

    De : I=F1aki Baz Castillo <ibc@aliax.net>
    =C0 : Emil Ivov <emcho@ji= tsi.org>
    Cc : "rtcweb@ietf.org" <rtcweb@ietf.org>
    Envoy=E9 le : Vendredi 21 juin 2013 1h24
    Objet : Re: [rtcweb] Requesting "SDP or not SDP" deba= te to be re-opened


    2013/6/21 Emil Ivov <emcho@jitsi.org<= /a>>:
    >
    > On 20.06.13, 23:49, I=F1aki Baz Castillo wrote:
    >>
    >> In JsSIP we are getting frustrated trying to implement the "h= old" /
    >> "unhold" feature because it requires SDP parsing and man= gling. Sending
    >> a re-INVITE with a modified SDP (now with a video track enabled) s= eems
    >> to work (after lot of pain) but we still miss a reliable API to kn= ow
    >> what the new SDP means. Instead we need to parse the SDP to detect=
    >> global (or per m=3D) line attributes like "a=3Dinactive"= or "a=3Dsendonly"
    >> etc etc. It's really painful.
    >
    >
    > I am having a problem following what you are trying to achieve here. I= n
    > JsSIP you seem to be going for a full SIP implementation in the browse= r. If
    > this is true and if this WG decides to remove SDP from the API surface= , then
    > you would need to completely parse SDP in the JS and then convert it i= nto
    > API calls. Similarly, when creating offers and answers you would need = to
    > construct SDP all by yourself.

    And we will do it very happily because then we will know what
    *exactly* we are sending on-the-wire.




    > So I am not sure why the SDP parsing in the current situation is so mu= ch of
    > a blocker for your use case.

    Because regardless I am a SIP-guy, I understand that the main mission
    of WebRTC is to provide realtime communications *for* the WWW, and not
    to enable a new interface for like-telephony-bussines.

    Today I'm doing SIP. Tomorrow I may be doing
    [[put_here_a_future_RTC_protocol_not_based_on_SDP]] and then I don't
    want to be constrained by decisions made today that force any future
    RTC protocol to deal with SDP O/A model.

    :)



    >> BTW I don't know wheter you support PlanA, PlanB or NoPlan, but I = did
    >> a question (in this case about NoPlan) for which I got no response= ,
    >> and honestly I would like to see it replied regardless the solutio= n
    >> uses PlanA, PlanB or NoPlan model:
    >>
    >>     http://www.ietf.org/mail-archive/web/rtcweb/current/msg07871.html
    >>
    > The other option would be indeed to do the same thing in JS. I believe= this
    > is JsSIP's use case. In that case however, regardless of whether you c= hoose
    > Plan A, Plan B, No Plan or CU-RTC-Web, you will inevitably be exposed = to a
    > fair amount of complexity, parsing and JS magic.
    >
    > You are, after all, building a SIP stack.

    Yes, but JsSIP creates its own SIP messages to be sent in the wire, so
    we have full control over *what* we create and send. Those SIP
    messages are not provided by the WebRTC API. But for the SDP
    component, JsSIP retreives a SDP blob string from the PC.







    >
    > In the above mail you also say:
    >
    >> Another example:
    >>
    >> * I am a powerful SIP conference server which properly implements<= br> >> WebRTC. I initiate a call to 5 users (running JS SIP app in their<= br> >> browsers). The initial INVITE has SSRC/MSID fields in the SDP
    >> identifying all the participants, am I right?
    >
    >
    > No, with No Plan there are no SSRCs and MSIDs in the SDP that comes fr= om the
    > browser.

    OK


    >> * Later, during the conference, I call to another 6th participant = and
    >> enter him into the conference, so I need to send a re-INVITE to ev= ery
    >> participant with a modified version of the SDP (note that this is = SIP
    >> protocol, so I need to use SIP messages to carry the new info abou= t
    >> SSRC/MSID and so on).
    >
    >
    > That's the thing. You don't need that. In Jitsi we do exactly this ope= ration
    > with no Offer/Answer signalling. RTP carries enough information to pro= cess
    > streams and we use upper layer signalling (4575) for things such as ma= pping
    > SSRCs to users and announcing current participant list.

    That is much better than Plan A and Plan B.



    BTW: What would happen in NoPlan if the remote (i.e. a SIP
    gateway/endpoing) sends you a re-INVITE for "hold" purposes and y= ou
    pass the SDP to your PC? or you should not pass the SDP to your PC?
    and if so, what about if the SDP contains updated ICE candidates due
    to remote peer network mobility?



    Thanks a lot for your response.

    --
    I=F1aki Baz Castillo
    <ibc@aliax.net>
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    = https://www.ietf.org/mailman/listinfo/rtcweb

     

    --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2E3F53TK5EX14MBXC273r_-- From silviapfeiffer1@gmail.com Fri Jun 21 16:40:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B304221F9E99 for ; Fri, 21 Jun 2013 16:40:38 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iso4GD-tEuge for ; Fri, 21 Jun 2013 16:40:37 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 023BE21F9ED4 for ; Fri, 21 Jun 2013 16:40:36 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i7so10051082oag.16 for ; Fri, 21 Jun 2013 16:40: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=HbCspx7cOmed6hCUcqv/sLCUwS2GhUTWAKmBs9/Jnkw=; b=yTi38MEA/27/kVJy6Zma4o2Z7XDFgIo7KDfx0fOEoCleu/5/44S7iMRUqSfUsG63VO 1dtVpOmXgZKu9s7nO/oE/4f6qlcjlNF+qqK+rGUIWsJ4q/Vgxyjp6kyMLj7oBmW7Uk/z kJNmISiOIC4iwRcihByGG+gyojxXdVIMNh+moTMrpKhNJR9LbZJrJYs7ebyyYZ+B5jW9 sYLIngijMBAErgbOrL3cIce4052i8npTA2U6pb9PQWRiWxY+jMdq2gzX6CG8FoQvYrud z0wisbuk6JgIT3rUhFsHZPCFr6PPaSzn4PT2YFmSLK2eCShfHznQfrg8dM1NOPQwsbx6 hwwQ== MIME-Version: 1.0 X-Received: by 10.182.72.170 with SMTP id e10mr4454295obv.62.1371858036217; Fri, 21 Jun 2013 16:40:36 -0700 (PDT) Received: by 10.76.116.71 with HTTP; Fri, 21 Jun 2013 16:40:35 -0700 (PDT) Received: by 10.76.116.71 with HTTP; Fri, 21 Jun 2013 16:40:35 -0700 (PDT) In-Reply-To: <1371826199.49975.YahooMailNeo@web171304.mail.ir2.yahoo.com> References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> <1371826199.49975.YahooMailNeo@web171304.mail.ir2.yahoo.com> Date: Sat, 22 Jun 2013 09:40:35 +1000 Message-ID: From: Silvia Pfeiffer To: Bossiel thioriguel Content-Type: multipart/alternative; boundary=001a11c2f3d8ee60f204dfb296b8 Cc: diopmamadou@doubango.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 23:40:38 -0000 --001a11c2f3d8ee60f204dfb296b8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Did you develop a SDP manipulation library that you could share/point us to= ? Silvia. On 22 Jun 2013 00:50, "Bossiel thioriguel" wrote: > @Peter > Both audio and video. > Yes we're doing all you're listing here and even more. > > ------------------------------ > *De :* Peter Thatcher > *=C0 :* Bossiel thioriguel > *Cc :* diopmamadou@doubango.org; rtcweb@ietf.org > *Envoy=E9 le :* Vendredi 21 juin 2013 16h42 > *Objet :* Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened > > Do you work with video or just audio? > Do you work with multiple streams/tracks, both send and receive? > Do you use features such as rtx, fec, and simulcast? > Simple, single-track, audio-only clients that use SDP for signalling over > the wire are fairly well served by the current API, as are clients only > using the data channel. But doing more advanced things, such as those I > mention, require significant SDP munging which can be a very slow and > error-prone experience. > Your experience may differ from others because they are trying to do > things that require a lot more SDP munging, which can be quite painful. > On Jun 21, 2013 2:40 AM, "Bossiel thioriguel" wrote: > > Hello, > > I'm registered on this group since the beginning but this is my first pos= t > on this thread. So, I presente myself: Mamadou DIOP and I'm working for > Doubango Telecom where we're building SIP endpoints, gateways, > TelePresence/Telemedicine systems... all focused on SIP/IMS/LTE/RCS-e and > open source. > > What I'm talking about is not just feeling but something I've experienced= . > > Using the current WebRTC we have managed to *easily* build almost all kin= d > of applications: click-to-call, SIP/IMS clients, gateways to PSTN, MCUs, > Telemedicine systems...and haven't seen any major issue. It's true that > it's not natural to "hack" a blob SDP to implement features like > hold/resume, media update, early media ... but it works and there are dem= o > applications showing it. If there is something more beautiful we just wan= t > to see it in action and test it. > > Many participants here have said that what they want is something close t= o > CU-RTC-WEB. Don't really know if they tried to build applications using i= t > or not but in my case I have. > My reference: > http://html5labs.interoperabilitybridges.com/prototypes/cu-rtc-web-roamin= g/cu-rtc-web-roaming/info > First on Windows 8 but haven't gone far as there is no documentation to > get started. Then, OSX and luckily there was a readme with two links for > testing (only one work). You need to open 3 pages (1 master, 2 slaves) an= d > check "send audio" on both slaves to header sound. Many javascript files > and no documentation. It's said on these blogs that interop with SIP > networks is easy but it's not my feeling ...I just want to see one :) > > I don't really understand the issue with the O/A model. SDP or not SDP > you'll always offer something and answer something. I'm I missing? > > For the current WebRTC, Google open sourced their engine, produced drafts= , > a working implementation in chrome, a mailing-list to help developers, de= mo > applications, documentation... we just want to see the same from any > company asking to rewrite everything. > > I'm not saying the current WebRTC implementation is perfect but I have > seen my 14 year old nephew developing an audio/video chat for his homewor= k > :) > > Regards > > ------------------------------ > *De :* I=F1aki Baz Castillo > *=C0 :* Emil Ivov > *Cc :* "rtcweb@ietf.org" > *Envoy=E9 le :* Vendredi 21 juin 2013 1h24 > *Objet :* Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened > > 2013/6/21 Emil Ivov : > > > > On 20.06.13, 23:49, I=F1aki Baz Castillo wrote: > >> > >> In JsSIP we are getting frustrated trying to implement the "hold" / > >> "unhold" feature because it requires SDP parsing and mangling. Sending > >> a re-INVITE with a modified SDP (now with a video track enabled) seems > >> to work (after lot of pain) but we still miss a reliable API to know > >> what the new SDP means. Instead we need to parse the SDP to detect > >> global (or per m=3D) line attributes like "a=3Dinactive" or "a=3Dsendo= nly" > >> etc etc. It's really painful. > > > > > > I am having a problem following what you are trying to achieve here. In > > JsSIP you seem to be going for a full SIP implementation in the browser= . > If > > this is true and if this WG decides to remove SDP from the API surface, > then > > you would need to completely parse SDP in the JS and then convert it in= to > > API calls. Similarly, when creating offers and answers you would need t= o > > construct SDP all by yourself. > > And we will do it very happily because then we will know what > *exactly* we are sending on-the-wire. > > > > > > So I am not sure why the SDP parsing in the current situation is so muc= h > of > > a blocker for your use case. > > Because regardless I am a SIP-guy, I understand that the main mission > of WebRTC is to provide realtime communications *for* the WWW, and not > to enable a new interface for like-telephony-bussines. > > Today I'm doing SIP. Tomorrow I may be doing > [[put_here_a_future_RTC_protocol_not_based_on_SDP]] and then I don't > want to be constrained by decisions made today that force any future > RTC protocol to deal with SDP O/A model. > > :) > > > > >> BTW I don't know wheter you support PlanA, PlanB or NoPlan, but I did > >> a question (in this case about NoPlan) for which I got no response, > >> and honestly I would like to see it replied regardless the solution > >> uses PlanA, PlanB or NoPlan model: > >> > >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07871.html > >> > > The other option would be indeed to do the same thing in JS. I believe > this > > is JsSIP's use case. In that case however, regardless of whether you > choose > > Plan A, Plan B, No Plan or CU-RTC-Web, you will inevitably be exposed t= o > a > > fair amount of complexity, parsing and JS magic. > > > > You are, after all, building a SIP stack. > > Yes, but JsSIP creates its own SIP messages to be sent in the wire, so > we have full control over *what* we create and send. Those SIP > messages are not provided by the WebRTC API. But for the SDP > component, JsSIP retreives a SDP blob string from the PC. > > > > > > > > > > > In the above mail you also say: > > > >> Another example: > >> > >> * I am a powerful SIP conference server which properly implements > >> WebRTC. I initiate a call to 5 users (running JS SIP app in their > >> browsers). The initial INVITE has SSRC/MSID fields in the SDP > >> identifying all the participants, am I right? > > > > > > No, with No Plan there are no SSRCs and MSIDs in the SDP that comes fro= m > the > > browser. > > OK > > > >> * Later, during the conference, I call to another 6th participant and > >> enter him into the conference, so I need to send a re-INVITE to every > >> participant with a modified version of the SDP (note that this is SIP > >> protocol, so I need to use SIP messages to carry the new info about > >> SSRC/MSID and so on). > > > > > > That's the thing. You don't need that. In Jitsi we do exactly this > operation > > with no Offer/Answer signalling. RTP carries enough information to > process > > streams and we use upper layer signalling (4575) for things such as > mapping > > SSRCs to users and announcing current participant list. > > That is much better than Plan A and Plan B. > > > > BTW: What would happen in NoPlan if the remote (i.e. a SIP > gateway/endpoing) sends you a re-INVITE for "hold" purposes and you > pass the SDP to your PC? or you should not pass the SDP to your PC? > and if so, what about if the SDP contains updated ICE candidates due > to remote peer network mobility? > > > > Thanks a lot for your response. > > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c2f3d8ee60f204dfb296b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    Did you develop a SDP manipulation library that you could sh= are/point us to?
    Silvia.

    On 22 Jun 2013 00:50, "Bossiel thioriguel&q= uot; <bossiel@yahoo.fr> wrote= :
    @Peter
    Both audio and video.
    Yes we're doing all you're listing here and even more.
    De=A0: Peter Thatcher <pthatcher@google.com>
    = =C0=A0: Bossiel thioriguel <= bossiel@yahoo.fr&= gt;
    Cc=A0: diopmamadou@doubango.org; rtcweb@ietf.org
    Envoy=E9 le : Vendredi 21 j= uin 2013 16h42
    Objet=A0:= Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened<= br>

    Do you work with video or ju= st audio?
    Do you work with multiple streams/tracks, both send and re= ceive?
    Do you use features such as rtx, fec, and simulcast?
    Simple, single-track, audio-only clients that use SDP for = signalling over the wire are fairly well served by the current API, as are = clients only using the data channel.=A0 But doing more advanced things, suc= h as those I mention, require significant SDP munging which can be a very s= low and error-prone experience.=A0
    Your experience may differ from others because they are tr= ying to do things that require a lot more SDP munging, which can be quite p= ainful.
    On Jun 21, 2013 2:40 AM, "Bossiel thioriguel" <bossiel@yahoo.= fr> wrote:
    Hello,

    I'm registered on this group since the b= eginning but this is my first post on this thread. So, I presente myself: M= amadou DIOP and I'm working for Doubango Telecom where we're buildi= ng SIP endpoints, gateways, TelePresence/Telemedicine systems... all focuse= d on SIP/IMS/LTE/RCS-e and open source.

    What I'm talking about is not just feeling but something I've= experienced.

    Using the current WebRTC we have managed to = *easily* build almost all kind of applications: click-to-call, SIP/IMS clie= nts, gateways to PSTN, MCUs, Telemedicine systems...and haven't seen an= y major issue. It's true that it's not natural to "hack" = a blob SDP to implement features like hold/resume, media update, early media= ... but it works and there are demo applications showing it. If there is s= omething more beautiful we just want to see it in action and test it.

    Many participants here have said that what they want is something clo= se to CU-RTC-WEB. Don't really know if they tried to build applications= using it or not but in my case I have.
    First on Windows 8 but ha= ven't gone far as there is no documentation to get started. Then, OSX a= nd=A0luckily=A0there was a readme with two links for testing (only one work= ). You need to open 3 pages (1 master, 2 slaves) and check "send audio= " on both slaves to header sound. Many javascript files and no documen= tation. It's said on these blogs that interop with SIP networks is easy= but it's not my feeling ...I just want to see one :)

    I don't really understand the issue with the O/A model. SDP or no= t SDP you'll always offer something and answer something. I'm I mis= sing?

    Fo= r the current WebRTC, Google open sourced their engine, produced drafts, a = working implementation in chrome, a=A0mailing-list to help developers, demo= applications, documentation... we just want to see the same from any compa= ny asking to rewrite everything.

    I'm not saying the current WebRTC i= mplementation is perfect but I have seen my 14 year old=A0nephew developing= an audio/video chat for his homework :)

    Regards

    De=A0: I=F1aki= Baz Castillo <ibc@aliax.net>
    =C0=A0: Emil Ivov <emcho@jits= i.org>
    Cc=A0: &qu= ot;rt= cweb@ietf.org" <rtcweb@ietf.org>
    Envoy=E9 le : Vendredi 21 j= uin 2013 1h24
    Objet=A0: = Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

    2013/6/21 Emil Ivov <emcho@jitsi.org>:
    >
    > On 20= .06.13, 23:49, I=F1aki Baz Castillo wrote:
    >>
    >> In JsSIP= we are getting frustrated trying to implement the "hold" /
    >> "unhold" feature because it requires SDP parsing and man= gling. Sending
    >> a re-INVITE with a modified SDP (now with a video track enabled) seems
    >> to work (after lot of pain) but we = still miss a reliable API to know
    >> what the new SDP means. Inste= ad we need to parse the SDP to detect
    >> global (or per m=3D) line= attributes like "a=3Dinactive" or "a=3Dsendonly"
    >> etc etc. It's really painful.
    >
    >
    > I am hav= ing a problem following what you are trying to achieve here. In
    > JsS= IP you seem to be going for a full SIP implementation in the browser. If > this is true and if this WG decides to remove SDP from the API surface= , then
    > you would need to completely parse SDP in the JS and then co= nvert it into
    > API calls. Similarly, when creating offers and answer= s you would need to
    > construct SDP all by yourself.

    And we will do it very happily b= ecause then we will know what
    *exactly* we are sending on-the-wire.
    <= br>


    > So I am not sure why the SDP parsing in the current situation is so much of
    > a blocker for your use case.

    Becaus= e regardless I am a SIP-guy, I understand that the main mission
    of WebRT= C is to provide realtime communications *for* the WWW, and not
    to enable= a new interface for like-telephony-bussines.

    Today I'm doing SIP. Tomorrow I may be doing
    [[put_here_a_future= _RTC_protocol_not_based_on_SDP]] and then I don't
    want to be constra= ined by decisions made today that force any future
    RTC protocol to deal = with SDP O/A model.

    :)



    >> BTW I don't know wheter you support Plan= A, PlanB or NoPlan, but I did
    >> a question (in this case about No= Plan) for which I got no response,
    >> and honestly I would like to= see it replied regardless the solution
    >> uses PlanA, PlanB or NoPlan model:
    >>
    >> http://www.ietf.org/mail-archive/web/rtcweb= /current/msg07871.html
    >>
    > The other option would be indeed to do the same thing in J= S. I believe this
    > is JsSIP's use case. In that case however, re= gardless of whether you choose
    > Plan A, Plan B, No Plan or CU-RTC-We= b, you will inevitably be exposed to a
    > fair amount of complexity, parsing and JS magic.
    >
    > You a= re, after all, building a SIP stack.

    Yes, but JsSIP creates its own = SIP messages to be sent in the wire, so
    we have full control over *what*= we create and send. Those SIP
    messages are not provided by the WebRTC API. But for the SDP
    component, = JsSIP retreives a SDP blob string from the PC.






    <= br>>
    > In the above mail you also say:
    >
    >> Another= example:
    >>
    >> * I am a powerful SIP conference server which properly= implements
    >> WebRTC. I initiate a call to 5 users (running JS SIP app in their
    >> browsers). The = initial INVITE has SSRC/MSID fields in the SDP
    >> identifying all = the participants, am I right?
    >
    >
    > No, with No Plan ther= e are no SSRCs and MSIDs in the SDP that comes from the
    > browser.

    OK


    >> * Later, during the conference,= I call to another 6th participant and
    >> enter him into the confe= rence, so I need to send a re-INVITE to every
    >> participant with = a modified version of the SDP (note that this is SIP
    >> protocol, so I need to use SIP messages to carry the new info abou= t
    >> SSRC/MSID and so on).
    >
    >
    > That's the = thing. You don't need that. In Jitsi we do exactly this operation
    > with no Offer/Answer signalling. RTP carries enough information to pro= cess
    > streams and we use upper layer signalling (4575) for things su= ch as mapping
    > SSRCs to users and announcing current participant list.

    That is much better than P= lan A and Plan B.



    BTW: What would happen in NoPlan if the re= mote (i.e. a SIP
    gateway/endpoing) sends you a re-INVITE for "hold&= quot; purposes and you
    pass the SDP to your PC? or you should not pass the SDP to your PC?
    and = if so, what about if the SDP contains updated ICE candidates due
    to remo= te peer network mobility?



    Thanks a lot for your response.
    --
    I=F1aki Baz Castillo
    <ibc@aliax.net>
    ___________________= ____________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb


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




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

    --001a11c2f3d8ee60f204dfb296b8-- From bossiel@yahoo.fr Fri Jun 21 16:47:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81B421F9E37 for ; Fri, 21 Jun 2013 16:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kKQ34sFn0+v for ; Fri, 21 Jun 2013 16:47:04 -0700 (PDT) Received: from nm7-vm1.bullet.mail.ird.yahoo.com (nm7-vm1.bullet.mail.ird.yahoo.com [77.238.189.223]) by ietfa.amsl.com (Postfix) with SMTP id 61A5921F9D87 for ; Fri, 21 Jun 2013 16:46:58 -0700 (PDT) Received: from [77.238.189.227] by nm7.bullet.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 23:46:57 -0000 Received: from [212.82.98.121] by tm16.bullet.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 23:46:57 -0000 Received: from [127.0.0.1] by omp1058.mail.ir2.yahoo.com with NNFMP; 21 Jun 2013 23:46:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 171377.58710.bm@omp1058.mail.ir2.yahoo.com Received: (qmail 31014 invoked by uid 60001); 21 Jun 2013 23:46:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1371858416; bh=5SRgAb0hwgsFZFYPnq46SwitmEtCLDeV2ZMmqZcxBw8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GMfIPbRvpw7CwPTmdq7YFmZ+bhDoPC9q7Pymd6b5gmB/xoI8pnu96rxRSDwpaxC+9mT8cHsr+t0rqWfbEzENN1cORCnRpT356nUNzyUko4TxhwOst+8dquXAdVjv0sc4eWY96qkbhVG7S6GtD1Xo7DMG2matyhbTLv7hsFQ2dYo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ReeBZ9aGYj0lEQYBmBvUbdoOkZ773mrPV2+PsQKtesWEn/Xc00l/NTxbqyLbO7P1ofj35iDF6rvKYhqGUnSQGRRICqJqBoYwmXRkg5mkZfP27DpvbakFNsf829Yd8XEkl7d8MuD/OE9rCXo59JVTqijVA7M+lxHxdwevCElDpNw=; X-YMail-OSG: go9Tri8VM1ndQ4qxuNWwMv3q.2nj5yA2SpyHEL8ytdwBBMn SvadsjAF0yt3gn.bq9Y8OSIc52Qwa0DzyevRfj5ewNkZjqeKGcfn1lPjbl8k 84PqmHC0Gjfne9BG5G1yueM0QwVJD5ec5TOTtpe8kYD.I5WEeVyyQ.6R1urx Be87CPSAtFIY3vkaqjN3dByHAlh1fDPO1skdLQAsu3ChtMfzEBH1Jh0WdJGj Ob3Gft6qaJOBGV14SplOA6mkh9pyfQVAV4CdysZZh0YsWY2uG98Ed_Vu2aUo upcu52c7rFvLjpkvM7E_RWFgKdQKQhzRBHJtSvgi2RV2OhgzvOTTeTQbqd3I 9EaDGy4Rfccy.s99_Gk28VVnHgmM094E7gmeB05GTMhYDwLcNhySRQRcLbFr In.sypyPMmt0BFWnwGgtwSmqO0uSoJnQAdJ0QHCudHuTy2t99P16navAhnq7 AMRSbP_wvNPPVhg52_Eihsl5p6gldIf4C31Rnt8AWqkH.pNmRMEnCy5UIgGE 62UjNe8rT3.KKEFU33p78sp9wYXHPA0kegGebcCOe1QQUMC60_e9difcBp6b gEkAD5_Sj8U_nmfyEwTgAJQ0U4RItXsoCK5QnofyLzv._d3Cf9UM4j0m2vBm enZapofGb8iBmR3bHgWaEC09AZipCw8Jkrx0ugUadpb18PDrbi7WxTWw3gai sMLG_OO8CjN0vAQmeTN3IcQZtpqfI3ZMYejK88PIWGEKn7ZflIvNWEQ49C6I wLIORee3AoCw5leXuHaPLHubzlNaJPuoZqf1ZRQMbe4ZmYPNmNlbeblbVEox .kjA- Received: from [88.179.39.5] by web171303.mail.ir2.yahoo.com via HTTP; Sat, 22 Jun 2013 00:46:56 BST X-Rocket-MIMEInfo: 002.001, WWVzCmh0dHBzOi8vY29kZS5nb29nbGUuY29tL3Avc2lwbWw1L3NvdXJjZS9icm93c2UvI3N2biUyRnRydW5rJTJGc3JjJTJGdGlueVNEUCUyRnNyYwoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRGXCoDogU2lsdmlhIFBmZWlmZmVyIDxzaWx2aWFwZmVpZmZlcjFAZ21haWwuY29tPgrDgMKgOiBCb3NzaWVsIHRoaW9yaWd1ZWwgPGJvc3NpZWxAeWFob28uZnI.IApDY8KgOiBkaW9wbWFtYWRvdUBkb3ViYW5nby5vcmc7IFBldGVyIFRoYXRjaGVyIDxwdGhhdGNoZXJAZ29vZ2xlLmNvbT47ICIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.554 References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> <1371826199.49975.YahooMailNeo@web171304.mail.ir2.yahoo.com> Message-ID: <1371858416.26047.YahooMailNeo@web171303.mail.ir2.yahoo.com> Date: Sat, 22 Jun 2013 00:46:56 +0100 (BST) From: Bossiel thioriguel To: Silvia Pfeiffer In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1953309981-804715514-1371858416=:26047" Cc: "diopmamadou@doubango.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bossiel thioriguel List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 23:47:09 -0000 ---1953309981-804715514-1371858416=:26047 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yes=0Ahttps://code.google.com/p/sipml5/source/browse/#svn%2Ftrunk%2Fsrc%2Ft= inySDP%2Fsrc=0A=0A=0A=0A________________________________=0A De=A0: Silvia P= feiffer =0A=C0=A0: Bossiel thioriguel =0ACc=A0: diopmamadou@doubango.org; Peter Thatcher ; "rtcweb@ietf.org" =0AEnvoy=E9 le : Samedi 22 jui= n 2013 1h40=0AObjet=A0: Re: [rtcweb] Requesting "SDP or not SDP" debate to = be re-opened=0A =0A=0A=0ADid you develop a SDP manipulation library that yo= u could share/point us to?=0ASilvia.=0A=0AOn 22 Jun 2013 00:50, "Bossiel th= ioriguel" wrote:=0A=0A@Peter=0A>Both audio and video.=0A= >Yes we're doing all you're listing here and even more.=0A>=0A>=0A>=0A>____= ____________________________=0A> De=A0: Peter Thatcher =0A>=C0=A0: Bossiel thioriguel =0A>Cc=A0: diopmamadou@= doubango.org; rtcweb@ietf.org =0A>Envoy=E9 le : Vendredi 21 juin 2013 16h42= =0A>Objet=A0: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-open= ed=0A> =0A>=0A>=0A>Do you work with video or just audio?=0A>Do you work wit= h multiple streams/tracks, both send and receive?=0A>Do you use features su= ch as rtx, fec, and simulcast?=0A>=0A>Simple, single-track, audio-only clie= nts that use SDP for signalling over the wire are fairly well served by the= current API, as are clients only using the data channel.=A0 But doing more= advanced things, such as those I mention, require significant SDP munging = which can be a very slow and error-prone experience.=A0 =0A>Your experience= may differ from others because they are trying to do things that require a= lot more SDP munging, which can be quite painful.=0A>On Jun 21, 2013 2:40 = AM, "Bossiel thioriguel" wrote:=0A>=0A>Hello,=0A>>=0A>>= =0A>>I'm registered on this group since the beginning but this is my first = post on this thread. So, I presente myself: Mamadou DIOP and I'm working fo= r Doubango Telecom where we're building SIP endpoints, gateways, TelePresen= ce/Telemedicine systems... all focused on SIP/IMS/LTE/RCS-e and open source= .=0A>>=0A>>=0A>>What I'm talking about is not just feeling but something I'= ve experienced.=0A>>=0A>>=0A>>Using the current WebRTC we have managed to *= easily* build almost all kind of applications: click-to-call, SIP/IMS clien= ts, gateways to PSTN, MCUs, Telemedicine systems...and haven't seen any maj= or issue. It's true that it's not natural to "hack" a blob SDP to implement= features like hold/resume, media update, early media ... but it works and = there are demo applications showing it. If there is something more beautifu= l we just want to see it in action and test it.=0A>>=0A>>=0A>>Many particip= ants here have said that what they want is something close to CU-RTC-WEB. D= on't really know if they tried to build applications using it or not but in= my case I have.=0A>>My reference:=A0http://html5labs.interoperabilitybridg= es.com/prototypes/cu-rtc-web-roaming/cu-rtc-web-roaming/info=0A>>First on W= indows 8 but haven't gone far as there is no documentation to get started. = Then, OSX and=A0luckily=A0there was a readme with two links for testing (on= ly one work). You need to open 3 pages (1 master, 2 slaves) and check "send= audio" on both slaves to header sound. Many javascript files and no docume= ntation. It's said on these blogs that interop with SIP networks is easy bu= t it's not my feeling ...I just want to see one :)=0A>>=0A>>=0A>>I don't re= ally understand the issue with the O/A model. SDP or not SDP you'll always = offer something and answer something. I'm I missing?=0A>>=0A>>=0A>>For the = current WebRTC, Google open sourced their engine, produced drafts, a workin= g implementation in chrome, a=A0mailing-list to help developers, demo appli= cations, documentation... we just want to see the same from any company ask= ing to rewrite everything.=0A>>=0A>>=0A>>I'm not saying the current WebRTC = implementation is perfect but I have seen my 14 year old=A0nephew developin= g an audio/video chat for his homework :)=0A>>=0A>>=0A>>Regards=0A>>=0A>>= =0A>>=0A>>________________________________=0A>> De=A0: I=F1aki Baz Castillo= =0A>>=C0=A0: Emil Ivov =0A>>Cc=A0: "rtcwe= b@ietf.org" =0A>>Envoy=E9 le : Vendredi 21 juin 2013 1h24= =0A>>Objet=A0: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-ope= ned=0A>> =0A>>=0A>>2013/6/21 Emil Ivov :=0A>>>=0A>>> On 20= .06.13, 23:49, I=F1aki Baz Castillo wrote:=0A>>>>=0A>>>> In JsSIP we are ge= tting frustrated trying to implement the "hold" /=0A>>>> "unhold" feature b= ecause it requires SDP parsing and mangling. Sending=0A>>>> a re-INVITE wit= h a modified SDP (now with a=0A video track enabled) seems=0A>>>> to work (= after lot of pain) but we still miss a reliable API to know=0A>>>> what the= new SDP means. Instead we need to parse the SDP to detect=0A>>>> global (o= r per m=3D) line attributes like "a=3Dinactive" or "a=3Dsendonly"=0A>>>> et= c etc. It's really painful.=0A>>>=0A>>>=0A>>> I am having a problem followi= ng what you are trying to achieve here. In=0A>>> JsSIP you seem to be going= for a full SIP implementation in the browser. If=0A>>> this is true and if= this WG decides to remove SDP from the API surface, then=0A>>> you would n= eed to completely parse SDP in the JS and then convert it into=0A>>> API ca= lls. Similarly, when creating offers and answers you would need to=0A>>> co= nstruct SDP all by yourself.=0A>>=0A>>And we will do it very happily becaus= e then we will know what=0A>>*exactly* we are sending on-the-wire.=0A>>=0A>= >=0A>>=0A>>=0A>>> So I am not sure why the SDP parsing in the current=0A si= tuation is so much of=0A>>> a blocker for your use case.=0A>>=0A>>Because r= egardless I am a SIP-guy, I understand that the main mission=0A>>of WebRTC = is to provide realtime communications *for* the WWW, and not=0A>>to enable = a new interface for like-telephony-bussines.=0A>>=0A>>Today I'm doing SIP. = Tomorrow I may be doing=0A>>[[put_here_a_future_RTC_protocol_not_based_on_S= DP]] and then I don't=0A>>want to be constrained by decisions made today th= at force any future=0A>>RTC protocol to deal with SDP O/A model.=0A>>=0A>>:= )=0A>>=0A>>=0A>>=0A>>>> BTW I don't know wheter you support PlanA, PlanB or= NoPlan, but I did=0A>>>> a question (in this case about NoPlan) for which = I got no response,=0A>>>> and honestly I would like to see it replied regar= dless the solution=0A>>>> uses PlanA, PlanB or NoPlan model:=0A>>>>=0A>>>> = http://www.ietf.org/mail-archive/web/rtcweb/current/msg07871.html=0A>>>>=0A= >>> The other option would be indeed to do the same thing in JS. I believe = this=0A>>> is JsSIP's use case. In that case however, regardless of whether= you choose=0A>>> Plan A, Plan B, No Plan or CU-RTC-Web, you will inevitabl= y be exposed to a=0A>>> fair amount of complexity, parsing and JS magic.=0A= >>>=0A>>> You are, after all, building a SIP stack.=0A>>=0A>>Yes, but JsSIP= creates its own SIP messages to be sent in the wire, so=0A>>we have full c= ontrol over *what* we create and send. Those SIP=0A>>messages are not provi= ded by the WebRTC API. But for the SDP=0A>>component, JsSIP retreives a SDP= blob string from the PC.=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>>=0A>>> In= the above mail you also say:=0A>>>=0A>>>> Another example:=0A>>>>=0A>>>> *= I am a powerful SIP conference server which properly implements=0A>>>> Web= RTC. I initiate=0A a call to 5 users (running JS SIP app in their=0A>>>> br= owsers). The initial INVITE has SSRC/MSID fields in the SDP=0A>>>> identify= ing all the participants, am I right?=0A>>>=0A>>>=0A>>> No, with No Plan th= ere are no SSRCs and MSIDs in the SDP that comes from the=0A>>> browser.=0A= >>=0A>>OK=0A>>=0A>>=0A>>>> * Later, during the conference, I call to anothe= r 6th participant and=0A>>>> enter him into the conference, so I need to se= nd a re-INVITE to every=0A>>>> participant with a modified version of the S= DP (note that this is SIP=0A>>>> protocol, so I need to use SIP messages to= carry the new info about=0A>>>> SSRC/MSID and so on).=0A>>>=0A>>>=0A>>> Th= at's the thing. You don't need that. In Jitsi we do exactly this operation= =0A>>> with no Offer/Answer signalling. RTP carries enough information to p= rocess=0A>>> streams and we use upper layer signalling (4575) for things su= ch as mapping=0A>>> SSRCs to users=0A and announcing current participant li= st.=0A>>=0A>>That is much better than Plan A and Plan B.=0A>>=0A>>=0A>>=0A>= >BTW: What would happen in NoPlan if the remote (i.e. a SIP=0A>>gateway/end= poing) sends you a re-INVITE for "hold" purposes and you=0A>>pass the SDP t= o your PC? or you should not pass the SDP to your PC?=0A>>and if so, what a= bout if the SDP contains updated ICE candidates due=0A>>to remote peer netw= ork mobility?=0A>>=0A>>=0A>>=0A>>Thanks a lot for your response.=0A>>=0A>>-= -=0A>>I=F1aki Baz Castillo=0A>>=0A>>________________________= _______________________=0A>>rtcweb mailing list=0A>>rtcweb@ietf.org=0A>>htt= ps://www.ietf.org/mailman/listinfo/rtcweb=0A>>=0A>>=0A>>=0A>>______________= _________________________________=0A>>rtcweb mailing list=0A>>rtcweb@ietf.o= rg=0A>>https://www.ietf.org/mailman/listinfo/rtcweb=0A>>=0A>>=0A>=0A>=0A>__= _____________________________________________=0A>rtcweb mailing list=0A>rtc= web@ietf.org=0A>https://www.ietf.org/mailman/listinfo/rtcweb=0A>=0A> ---1953309981-804715514-1371858416=:26047 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    = Yes
    https:/= /code.google.com/p/sipml5/source/browse/#svn%2Ftrunk%2Fsrc%2FtinySDP%2Fsrc<= br>

    =
    De : Silvia Pfeiffer <silv= iapfeiffer1@gmail.com>
    =C0&nbs= p;: Bossiel thioriguel <bossiel@yahoo.fr>
    Cc : diopmamadou@doubango.org; Peter Thatcher <p= thatcher@google.com>; "rtcweb@ietf.org" <rtcweb@ietf.org>
    = Envoy=E9 le : Samedi 22 juin = 2013 1h40
    Objet := Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

    Did you develop a SDP manipulation library that you could share= /point us to?
    =0ASilvia.
    =0A
    =0A
    On 22 Jun 2013 00:50, "Bossiel thioriguel" <bossiel@yahoo.fr> wrote:
    =0A
    @Peter
    Both audio an= d video.
    =0AYes we're doing all you're listing here and even more.<= /div>

    =0A
    <= span style=3D"font-weight:bold;">De : Peter Thatcher <pthatcher@google.com>
    <= span style=3D"font-weight:bold;">=C0 : Bossiel thioriguel &= lt;bossiel@yahoo.fr>
    =0ACc : diopmamadou@doubango.org; rtcweb@ietf.org
    =0A En= voy=E9 le : Vendredi 21 juin 2013 16h42
    Objet : Re: [rtcweb] Requesting "SDP or no= t SDP" debate to be re-opened
    =0A

    Do you work with video or just audio?
    =0A
    Do = you work with multiple streams/tracks, both send and receive?
    =0A
    Do you use features such as rtx, fec, and simulcast?
    = =0A
    Simple, single-track, audio-only clients that use SDP f= or signalling over the wire are fairly well served by the current API, as a= re clients only using the data channel.  But doing more advanced thing= s, such as those I mention, require significant SDP munging which can be a = very slow and error-prone experience. 
    =0A=0A=0A
    Your experience may differ from others because they are trying to do thing= s that require a lot more SDP munging, which can be quite painful.
    =0A=
    On Jun 21, 2013 2:40 AM, "Bossiel thioriguel" <bossiel@yahoo.fr> wrote:
    =0A=0A
    Hello,<= /div>
    =0A=0A
    I'm registered on this group = since the beginning but this is my first post on this thread. So, I present= e myself: Mamadou DIOP and I'm working for Doubango Telecom where we're bui= lding SIP endpoints, gateways, TelePresence/Telemedicine systems... all foc= used on SIP/IMS/LTE/RCS-e and open source.
    =0A=0A

    <= /span>
    =0AWhat I'm talking about is not just feeling but some= thing I've experienced.
    =0A
    U= sing the current WebRTC we have managed to *easily* build almost all kind o= f applications: click-to-call, SIP/IMS clients, gateways to PSTN, MCUs, Tel= emedicine systems...and haven't seen any major issue. It's true that it's n= ot natural to "hack" a=0A blob SDP to implement features like hold/resume, = media update, early media ... but it works and there are demo applications = showing it. If there is something more beautiful we just want to see it in = action and test it.
    =0A=0A

    =0AMany participants here have said that what they want is something close t= o CU-RTC-WEB. Don't really know if they tried to build applications using i= t or not but in my case I have.
    =0A=0A

    =0AI d= on't really understand the issue with the O/A model. SDP or not SDP you'll = always offer something and answer something. I'm I missing?
    = =0A=0A
    =0A=0A

    <= /span>
    I'm not saying the current WebRTC implementation is = perfect but I have seen my 14 year old nephew developing an audio/vide= o chat for his homework :)
    =0A=0A

    = =0ARegards

    =0A
    De : I=F1aki Baz Castillo <    ibc@aliax.net>
    =0A=0A = =C0 : Emil Ivov <emcho@jit= si.org>
    Cc : "rtcweb@ietf.org" <rtcweb@ietf.org>
    =0A=0A Envoy=E9 le : Vendredi 21 juin 2013 1h24
    Objet : Re: [rtcweb] Requesting= "SDP or not SDP" debate to be re-opened
    =0A=0A

    = 2013/6/21 Emil Ivov <emcho@jitsi.org&g= t;:
    >
    > On 20.06.13, 23:49, I=F1aki Baz Castillo wrote:
    >= >
    >> In JsSIP we are getting frustrated trying to implement the= "hold" /
    =0A=0A>> "unhold" feature because it requires SDP parsin= g and mangling. Sending
    >> a re-INVITE with a modified SDP (now wi= th a=0A video track enabled) seems
    >> to work (after lot of pain) = but we still miss a reliable API to know
    >> what the new SDP means= . Instead we need to parse the SDP to detect
    >> global (or per m= =3D) line attributes like "a=3Dinactive" or "a=3Dsendonly"
    =0A=0A>>= ; etc etc. It's really painful.
    >
    >
    > I am having a probl= em following what you are trying to achieve here. In
    > JsSIP you seem= to be going for a full SIP implementation in the browser. If
    =0A=0A>= this is true and if this WG decides to remove SDP from the API surface, th= en
    > you would need to completely parse SDP in the JS and then conver= t it into
    > API calls. Similarly, when creating offers and answers yo= u would need to
    =0A=0A> construct SDP all by yourself.

    And we = will do it very happily because then we will know what
    *exactly* we are = sending on-the-wire.




    > So I am not sure why the SDP p= arsing in the current=0A situation is so much of
    > a blocker for your= use case.

    Because regardless I am a SIP-guy, I understand that the = main mission
    of WebRTC is to provide realtime communications *for* the W= WW, and not
    to enable a new interface for like-telephony-bussines.
    = =0A=0A
    Today I'm doing SIP. Tomorrow I may be doing
    [[put_here_a_futu= re_RTC_protocol_not_based_on_SDP]] and then I don't
    want to be constrain= ed by decisions made today that force any future
    RTC protocol to deal wi= th SDP O/A model.
    =0A=0A
    :)



    >> BTW I don't know = wheter you support PlanA, PlanB or NoPlan, but I did
    >> a question= (in this case about NoPlan) for which I got no response,
    >> and h= onestly I would like to see it replied regardless the solution
    =0A=0A>= ;> uses PlanA, PlanB or NoPlan model:
    >>
    >> http://www.ietf.org/mail-archive/web/rtcweb/cur= rent/msg07871.html
    =0A=0A>>
    > The other option would be = indeed to do the same thing in JS. I believe this
    > is JsSIP's use ca= se. In that case however, regardless of whether you choose
    > Plan A, = Plan B, No Plan or CU-RTC-Web, you will inevitably be exposed to a
    =0A= =0A> fair amount of complexity, parsing and JS magic.
    >
    > Yo= u are, after all, building a SIP stack.

    Yes, but JsSIP creates its o= wn SIP messages to be sent in the wire, so
    we have full control over *wh= at* we create and send. Those SIP
    =0A=0Amessages are not provided by the= WebRTC API. But for the SDP
    component, JsSIP retreives a SDP blob strin= g from the PC.







    >
    > In the above mai= l you also say:
    >
    >> Another example:
    =0A=0A>>
    &= gt;> * I am a powerful SIP conference server which properly implements>> WebRTC. I initiate=0A a call to 5 users (running JS SIP app in t= heir
    >> browsers). The initial INVITE has SSRC/MSID fields in the = SDP
    >> identifying all the participants, am I right?
    >
    &g= t;
    > No, with No Plan there are no SSRCs and MSIDs in the SDP that co= mes from the
    =0A=0A> browser.

    OK


    >> * Later, = during the conference, I call to another 6th participant and
    >> en= ter him into the conference, so I need to send a re-INVITE to every
    >= > participant with a modified version of the SDP (note that this is SIP<= br>=0A=0A>> protocol, so I need to use SIP messages to carry the new = info about
    >> SSRC/MSID and so on).
    >
    >
    > That's= the thing. You don't need that. In Jitsi we do exactly this operation
    = =0A=0A> with no Offer/Answer signalling. RTP carries enough information = to process
    > streams and we use upper layer signalling (4575) for thi= ngs such as mapping
    > SSRCs to users=0A and announcing current partic= ipant list.

    That is much better than Plan A and Plan B.


    <= br>BTW: What would happen in NoPlan if the remote (i.e. a SIP
    gateway/en= dpoing) sends you a re-INVITE for "hold" purposes and you
    =0A=0Apass the= SDP to your PC? or you should not pass the SDP to your PC?
    and if so, w= hat about if the SDP contains updated ICE candidates due
    to remote peer = network mobility?



    Thanks a lot for your response.
    =0A=0A<= br>--
    I=F1aki Baz Castillo
    <ibc@aliax.ne= t>
    _______________________________________________
    rtcweb mail= ing list
    rtcweb@ietf.org
    =0A=0Ahttps://www.ietf.org/mailman/listinfo/rtcweb


    =

    _____________________________________= __________
    =0A=0Artcweb mailing list
    =0Artcweb@ietf.org
    =0Ahttps://www.ietf.org/mailman/= listinfo/rtcweb
    =0A



    _______________________________________________=0Artcweb mailing list
    =0Artcweb@ietf.or= g
    =0Ahttps://www.ietf.org/mailman/listinfo/rtcweb
    =0A
    =0A


    ---1953309981-804715514-1371858416=:26047-- From silviapfeiffer1@gmail.com Fri Jun 21 16:54:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D028821F9EE0 for ; Fri, 21 Jun 2013 16:54:30 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPnaJNitcCy7 for ; Fri, 21 Jun 2013 16:54:29 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id BEC5321F9E93 for ; Fri, 21 Jun 2013 16:54:29 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id 16so8908584obc.40 for ; Fri, 21 Jun 2013 16:54: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=lcQ0QzaL47Bl7DK94VysefkZViSi0X1r0AOXtNreAb0=; b=HhNJAYbgQjMuQkQCvUz2DOEUGebKBHnyRzGMYH2TxQuuv43AwwsBatf9Em17hCXXUw BAIF43P3Hh12p6NaeyJPeXWYabQaGgME2b0MdzHuxEyuhHDOtM76PRZqk2NuTQU/RKv3 CVuPo4Kf3VldZz0/HgEhgd0voGCpoZfgwkI8Dgj9loQ59/kmPKHr38gzPe8zjwhq7SBU aOTxktArl/LR89jyWLy5ZNjkMxXAPZszQAcDbuCc/50Q/mfRkiXNvRtG567kSWz0KrOh Xne9VIhGcfre7s3ABXBJ6FapePt1rgH3x4wel2iTsqnmC9UwmSx0z9Q91VcxbnjPoQ9w VFVw== MIME-Version: 1.0 X-Received: by 10.60.136.234 with SMTP id qd10mr7628053oeb.15.1371858869251; Fri, 21 Jun 2013 16:54:29 -0700 (PDT) Received: by 10.76.116.71 with HTTP; Fri, 21 Jun 2013 16:54:28 -0700 (PDT) Received: by 10.76.116.71 with HTTP; Fri, 21 Jun 2013 16:54:28 -0700 (PDT) In-Reply-To: <51C48F4A.9070707@hookflash.com> References: <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> <9F33F40F6F2CD847824537F3C4E37DDF115D4A59@MCHP04MSX.global-ad.net> <4337C1D6-5D1E-4316-A96B-E6FBA2E647E7@siemens-enterprise.com> <51C48F4A.9070707@hookflash.com> Date: Sat, 22 Jun 2013 09:54:28 +1000 Message-ID: From: Silvia Pfeiffer To: Robin Raymond Content-Type: multipart/related; boundary=047d7b33c98295790c04dfb2c8a8 Cc: diopmamadou@doubango.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 23:54:30 -0000 --047d7b33c98295790c04dfb2c8a8 Content-Type: multipart/alternative; boundary=047d7b33c98295790b04dfb2c8a7 --047d7b33c98295790b04dfb2c8a7 Content-Type: text/plain; charset=ISO-8859-1 Is it possible to continue using SDP but not do o/a ? While I am all for having an easy API to manipulate SDP for the common use cases (and this abstract away the mangling) I am not too fussed about the use of SDP itself. I wonder if the restricted negotiation that you propose will still need something like SDP to communicate the parameters of the negotiation. So we could leave the data structure intact, but have a different negotiation algorithm between browsers. We could even offer in the SDP a choice of which negotiation algo to use so as to make interfacing with the SIP works easier. I hope this makes sense. Cheers, Silvia. On 22 Jun 2013 03:37, "Robin Raymond" wrote: > > To me the issue is not easy of use but compatibility, as what is produced > should increase compatibility not decrease it. That's one of the major > drawbacks of SDP with offer/answer as I've described numerous times -- it > increases incompatibility rather than decreases it. > > I too want to see an API where people don't need to understand a complex > mechanism to be able to produce a suitable application. Unfortunately, the > current SDP approach all too often requires learning SDP by JavaScript > developers to perform normal edge case scenarios (e.g. putting media on/off > hold). That's simply not acceptable in my mind. > > That's why I will drafting up an alternative approach which can have a > reasonable non-SDP based API without offer/answer but I will provide a > JavaScript shim on top that will provide the current "simple" approach, > including being able perform offer/answer using SDP (as some people > prefer). This should more than adequately satisfy the charter's limited 1.0 > goals and responsibilities and give the non-SDP people a basis for moving > forward where they can feel comfortable will satisfy their needs as well. > > -Robin > > > > Hutton, Andrew > 21 June, 2013 12:52 PM > Now this is getting ridiculous. > > You do know that one of the goals is to build an API that web developers > without knowledge of IETF protocols can use to build apps. I was only using > this as an example where this has been achieved. > > I also think you know that there are many apps out there already which > are much more than high school projects. > > I believe we are simply making life difficult by trying to do too much > at once and we need to rethink what is really needed and deliver on what > we have said we we will deliver please read the charter. > > Andy > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b33c98295790b04dfb2c8a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    Is it possible to continue using SDP but not do o/a ?

    While I am all for having an easy API to manipulate SDP for = the common use cases (and this abstract away the mangling) I am not too fus= sed about the use of SDP itself.

    I wonder if the restricted negotiation that you propose will= still need something like SDP to communicate the parameters of the negotia= tion. So we could leave the data structure intact, but have a different neg= otiation algorithm between browsers. We could even offer in the SDP a choic= e of which negotiation algo to use so as to make interfacing with the SIP w= orks easier.

    I hope this makes sense.

    Cheers,
    Silvia.

    On 22 Jun 2013 03:37, "Robin Raymond" = <robin@hookflash.com> wrot= e:

    To me the issue is not easy of use but compatibility, as what is=20 produced should increase compatibility not decrease it. That's one of= =20 the major drawbacks of SDP with offer/answer as I've described numerous= =20 times -- it increases incompatibility rather than decreases it.

    I too want to see an API where people don't need to understand a comple= x mechanism to be able to produce a suitable application. Unfortunately,=20 the current SDP approach all too often requires learning SDP by=20 JavaScript developers to perform normal edge case scenarios (e.g.=20 putting media on/off hold). That's simply not acceptable in my mind.
    That's why I will drafting up an alternative approach which can have a= =20 reasonable non-SDP based API without offer/answer but I will provide a=20 JavaScript shim on top that will provide the current "simple" app= roach,=20 including being able perform offer/answer using SDP (as some people=20 prefer). This should more than adequately satisfy the charter's limited= =20 1.0 goals and responsibilities and give the non-SDP people a basis for=20 moving forward where they can feel comfortable will satisfy their needs=20 as well.

    -Robin



    =20 21 June, 2013=20 12:52 PM
    Now this is getting ridiculous.

    You do know that one of the goals is to build an API that web=20 developers without knowledge of IETF protocols can use to build apps. I=20 was only using this as an example where this has been achieved.

    I also think you know that there are many apps out there already=20 which are much more than high school projects.

    I believe we are simply making life difficult by trying to do too=20 much at once =A0and we need to rethink what is really needed and deliver=20 on what we have said we we will deliver please read the charter.

    Andy


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

    --047d7b33c98295790b04dfb2c8a7-- --047d7b33c98295790c04dfb2c8a8 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 2645a3fe801d59c9_0.0.1.1 /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQECAQEB AQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAARCAAZABkDAREA AhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUKBwAAAAAAAAACAQME BQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAAAAAAAAAAAAADAAEEAv/E ACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oADAMBAAIRAxEAPwDuEt+gW/UL et6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJVIl7eXLCaZIGwBl3TY8epPx2+jy2 ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJ Ew/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx+a69/JSf9alIlste0VzaNpeFrcT9KKymotyi aZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mRUfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRD nu5azS8miKqjOTVkKqS/psG37fo1Fbabeg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GA cpOwBeN+U8/IkGbsiS8b7ryogmbzhbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH 4hPOI0DkjZtaJtFxuVEbIUUiyeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJ nYn9dnAQWl722p4ot37yzqnlfp6FrqbwawG8/9k= --047d7b33c98295790c04dfb2c8a8-- From roman@telurix.com Fri Jun 21 17:08:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748CF21F9DBB for ; Fri, 21 Jun 2013 17:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8POHOzWHOu61 for ; Fri, 21 Jun 2013 17:08:06 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 85EAC21F9DC0 for ; Fri, 21 Jun 2013 17:08:05 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w56so6942259wes.11 for ; Fri, 21 Jun 2013 17:08:04 -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=ZzfrKMHmO/5fayQazuiasrgOJpnKrf1WnkgYRQNR1yA=; b=AD4JEE6Nn3zlj/+nne/VRfqCH7mzRO6AlBGk4joSUEyP5ihzzi3j80mNcb3URTyn1N 7HhKZsYM1/1gNprCbPnk9NK4NSapswqh5o1JkRzlb4dIX2aS567PGfKPNsP8j63EgK8X R+rhogqnnZu5LiZE8+/VPRjAoZmm9fBojjjHsFbmkv4IgjnUBpS88J/gR2YyAbryqSKu ksrKDDIaSlu7p94Mjm4bOef4JowwcQvgWtzf/wuvn9CgC0A0BJlKDDt9HPHx6odjVRJV vm2F8LgJU+/HmgNYUstxUHQztS7evNB8V/HBOnJPsNsPr+pgAtExxIaEZklZmNr+wmEY 6B+g== X-Received: by 10.194.2.79 with SMTP id 15mr10879525wjs.42.1371859684689; Fri, 21 Jun 2013 17:08:04 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [2a00:1450:400c:c05::22a]) by mx.google.com with ESMTPSA id b20sm841204wiw.4.2013.06.21.17.08.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 17:08:03 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so1184866wid.3 for ; Fri, 21 Jun 2013 17:08:02 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.85.6 with SMTP id d6mr306980wiz.47.1371859682743; Fri, 21 Jun 2013 17:08:02 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Fri, 21 Jun 2013 17:08:02 -0700 (PDT) In-Reply-To: References: <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> <9F33F40F6F2CD847824537F3C4E37DDF115D4A59@MCHP04MSX.global-ad.net> <4337C1D6-5D1E-4316-A96B-E6FBA2E647E7@siemens-enterprise.com> <51C48F4A.9070707@hookflash.com> Date: Fri, 21 Jun 2013 20:08:02 -0400 Message-ID: From: Roman Shpount To: Silvia Pfeiffer Content-Type: multipart/alternative; boundary=f46d0442808e125cd504dfb2f9c6 X-Gm-Message-State: ALoCoQmpJ6CxrJZd0EEI9JlKMwqrb+AGgfM5cmyN4r4rWXw7/GTEi61NYDe1ciPNXAbXS+d8rrig Cc: diopmamadou@doubango.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Jun 2013 00:08:06 -0000 --f46d0442808e125cd504dfb2f9c6 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 21, 2013 at 7:54 PM, Silvia Pfeiffer wrote: > Is it possible to continue using SDP but not do o/a ? > Neither SDP not O/A belongs in API. The issue with SDP is that it creates an API surface which is using a string blob. To make such API a standard you need to standardize the blob format. Also, every time you add features you need to update the SDP format and all the parsers that are dealing with it. Not sustainable long term. Finally, SDP mixes multiple unrelated data items together, ie it specifies transport parameters and media parameters at the same time. For a normal API flow you need to control those separately. O/A implies one model to negotiate media and transport parameters and forces them to be negotiated at the same time. One other thing to keep in mind that O/A compliant end points are not O/A internally. For instance you can change the sending codec or sending codec parameters (like bitrate) without going through offer/answer exchange. So, normally end points expose offer/answer to the network, but use a different API internally to control transport and media settings based on data received from O/A exchanges, user input, and other factors (like detecting high packet loss and reducing bandwidth or changing codec). _____________ Roman Shpount --f46d0442808e125cd504dfb2f9c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Fri, Jun 21, 2013 at 7:54 PM, Silvia Pfeiffer <= ;silviapfeif= fer1@gmail.com> wrote:

    Is it possible to continue using SDP but not do o/a ?


    Neither SDP not O/A belongs in API.

    The issue with SDP is that it creates an API surface which = is using a string blob. To make such API a standard you need to standardize= the blob format. Also, every time you add features you need to update the = SDP format and all the parsers that are dealing with it. Not sustainable lo= ng term. Finally, SDP mixes multiple unrelated data items together, ie it s= pecifies transport parameters and media parameters at the same time. For a = normal API flow you need to control those separately.

    O/A implies one model to negotiate media and transport = parameters and forces them to be negotiated at the same time. One other thi= ng to keep in mind that O/A compliant end points are not O/A internally. Fo= r instance you can change the sending codec or sending codec parameters (li= ke bitrate) without going through offer/answer exchange. So, normally end p= oints expose offer/answer to the network, but use a different API internall= y to control transport and media settings based on data received from O/A e= xchanges, user input, and other factors (like detecting high packet loss an= d reducing bandwidth or changing codec).
    _____________
    Roman Shpount

    =A0
    --f46d0442808e125cd504dfb2f9c6-- From roman@telurix.com Fri Jun 21 17:17:20 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B79121E804B for ; Fri, 21 Jun 2013 17:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.871 X-Spam-Level: X-Spam-Status: No, score=-2.871 tagged_above=-999 required=5 tests=[AWL=1.106, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEhDA3xrlNeK for ; Fri, 21 Jun 2013 17:17:18 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0A79811E80A2 for ; Fri, 21 Jun 2013 17:17:17 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so6841530wes.17 for ; Fri, 21 Jun 2013 17:17:16 -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=9PR+KxzMba3InqkqaVF7uUYI77dvA1r8Shn3knQvuPo=; b=D/7h6ndtOyPmXFi4+ePy9+cKRsF2IrPBX+9nnJtp/8iKEjrhuCo6cn1kmJ/X5daHmO 7kXsdN1sIOojT3zl0sAfJz3Tq2F1y83AtRvmcjDn+ARR2FrqbhQbX1iP4OlJpJcGzAYq ejAYegm+SanvdkozNfn3sB+JLtTLOR8F5Co5ZD7mexkocV3mOjROaC5MCQPsm1q0/5WD +lYalfrW4Fmi2B4UTTtQ/Lb1IuNzIAQspozwe4WmU3FAwQvZXZqiW4nbLMMQKOB4e9cQ CjKlJg9zE1rLa47PcOPE4cFmlExO/wUGGW6D1YgiJqrxg+TFp18b+IU7v5yK0ypWwyVS gh0g== X-Received: by 10.180.85.6 with SMTP id d6mr321691wiz.47.1371860236589; Fri, 21 Jun 2013 17:17:16 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [2a00:1450:400c:c03::22f]) by mx.google.com with ESMTPSA id cd11sm807577wib.10.2013.06.21.17.17.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 17:17:15 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t59so6697902wes.6 for ; Fri, 21 Jun 2013 17:17:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.119.228 with SMTP id kx4mr10546801wjb.33.1371860234691; Fri, 21 Jun 2013 17:17:14 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Fri, 21 Jun 2013 17:17:14 -0700 (PDT) In-Reply-To: <1371858416.26047.YahooMailNeo@web171303.mail.ir2.yahoo.com> References: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> <1371826199.49975.YahooMailNeo@web171304.mail.ir2.yahoo.com> <1371858416.26047.YahooMailNeo@web171303.mail.ir2.yahoo.com> Date: Fri, 21 Jun 2013 20:17:14 -0400 Message-ID: From: Roman Shpount To: Silvia Pfeiffer Content-Type: multipart/alternative; boundary=089e012292e2f86d4204dfb31969 X-Gm-Message-State: ALoCoQnCRptRKEFz/ECfpziRMLmMxH7ikx52C3N+gTaYlJqpP3AIrb8wbPjuGYoZmW0F3qVVpAor Cc: "diopmamadou@doubango.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Jun 2013 00:17:20 -0000 --089e012292e2f86d4204dfb31969 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just keep in mind that with this library, after you parse SDP, you will end up with a bunch of connection line attributes and format parameters. You will need to interpret those and figure out what they mean on your own. SDP is well defined format in the sense that you can parse it. Figuring out what this all means is a different story. For all you care, you can create a birthday party invitation and stuff it in SDP. Will make no sense to your WebRTC browser but will be well formed SDP none the less. _____________ Roman Shpount On Fri, Jun 21, 2013 at 7:46 PM, Bossiel thioriguel wrote= : > Yes > > https://code.google.com/p/sipml5/source/browse/#svn%2Ftrunk%2Fsrc%2FtinyS= DP%2Fsrc > > ------------------------------ > *De :* Silvia Pfeiffer > *=C0 :* Bossiel thioriguel > *Cc :* diopmamadou@doubango.org; Peter Thatcher ; " > rtcweb@ietf.org" > *Envoy=E9 le :* Samedi 22 juin 2013 1h40 > > *Objet :* Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened > > Did you develop a SDP manipulation library that you could share/point us > to? > Silvia. > On 22 Jun 2013 00:50, "Bossiel thioriguel" wrote: > > @Peter > Both audio and video. > Yes we're doing all you're listing here and even more. > > ------------------------------ > *De :* Peter Thatcher > *=C0 :* Bossiel thioriguel > *Cc :* diopmamadou@doubango.org; rtcweb@ietf.org > *Envoy=E9 le :* Vendredi 21 juin 2013 16h42 > *Objet :* Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened > > Do you work with video or just audio? > Do you work with multiple streams/tracks, both send and receive? > Do you use features such as rtx, fec, and simulcast? > Simple, single-track, audio-only clients that use SDP for signalling over > the wire are fairly well served by the current API, as are clients only > using the data channel. But doing more advanced things, such as those I > mention, require significant SDP munging which can be a very slow and > error-prone experience. > Your experience may differ from others because they are trying to do > things that require a lot more SDP munging, which can be quite painful. > On Jun 21, 2013 2:40 AM, "Bossiel thioriguel" wrote: > > Hello, > > I'm registered on this group since the beginning but this is my first pos= t > on this thread. So, I presente myself: Mamadou DIOP and I'm working for > Doubango Telecom where we're building SIP endpoints, gateways, > TelePresence/Telemedicine systems... all focused on SIP/IMS/LTE/RCS-e and > open source. > > What I'm talking about is not just feeling but something I've experienced= . > > Using the current WebRTC we have managed to *easily* build almost all kin= d > of applications: click-to-call, SIP/IMS clients, gateways to PSTN, MCUs, > Telemedicine systems...and haven't seen any major issue. It's true that > it's not natural to "hack" a blob SDP to implement features like > hold/resume, media update, early media ... but it works and there are dem= o > applications showing it. If there is something more beautiful we just wan= t > to see it in action and test it. > > Many participants here have said that what they want is something close t= o > CU-RTC-WEB. Don't really know if they tried to build applications using i= t > or not but in my case I have. > My reference: > http://html5labs.interoperabilitybridges.com/prototypes/cu-rtc-web-roamin= g/cu-rtc-web-roaming/info > First on Windows 8 but haven't gone far as there is no documentation to > get started. Then, OSX and luckily there was a readme with two links for > testing (only one work). You need to open 3 pages (1 master, 2 slaves) an= d > check "send audio" on both slaves to header sound. Many javascript files > and no documentation. It's said on these blogs that interop with SIP > networks is easy but it's not my feeling ...I just want to see one :) > > I don't really understand the issue with the O/A model. SDP or not SDP > you'll always offer something and answer something. I'm I missing? > > For the current WebRTC, Google open sourced their engine, produced drafts= , > a working implementation in chrome, a mailing-list to help developers, de= mo > applications, documentation... we just want to see the same from any > company asking to rewrite everything. > > I'm not saying the current WebRTC implementation is perfect but I have > seen my 14 year old nephew developing an audio/video chat for his homewor= k > :) > > Regards > > ------------------------------ > *De :* I=F1aki Baz Castillo > *=C0 :* Emil Ivov > *Cc :* "rtcweb@ietf.org" > *Envoy=E9 le :* Vendredi 21 juin 2013 1h24 > *Objet :* Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened > > 2013/6/21 Emil Ivov : > > > > On 20.06.13, 23:49, I=F1aki Baz Castillo wrote: > >> > >> In JsSIP we are getting frustrated trying to implement the "hold" / > >> "unhold" feature because it requires SDP parsing and mangling. Sending > >> a re-INVITE with a modified SDP (now with a video track enabled) seems > >> to work (after lot of pain) but we still miss a reliable API to know > >> what the new SDP means. Instead we need to parse the SDP to detect > >> global (or per m=3D) line attributes like "a=3Dinactive" or "a=3Dsendo= nly" > >> etc etc. It's really painful. > > > > > > I am having a problem following what you are trying to achieve here. In > > JsSIP you seem to be going for a full SIP implementation in the browser= . > If > > this is true and if this WG decides to remove SDP from the API surface, > then > > you would need to completely parse SDP in the JS and then convert it in= to > > API calls. Similarly, when creating offers and answers you would need t= o > > construct SDP all by yourself. > > And we will do it very happily because then we will know what > *exactly* we are sending on-the-wire. > > > > > > So I am not sure why the SDP parsing in the current situation is so muc= h > of > > a blocker for your use case. > > Because regardless I am a SIP-guy, I understand that the main mission > of WebRTC is to provide realtime communications *for* the WWW, and not > to enable a new interface for like-telephony-bussines. > > Today I'm doing SIP. Tomorrow I may be doing > [[put_here_a_future_RTC_protocol_not_based_on_SDP]] and then I don't > want to be constrained by decisions made today that force any future > RTC protocol to deal with SDP O/A model. > > :) > > > > >> BTW I don't know wheter you support PlanA, PlanB or NoPlan, but I did > >> a question (in this case about NoPlan) for which I got no response, > >> and honestly I would like to see it replied regardless the solution > >> uses PlanA, PlanB or NoPlan model: > >> > >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07871.html > >> > > The other option would be indeed to do the same thing in JS. I believe > this > > is JsSIP's use case. In that case however, regardless of whether you > choose > > Plan A, Plan B, No Plan or CU-RTC-Web, you will inevitably be exposed t= o > a > > fair amount of complexity, parsing and JS magic. > > > > You are, after all, building a SIP stack. > > Yes, but JsSIP creates its own SIP messages to be sent in the wire, so > we have full control over *what* we create and send. Those SIP > messages are not provided by the WebRTC API. But for the SDP > component, JsSIP retreives a SDP blob string from the PC. > > > > > > > > > > > In the above mail you also say: > > > >> Another example: > >> > >> * I am a powerful SIP conference server which properly implements > >> WebRTC. I initiate a call to 5 users (running JS SIP app in their > >> browsers). The initial INVITE has SSRC/MSID fields in the SDP > >> identifying all the participants, am I right? > > > > > > No, with No Plan there are no SSRCs and MSIDs in the SDP that comes fro= m > the > > browser. > > OK > > > >> * Later, during the conference, I call to another 6th participant and > >> enter him into the conference, so I need to send a re-INVITE to every > >> participant with a modified version of the SDP (note that this is SIP > >> protocol, so I need to use SIP messages to carry the new info about > >> SSRC/MSID and so on). > > > > > > That's the thing. You don't need that. In Jitsi we do exactly this > operation > > with no Offer/Answer signalling. RTP carries enough information to > process > > streams and we use upper layer signalling (4575) for things such as > mapping > > SSRCs to users and announcing current participant list. > > That is much better than Plan A and Plan B. > > > > BTW: What would happen in NoPlan if the remote (i.e. a SIP > gateway/endpoing) sends you a re-INVITE for "hold" purposes and you > pass the SDP to your PC? or you should not pass the SDP to your PC? > and if so, what about if the SDP contains updated ICE candidates due > to remote peer network mobility? > > > > Thanks a lot for your response. > > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > _______________________________________________ > 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 > > --089e012292e2f86d4204dfb31969 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just keep in mind that with this library, after you parse SDP, you will end= up with a bunch of connection line attributes and format parameters. You w= ill need to interpret those and figure out what they mean on your own.

    SDP is well defined format in the sense that you can parse i= t. Figuring out what this all means is a different story. For all you care,= you can create a birthday party invitation and stuff it in SDP. Will make = no sense to your WebRTC browser but will be well formed SDP none the less.<= br clear=3D"all">
    _____________
    Roman Shpount


    On Fri, Jun 21, 2013 at 7:46 PM, Bossiel= thioriguel <bossiel@yahoo.fr> wrote:
    Yes

    =
    De=A0: Silvia Pfeiffer <= silviapfeiff= er1@gmail.com>
    =C0=A0: Bossiel thioriguel <bossiel@yahoo.fr>
    Cc=A0: diopmamadou@doubango.org; Pete= r Thatcher <pt= hatcher@google.com>; "rtcweb@ietf.org" <rtcweb@ietf.org>
    Envoy=E9 le : Samedi 22 jui= n 2013 1h40

    Objet=A0: Re: [rtcweb] Requesting "SDP or not SDP&quo= t; debate to be re-opened

    Did you develop a SDP manipulation library that you could share/po= int us to?
    Silvia.
    On 22 Jun 2013 00:50, "Bossiel thioriguel" <bossiel@yahoo.fr<= /a>> wrote:
    @Peter
    Both audio and video.
    Yes we're doing all you're listing here and even more.
    De=A0: Peter Thatcher <    pthatcher@google.co= m>
    =C0=A0: Bossiel thioriguel = <= bossiel@yahoo.fr>
    Cc=A0: diopmamadou@douba= ngo.org; rtcweb@ietf.org
    Envoy=E9 le : Vendredi 21 j= uin 2013 16h42
    Objet=A0:= Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened<= br>

    Do you work with video or ju= st audio?
    Do you work with multiple streams/tracks, both send and re= ceive?
    Do you use features such as rtx, fec, and simulcast?
    Simple, single-track, audio-only clients that use SDP for = signalling over the wire are fairly well served by the current API, as are = clients only using the data channel.=A0 But doing more advanced things, suc= h as those I mention, require significant SDP munging which can be a very s= low and error-prone experience.=A0
    Your experience may differ from others because they are tr= ying to do things that require a lot more SDP munging, which can be quite p= ainful.
    On Jun 21, 2013 2:40 AM, "Bossiel thioriguel" <bossiel@yahoo.= fr> wrote:
    Hell= o,

    I'm registered on this group since the b= eginning but this is my first post on this thread. So, I presente myself: M= amadou DIOP and I'm working for Doubango Telecom where we're buildi= ng SIP endpoints, gateways, TelePresence/Telemedicine systems... all focuse= d on SIP/IMS/LTE/RCS-e and open source.

    What I'm talking about is not just feeling but something I've= experienced.

    Using the current WebRTC we have managed to = *easily* build almost all kind of applications: click-to-call, SIP/IMS clie= nts, gateways to PSTN, MCUs, Telemedicine systems...and haven't seen an= y major issue. It's true that it's not natural to "hack" = a blob SDP to implement features like hold/resume, media update, early media= ... but it works and there are demo applications showing it. If there is s= omething more beautiful we just want to see it in action and test it.

    Many participants here have said that what they want is something clo= se to CU-RTC-WEB. Don't really know if they tried to build applications= using it or not but in my case I have.
    First on Windows 8 but ha= ven't gone far as there is no documentation to get started. Then, OSX a= nd=A0luckily=A0there was a readme with two links for testing (only one work= ). You need to open 3 pages (1 master, 2 slaves) and check "send audio= " on both slaves to header sound. Many javascript files and no documen= tation. It's said on these blogs that interop with SIP networks is easy= but it's not my feeling ...I just want to see one :)

    I don't really understand the issue with the O/A model. SDP or no= t SDP you'll always offer something and answer something. I'm I mis= sing?

    Fo= r the current WebRTC, Google open sourced their engine, produced drafts, a = working implementation in chrome, a=A0mailing-list to help developers, demo= applications, documentation... we just want to see the same from any compa= ny asking to rewrite everything.

    I'm not saying the current WebRTC i= mplementation is perfect but I have seen my 14 year old=A0nephew developing= an audio/video chat for his homework :)

    Regards

    De=A0: I=F1aki= Baz Castillo <ibc@aliax.net>
    =C0=A0: Emil Ivov <emcho@jits= i.org>
    Cc=A0: &qu= ot;rt= cweb@ietf.org" <rtcweb@ietf.org>
    Envoy=E9 le : Vendredi 21 j= uin 2013 1h24
    Objet=A0: = Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

    2013/6/21 Emil Ivov <emcho@jitsi.org>:
    >
    > On 20= .06.13, 23:49, I=F1aki Baz Castillo wrote:
    >>
    >> In JsSIP= we are getting frustrated trying to implement the "hold" /
    >> "unhold" feature because it requires SDP parsing and man= gling. Sending
    >> a re-INVITE with a modified SDP (now with a video track enabled) seems
    >> to work (after lot of pain) but we = still miss a reliable API to know
    >> what the new SDP means. Inste= ad we need to parse the SDP to detect
    >> global (or per m=3D) line= attributes like "a=3Dinactive" or "a=3Dsendonly"
    >> etc etc. It's really painful.
    >
    >
    > I am hav= ing a problem following what you are trying to achieve here. In
    > JsS= IP you seem to be going for a full SIP implementation in the browser. If > this is true and if this WG decides to remove SDP from the API surface= , then
    > you would need to completely parse SDP in the JS and then co= nvert it into
    > API calls. Similarly, when creating offers and answer= s you would need to
    > construct SDP all by yourself.

    And we will do it very happily b= ecause then we will know what
    *exactly* we are sending on-the-wire.
    <= br>


    > So I am not sure why the SDP parsing in the current situation is so much of
    > a blocker for your use case.

    Becaus= e regardless I am a SIP-guy, I understand that the main mission
    of WebRT= C is to provide realtime communications *for* the WWW, and not
    to enable= a new interface for like-telephony-bussines.

    Today I'm doing SIP. Tomorrow I may be doing
    [[put_here_a_future= _RTC_protocol_not_based_on_SDP]] and then I don't
    want to be constra= ined by decisions made today that force any future
    RTC protocol to deal = with SDP O/A model.

    :)



    >> BTW I don't know wheter you support Plan= A, PlanB or NoPlan, but I did
    >> a question (in this case about No= Plan) for which I got no response,
    >> and honestly I would like to= see it replied regardless the solution
    >> uses PlanA, PlanB or NoPlan model:
    >>
    >> http://www.ietf.org/mail-archive/web/rtcweb= /current/msg07871.html
    >>
    > The other option would be indeed to do the same thing in J= S. I believe this
    > is JsSIP's use case. In that case however, re= gardless of whether you choose
    > Plan A, Plan B, No Plan or CU-RTC-We= b, you will inevitably be exposed to a
    > fair amount of complexity, parsing and JS magic.
    >
    > You a= re, after all, building a SIP stack.

    Yes, but JsSIP creates its own = SIP messages to be sent in the wire, so
    we have full control over *what*= we create and send. Those SIP
    messages are not provided by the WebRTC API. But for the SDP
    component, = JsSIP retreives a SDP blob string from the PC.






    <= br>>
    > In the above mail you also say:
    >
    >> Another= example:
    >>
    >> * I am a powerful SIP conference server which properly= implements
    >> WebRTC. I initiate a call to 5 users (running JS SIP app in their
    >> browsers). The = initial INVITE has SSRC/MSID fields in the SDP
    >> identifying all = the participants, am I right?
    >
    >
    > No, with No Plan ther= e are no SSRCs and MSIDs in the SDP that comes from the
    > browser.

    OK


    >> * Later, during the conference,= I call to another 6th participant and
    >> enter him into the confe= rence, so I need to send a re-INVITE to every
    >> participant with = a modified version of the SDP (note that this is SIP
    >> protocol, so I need to use SIP messages to carry the new info abou= t
    >> SSRC/MSID and so on).
    >
    >
    > That's the = thing. You don't need that. In Jitsi we do exactly this operation
    > with no Offer/Answer signalling. RTP carries enough information to pro= cess
    > streams and we use upper layer signalling (4575) for things su= ch as mapping
    > SSRCs to users and announcing current participant list.

    That is much better than P= lan A and Plan B.



    BTW: What would happen in NoPlan if the re= mote (i.e. a SIP
    gateway/endpoing) sends you a re-INVITE for "hold&= quot; purposes and you
    pass the SDP to your PC? or you should not pass the SDP to your PC?
    and = if so, what about if the SDP contains updated ICE candidates due
    to remo= te peer network mobility?



    Thanks a lot for your response.
    --
    I=F1aki Baz Castillo
    <ibc@aliax.net>
    ___________________= ____________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb


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




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




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


    --089e012292e2f86d4204dfb31969-- From bo.burman@ericsson.com Sat Jun 22 06:41:20 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0853C21F8ECE for ; Sat, 22 Jun 2013 06:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIlUbwswTeEy for ; Sat, 22 Jun 2013 06:41:14 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E181711E80FA for ; Sat, 22 Jun 2013 06:41:12 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-91-51c5a975f0f3 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DF.5E.18006.579A5C15; Sat, 22 Jun 2013 15:41:10 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.188]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Sat, 22 Jun 2013 15:41:09 +0200 From: Bo Burman To: "rtcweb@ietf.org" Thread-Topic: More H.264 vs VP8 tests Thread-Index: Ac5vQ4bE4hnmu5ERSv6YOg93i7vBVw== Date: Sat, 22 Jun 2013 13:41:08 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/mixed; boundary="_006_BBE9739C2C302046BD34B42713A1E2A22DECC12FESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUyM+JvrW7ZyqOBBk1P2C3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxofX/ewF30/wV1z6lt/AuG4CfxcjB4eEgInEtolAJieQKSZx 4d56ti5GLg4hgcOMEituH2WCcJYwSsw/sZIdpIpNQENi/o67jCC2iIC6xOWHF8DiwgIKEk9X 72aFiKtK3Gpbxw5h60ns3v+RGcRmAYrf/7mECcTmFfCV6OjYzQZiMwrIStz/fo8FxGYWEJe4 9WQ+E8RFIhIPL55mg7BFJV4+/scKcbSixPJ+OYjyTInrq1sYIUYKSpyc+YRlAqPQLCSTZiEp m4WkDCKuI7Fg9yc2CFtbYtnC18wQdoTE/CvdUL0WElM/HQCKcwHZwHD5ueU+O0RCUWJK90Mo 21xixvHvcEMnb+tkgmjYyihxavZjVlQNHEC2JdB1ahBhPYnuTV1Q9dsZJW69X8SMaYG9xLa1 OxghbBOJ082T2SAa9jJKvJi0hRVTg6PE6eOvoF4wk3h6fyEjRMNBRom7v9tRvLCAUXIVI3tu YmZOernRJkZgujq45bfqDsY750QOMUpzsCiJ8348tStQSCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA2NA8OUHl6JrnyjMsxGZnWj/hOVDcp/wFP4bS83VAyI6f2j3SDrwOm7vPM2T8OaUgobU Eb9d13KlzcXNJiTpigQK3pv54Ec0y5sp6Sw6lyf/OekvtJjl6sfQbJVGcfn5j+OCm64/lXxi Z1hieWau0IcfL+dLXWjPunl53lOHBdsuHhK8dqnL9IsSS3FGoqEWc1FxIgC4vzwHJQMAAA== Subject: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Jun 2013 13:41:20 -0000 --_006_BBE9739C2C302046BD34B42713A1E2A22DECC12FESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 We have had a look at Google's comparison between VP8 and H.264 constrained= baseline that was posted on April 3rd (http://www.ietf.org/mail-archive/we= b/rtcweb/current/msg07028.html). This post contains, as the one mentioned a= bove (and if the attachments make it to the list), information on the exact= tools and options used for encoding and should thus be repeatable by anyon= e interested. As was already stated by others on this list, one major problem is that Goo= gle's test involves the rate control mechanism. Typically codecs are measur= ed with rate control turned off, since it acts as a huge noise on the measu= rement. Instead we propose to compare the codecs using fixed qp-levels. The= qp-level is the quantization parameter that affects the rate/distortion tr= adeoff. Comparing using fixed qp-levels is what has been used when benchmar= king HEVC against H.264 in the JCT-VC standardization, for instance. We are= going to select a codec (essentially bit stream format), not a rate contro= l mechanism: Once the codec is selected you can choose whatever rate contro= l mechanism you wish. We used Google's excellent framework as the baseline and changed the parame= ter settings in order to make it possible to measure using fixed qp. We use= d the same sequences, but limited them to the first 10 seconds since they v= aried from 10 seconds to minutes; this also eased computation time. We used two H.264 encoder implementations: X264, which is an open-source co= dec that can operate in everything from real-time to slow, and JM which is = the reference implementation that was used to develop H.264. JM is very slo= w but attempts to be very efficient in terms of bits per quality. The resul= ts were as follows: X264 baseline vs VP8: H.264 wins with 1% JM baseline vs VP8: H.264 wins with 4% Running times:=20 X264: 1 hour 3 minutes VP8: 2 hours 0 minutes JM: order of magnitude slower It is interesting to note that the measurements are more stable in the new = test; the variance of the percentages for the sequences is now around 70, d= own from around 700 in Google's test of April 3rd. We believe this is due = to the removal of the rate controller, which acts like noise on the measure= ments.=20 We also tried setting H.264 to constrained high (no interlace and no B-pict= ures, compared to high). The results were then: X264 constrained high vs VP8: H.264 wins with 25% JM constrained high vs VP8: H.264 wins with 24% We also note that the script that Google provided to calculate the rate dif= ferences ("BD-rate") does not give exactly the same numbers as the JCT-VC-w= ay of calculating BD-rate. The main difference is that the JM score for con= strained high is better (around 29%) if the JCT-VC way of calculating BD-ra= te is used.=20 In summary we think that proper testing can conclude that there is no clear= performance advantage to any codec between VP8 and H.264 baseline. When co= mparing VP8 against H.264 constrained high on the other hand, it seems like= there is an advantage for H.264 constrained high. The attached file includes the files necessary to reproduce the test. Best Regards, Bo Burman --_006_BBE9739C2C302046BD34B42713A1E2A22DECC12FESESSMB105erics_ Content-Type: application/x-zip-compressed; name="Ericsson_h264_vs_vp8_comparison.zip" Content-Description: Ericsson_h264_vs_vp8_comparison.zip Content-Disposition: attachment; filename="Ericsson_h264_vs_vp8_comparison.zip"; size=93666; creation-date="Sat, 22 Jun 2013 12:11:35 GMT"; modification-date="Sat, 22 Jun 2013 12:11:35 GMT" Content-Transfer-Encoding: base64 UEsDBBQAAAAAAEBU1UIAAAAAAAAAAAAAAAAkAAAARXJpY3Nzb25faDI2NF92c192cDhfY29tcGFy aXNvbi9iaW4vUEsDBBQAAAAIAAKf00K0jo8xgAAAAM0BAAAuAAAARXJpY3Nzb25faDI2NF92c192 cDhfY29tcGFyaXNvbi9kcmF3X2dyYXBocy5zaNPTL8ssLk3Mic9NLSnKTC7WK6hUgDLjS1JzC3IS S1L1MkpycxSUtAz0SipKlBSKSxJLivXLCiygrAojM5P4pMTi1JzMvFQFOwWgTHxZcTyKMNgILj0q WZacn1dcUpQINDclPiMzPQPNUnRpqlmelYvFn0iC1LQItx+xSEIs5gIAUEsDBBQAAAAIAGVKuEIu JoSxUyAAAPF5AAA0AAAARXJpY3Nzb25faDI2NF92c192cDhfY29tcGFyaXNvbi9lbmNvZGVyX2Jh c2VsaW5lLmNmZ7w8+2/jNpM/N0D+B2ID3DlX22s7j+bSzwViO+nmkIc23t1ecbgLaImOhZUlV5Ty 6Ifvf795kBIlO7Gz21RFsbHIeXA4HM4Mh9oRV+pBnMeLPBNnYaTEWZLOZSZCLaQW0ySKkge9vbUj /uHJVM5VptIr+OcX0XfefJFRDq92xDCZz1WcQX8EGSsl/CSehndTwNyeAbpUSBGFOhPJVOh8sUjS TAWiglobaGBETPI7kSrsFcZ3QsaB+BonDzFwp3OlhVbqGLvOsmyhj9+/DxeTrD2bhe1pKvN4lkxV 2g7U9hb+t/NmDzELA9RvS4TmiKbIffriHUhVzWV8u5BpdvuHH07bT/n9O9O+Y+ZWqz9yFfvK4Pmg ZKDSCxXfZTODp1MATEU2UyLEfjhxYgaaIMWMQJpCZzKD1uzftYgYPozF5AnezVQK+McZ8HGGE1rl s8BPHcSUeqBGAFtJAPPbFo1O62p3e4uA9adkoE6xCRSEMexZDFf5fKJS1CHCokWWiAnqGvQ14DfI ZJWBvU67Q+DMHPVYABqtQEkDIN7utrod6AQsjJM89dVvYWDEY3F0fzo0g6AOZhQP2M8CfVDh3Syr AO3vrwCaUT8LdaN0+KfDsSMv06QZmP5GsSV5BhO0vXVN/77AKneossrvXmC1AmRZ3d76lEpfrVLC DBtuYSrb2WNmlG9HUHdBSrS9dYNyXgmrdHabKr+qt9RdZ2nuZ2ESi98/fyFElvc6IoOn3Tvcf1e+ BTyDMAMsSs5JNTO9igPUad0OZOaA7oA1Q7UkhQeTFfraMPC263xHsNanQD/O0iR6W3JemuCozkfD qkwOD1EEplVgc+PwsD+RWkVhrJrip5/6cxnGTXF01FePmYph7f0szm5O//uThdLHAtZT/wMoT1N0 u/wXvIIfvR7/2D/uHfeaore/b3/Df00BP4cnXy6G/BtMGKjXLpou+Ney5PDaoek6AUW5x0VN3QrW ca0AW48ZrPBjMZWRBu67xwI0SwFO8cKzIxqqDXaplFG/i+y7fPS7wMEvQpixVYkD/gt1r6KadJHn gw7ip1bBzUyr14HGiF73yBTZYas0TIIKig6xaBrAGJ63FqGf5SkYRMDW6Sdx9AQqm+oMZTe6WUKx EsnoRhRo6khOArkAIasqR2A2CIlthQ0BZbCgdgeowkExaxaICBsQwj9SkXxaxSyLuAEAu5ZVEVDn RthWbeHbdYu2AxthWJ537nleu90WMIzTWE5wOm9+vfaW0Y/ZLyHFQab8KNGwB0FfTSoUhBrBA9Ii RaiCAun1QsUu1lVIE+izFt1H73wchX7VVAG63hGi+5jLOGuLBTpOzKig3oiyddAleO818F4dnjbJ 8ddwUYPviBd2YA39FyAr8AjIfSCdFj3YdaKItmcBip0+gX8RpgGD7rbFukV4lcCizmbglQKcFuAB CvXoR3kAdEHVVDpXQYgLn6d/sMueQKHG21vDWZrM5UfvejrVqtjw7GC4VXz0YDzU3gARtNskhu2t Ec/POJ8sVHR5WoM1rQKbw0dYtJcJbVensGGAH41/4iKaTt8HairzKINphjWFLoaSqT+7kfGdO0fg pvQQ76V8BMcEe4gUuyAnl6dALUNnGPZRD2hVOBmrSPmZUGkK0wnedBr6bPvyKGphb+YdVW58MiJt G49PwfYeiw8ykHMJMwINu1U6Hxw6vRfpfJDR9NvpfNyYDqguBA2pJbUJnVFJx5X0y3QuUV1Hyg81 gW1AB1fLSA2ixP96lcQ3alqdH1xLIzXBZjRPjVTdASxskxrX0eisiIL0WSTvdomJOIlbqYI4Bn13 u9aQFdAoYoVUiRX4cjjIp9C1HCCb5aGM/DzC9TFMIsDpJ/NFEkOYxotnkWBbIO4xiMMFJWRwL5Ec xlsoN1x8at5et0xhz7sPcU1K2FshVmgBj2AUsgcF5m6u5gksfESJ9POM1oaM6FekHsPsaR1+11g6 q8k1mkYQp2yLLaidgU/yK+1NiZC+n+QggGWBTCn8xRkP8hSn6fJ0E77KXbLEVvK4DgMO4gQsZI0d LVq416k7mFNQAnC7MLgmWmsx9p7FiK9LbNqR2m+VcMCqD79FUaBC+mwrS4xt8QmN8sIqr9CzJI8C CBphT5dAKSJx6hlo/0MIMYpPLLGc22jWeC+5sVrO0R+Q3xfVnWaRqvswybVdBjnuysgTqbGYs+E1 RhO2se4h2W/vAhZ/p0Cv7eg6hN4TmnZJ7ASvyrWWwEaVgjoDJqt1TXEl/tEXK/lFTy+564HZPoP2 yzDO9X6F0FiB9CPocjuXj7c0hNs4n9/OuWuj1RXHAt1r8MJisRQCvz/Js6Qpful3oNsSpZK6dz28 0JOCfl8A3iXqsDHeJimEGLd+nN1GelLlYgUpFy1J9VcVqxTsxiUoeAgLGLwNZ7AQ98V6HmZibppd /VCoNMM8BellsGqKFo3DD30ZwUte0gL+Fr95MLWBss7SKl9pDNHHyeeRqD6l5MHonPg+GlrwKUPg C9j4HAN7VycXn0WDkhDkl0julUPbLgasGkDHNDIXLe8b3CqoecmPQ8bZTbVOCG0YbCbYr2yKvePC x0S7aF3H84K0t0S645LG5gatKZzQQo63IOHbMBAd3kJ4ZOwRkVq9PwsVLNCFDNOXHFDYNycXYCVo GJ8XgU2oWCZOacNMk0musxik1oAoEMbLvv9c+il4hLjXiZxg9S77QbCIjsV1rMABHhjeruyKlqmN HYhdlAMIJpkTC5cDWHIgyFnJwlmS+uRtIsjlQFM6xwj87cN041+Tn5A9Ld46/8fk6h65tdJei7mh dlwvmHnVYL9S3s3QCy3MWLfP07xbYCWj2T187B6uxHpOFpan0xhY7rwZ1qPVvK7GerQRr0eW1U2w iqMNeT2yrG6IdVNe91+FdX8jrPuv4nV/Q173X8Xr/gu8FpETrd4SL6/eMnJiM4ntZOarYKVKrgbj 9hWA5zHz+xwgbyml90BegLaZhwKRSq/RZFscJ4sF/OJm9IjOjbGKg5CcHDbw4GAy8SKkPjYCKlzC wtLuGpIwfvD/LY8r2P6iIH6BzVH8m/iQpOGfSZzBDwArEYxCeedgqCHAVvK49w8CdZcqVQd+ifo1 RACpg6KApAmocL4R3wRWQRHJWFmYGgpsk6mFYW/Vnafn1cNE9jzZCY0hm8lYjIZFEsgbXgr3IbXH HCyjwWbazFjxEZNR7UVClLwqcMcBLjtZN5PCKzxcWaQhBI5PIpJPqrILrwhsdpmcV09fFOQomRP+ SV4ydUC1DlYQJzqMn11jcncR+TV6gzURcCshwtwaOYziYQbB3CQPI0qx8VBUEHKOvsy4SRD3YkF5 M1gNJiHHGBoSglQ/02bbRs+nTP1B7B3GWlGo3hRyniAYzhs62MyQlzzAqpx+ekiqUjDsrmJHc/aI QhI+s9JCPUJPjQwCrwvESWF49pBg7ms+JlgOqO0xGcjlUGDOln4mfEzGJyTlyNF3BAEh3M8C/vRB 3SZlOBFzFAUjlKAKPvj7GmdiOMMkz0evdm5mhsZvoX91Lqag3DAhIVhijGnJNiFLjKzMZ+kS/7mo PAZ/HYBzAeyc3o4vzoenJQbvtRi8OobBazEM6hjG1WGsxzBeGsbYey2KYhwv+mnf9aBXaQ7ezNlP E0OUN3Ys6UQNT8XIk60IhaVizwLxNAUNYFN0jk/iWD2KAZqpm0/e3+Bsmzw/R8gUdbYWEmI1e3r8 hgzg6G5GhoMyI+gKSZAFUimmNdygFxg0xg/t3BwTUDcjMI2YHI7AFhtcbOgwy0aUyG8YfFLasfUr KbFnxqdFgLfAZ7NuHpEdGPuPmfZiHBjUA3vFIQNg7xrsmHuOi7SL4R/HYjymc4OvicsjLDKH/9Nt 7v1v024wWEHSXUHQcwj2NiToPUvwsEqwt0xv4NDb25DeYFN6ew49MtLOqcuK6ZIB+4kw9bxt8MyB ufFnCryLxkfvx/et7m5t0E6MLhp2/3aj9WUuBn8VF4NVXLi0S44qi6RIcz+nujJmf8yRPrkKxAKm vQPGUZ7jvE4Q4M+Cl1GatNeygBupjMCLjyUdTwaEj0PrqmA24usNzRPZR0fiYKcx+Cjzam9LG7zT 2tGFsE/fiBx3VqoD45PaOqcQQLpJQBUlDyK8i5OUNM1t0ypGPfsBH8T7Q/G4p4Q4PcURNuXHCotM c8bZmnVpeX52TEg3Y6jC66NUP2Ojw81JmXBRQRtlYiKRGzWtHOQ6MrGxyrJEwNUrM9HnteNMlNcZ 9UPpXCWCf9BB6ujsJFrMZJ1ohezN85gJ2Po+QXjfFr2m+GfrsClaB02Bp+edpvixi3+KHw//hfQG KltBbkN6CPw6ckZmVzWSm0oVDMv3SbZOuEL6CrD/9dJdJvkKmt8sYcDpfZ/eeq+Xbp3oM3q0hPkb JbtMbkN63yzVqxrJTaVa1dtvkGyd8As69FdJd5nkK2i+VsJvu8fZ0w4sxYxC4vi9ye69LeHtLaJS j8ysN7NjIgDySvh8BRRgGj6CKHfmE9Qc3qN69iUW6ury/V4/17BzySiaSP/rriF3kt7ldNRckjtw yUnb3rA9yXHiNFuXYo6ekJPknvPAeMxJ5G7v0iRfaD5t7NqguzzhZey/UidBh40Cprgj+n1YAOLs 8hrUG39kD4nhnxE2hcp82HQdIrdzubilHduq3Q66aZyYjZS85yJAzH2BY4GOhqBD8zPwOhABDIE8 h0hNsxYmb5prvIUdPM4Tg+SxleQZYds/FjdSUx4Yk0BCHByL38KFWovoEBCdPi5gMCFgcgcFsUiq ZMCZH5IWCYudKwzhsYC+KgefUhq37L6C1387RQ/NLESSyYR5xjo3/+tDiOWRKfOtkW9Q+wfgWqRY BrBOCu6zgwIukGO9BfraDhE8/QPtW0UMxb5yHHjmbPVH4MweHSApo7grpFHyg3W+dx28kND2p3fv iMPPtoZgpeqAjQGzc4g6DB1vVABqIePM5iJERYwQTFBJQtXvB+Uu4D6EKsVzkyfBZysI19rHvCYl g3+99pyCfOzToT54Jmwq7ZHT1KLDQ+bENzVmXS53EC89O6tLF8A7Bl8WHFhYY1SNRCnyJaYo81sS 5/VXHefUABUUi3GegMToYJ+KNsrYu9jTOPC2aXFCrotRva2NxQoBOs7iWjyw8VgDRmJ9j1mVa8zW hH+SoN+WEzr3J+K14kDOleyAuEreUF6Y0CdvQZPRBWmS9tG/PVRJF0JThO6OxpknTvmnQSvhdpgl 2lRsSmmtagEnNyMq+WpcQPxWlnURnvWq2WV4UGWqpH41fK+APwN7ImYrkIgWLdKHJP2KOyDWqhel 6usJgHnnHSHRlLQ/7x6SNGsdbdJ0YZIMz4uUc2nOMeblYC0TXITY4izod2NjmW+G7DksYHnzyeWA 70qMs/LajdUpnU+cA7SiNhs6ruUPRhslD8oU1fFMNkWQ0DRyZSIZRHQSXcS2dg9It4Dz1ykyCAXr ifN5hSgTQSeHd6sKOaog8rmiidX1uzgAVUb1rY+bB8zr/HUjHhXlr+PxeXncaVV1SAWZSlBjUPRt b1JxWaK+HN+W2OuoKWEPO3z0bVQQ5hq8hUguxs41KaBC1eymie9GYQavqHitEYMd5Vhwnfbkif9o iiMylAnjqAzp989fsuTm10F1SAVyBy+YE+wXJHgnRsgpq0iMDg4tJ/TXfh9OhmSyTe0ul+5mjyfB IruQd1TmjXKqyg+8psesvCVhOwpTeAcuxVp9WpmeXAvlpnjRZGJmDjSS3IDqNtLHaypodYcpH8s7 RyTWCpBRNsfxYVGBURqcmlhMMPxphgVfCR82i1IsNlautIM7QXWHZHaHiZpOwYGm2KSGHGuk3CIR DuQK5NisnTIRTggjBbrWkBXVIiKcFie5ldFwJZvGa2PTEOVXL9jmmtrf60K3wrrIQUoPXI2LpgXE bWGGk2dgoOEZiFRUnwIiXYJ4W/dmp4hqQI3nk0CC+y3xasM60G9/yHG3VJko5ap1EUJzEIDlAMxZ xJyhreJDgSL5XJbxkI9vSlRNf5YkeV35CnR0ggQTz3WUzIgtu7aTYrnhUksDeAeLPrYLB/pWqvpg 1WFUz+jqWUnRafPKo8D/wuGjcohXwVHPEK3B4RU4tre4kVWulvAGLIcH6Am4Mq0wYYrIbSY9N2UZ 0ibuQ8yC4d0elkp/BbH/EL3/azQ+eq1ub/f93m6VIW+ZoaOVDHl/AUPeMwxhjbbWeO34RNQeYOkA 5QxqA1E65sGk/xW2ePQ1BYa89twBo+AYdi/ktTyHwJvfIZfM0GkFn1qCdaq5+308sLRMLHl01v69 mglzgfqbuKjdi/wOLvhO2auYOEPpURA8TFLMj/xQYeF8iumnUsx8WhqamgNgDUJhxcSl1vl8QZjp CCrkLyhED/IJKwAIOXAD/yhY0AEmZjkWv57CbgnIUu1IYI/IcweqSgpsn9xUVOlwzj6II4lNRmzj S4jVTfBfE/soUdqkFh6cjDPWF6VKuoVUEyww4K2cK7zp2p8UyFbKsmq//Y5yUh5mj7N8On1DeiYN NKRb6bDnq4B8BC+Fkdd0hss/yb9kX8Amh5zAygmKypo150JMMr1Q8uvTIEf113aSbM1v7XGzqAQm GM6ULuA15AIXLrvyEjzgfBdh44QacYWZ9Bh/1cKtMlPmYjr8D1psluMKCrTFFiRqFMjYMglD4QE/ HFEgpzAHvy1RhdBGMqy25/HpBZZOQuw5Vn8gDZJ+mVgyNwpMueVpPMMbbQFmYiM5CSNMCRCCBmXu yg70koz1GMgqk+q7Xrjpkr5NvhtgjT2Lm8h4h4w8vepreS/DyJRzuqhH4FzQ1IMvS6gPCXXh2XJ2 klCVy7E4JgksdBWpp1IfPF9wrhBrX/xnbwVSMt2E2FXFApIKREOfKkOHcfbJ5NILGXREIQPvesgO cIcGXvzskj9U/Oy9aSoPMNMnPfy3/moC5elw62JClbuG9oALgi4bpOCZBffZ3hqEtMBE/emL/YNO ryPoaxXYozFZaCoNB+Mmo4/eUv8O/Yt34amHrQFmU1+UY9T8hHNeFutz+AXejwtQsYWKAyxtp3MX Xu7H9FkNrKSxlXkbnAzsUPIC2SlT2iATvPRFt7GqTznG0rThHR+zpOmuGFXbbkLYXEqc4JVEkAFn UI0jkSVYkc6mYxNcJR/SuASNd513dK8N3gw+C/VHDghxyzRX3LnsFLbo2iJyB2mrS8xm3hDdPmze aF7TJ/RRzfufRadPOxDm4M07zOsOOWxYLuG0+G/4AjCpLBFr080l7XyG6XiT0XcAZ5KGdyFuuf91 yXuAWXMb6QCe+7lAxmHSVMAcsnuD1+eMBa/ekiabRe41DmEjej2X4UWU8zcDoii8w2wdLC1NF8CL rGelZFI0whi/NIAzYI9v8DbD7kak91zSP4rZ0yQF1wy0I8D4za+KYYk4OAxIdgIrgzqW36HZgDaq BEdGsFBv0CzYpr7omu8gZTK9U4QcWkG4E1zSxEardhqPaUiZ8tx4ptErig8ofeAoYH+PNHJQId8p yHfaBy+TH7yKfEtkag4aDCLmQsbOhhx1HY56B2/JUXdDjnp/G0e9DTna+9s42tuQo/2/jaP95znC ZLFXWVWGo33iyGWF126OiS58I+tcUeIZXnu113bnHp9cnqKVeo6X82d42WsfddbxEtdX+vcycxnG K747Y8OWHTEPYwhc5/ZrM4iqzCa51pCQyceVyOwnyuby8RXIkLOlL+osc3a+ETLkbAWyvcMqZxsg e0s3dYeS7uQSjIqzoHVg3/psb53KNHrC5Hn16xuOD0I96CNBZeBCAYTN50PwcGrvvPF3WezHpkqc Jbqih5usd08UVuLFJAg6PPyBI/zw2zKjAGtB+e7VuPwGnItrxPexTmPfM1nlFzCN7OWtafGFNwPl ovyi0kmiV4UI9rYEWyfMChmE9wyCl/A3qGmm8yDwh1M+ZIvxQxyRW7bew0uCGUSrmOfeK3+8j+8n m6DfNwflzj2Dy4Hh2mS1MUZ+Y92/wRou9J/Mpcm/JSxkWpcyS8NHD09p44wL4otw2ejx//d2rb9t 20D8e4H+D1yNAQ3m2FbSdJuLDIjzaFzEnWKl7tYvhRIrjTq/Itltg2H/+3gPHqlHbDmtIyAfYol3 xxNFHu/xowRCWLrM9g3bI1KJExrN1IOeu4ysLwf4PLv9SGmTxsUirMp5XDOkoYkwit4sSS8juoQi 5UlBLXkzuNh+2/I8V+5sISs2Ng0pqlDO5fVoeqkHjjBLDDOYQmF7cDtL72GjV3IezM3paChMJ8MS CD2PvC18B7aWUTJOzRYPeKFvExiLBFxUuQq3TCnaLnEiSMpeUoUwZtYvhN9FQ0/QtmrqZUMrgwB4 Y6vUhu0Ih4PsldMeWDoS/rSCh9A8lJ0OQfnIu9d035/onfE06fYZukoRCI+qlbz09zZ02G0GXQmJ TsrcVM0Xrd9fFvj4a/Lxm4H/ED7dt33B4qrCJ9efbO71qj6tySvXp+W8nBGQ5N6VcOOxsU4HV3dO 2PkPYbf2e7O9Y22uxe5Br8/28CEs13yLyxeSh1/W5MOP3MEgNI4f8QxuMG8dneeYv1hIW3cWQpYx sjKC+VZlSt0GDxKgGnLeZpU26LZC3TgNKyfDEAlg+653Gn0DEIx1eIMHKojHehnGbJAH0QBXkgQp fI4X6dH4gUJf3J9j/0NQoTNPn6AMR0G/cEtWEkiKyOTF+jZIpf40OFbSlwCgE28Au7VAMnfVnEQK m0chmV9bLFyAyWLZiyHAWTh44OM1frQoyzC+xk9OL6Jj2OFCNlj6I2XdbTfXGTDdyRWETGGqoN0f JLins0i/wMXMjH9SMYb94OX54Vx/nA5KJVxs+gtUJTwoqdKJBQacUeMVQI1ECkyndAyG1DCG6nNK W09vFyEU2uotgMF0NvdN16s5Ptva0k8+RZa43hQEHV+d4a9H/GsVUntt5fcGJwfBBSL36q4fLcJR 3/aaLhkaxgKipITv05Cb7pPX1o5oqwqx3SUKBd1ktVWF4l6ZQqF0JKctNLL5252aLAMZUUZb7+PJ cPqVLfmZPF1FkLyefExDoMgfubOdrwYkujBuNvcqWLDijFtbmtIy9ZwMgR4JcTjqRWOndUGGlJ4y 4KUbkQThYvNxoYIkFJzFGJG/CSl68QSDw5lZV9Zq/JUmWZx7jLNsLvFkAMlkgpU+ruVzo8H0aLBw 0bBMOFZRQTgAg564snmblC38ViabmbDzsrFj8JGECxaXvoNZTZcdWyARwVqXZBa67TsxJblUb0/+ d2omKVmpSzWnNTsjZanalAXMHk9cEq8hmlbSMYPvgKQoiBZCZjwlfn/SrTZshKvguPtoprZBYtU8 e1GKvn1RSEuVXDVlmkAEAES9gBRzbqxtdyGEvzvXvnp2CgdsNA8Gh8aHiYlC+CBQEiKYKtUbnAHa qk1tM2RaquQis643UNQINhHz3uAv/K9AYc/bUYWr5kLMGUIQwsWQL8AoQ75AusWk/16L9MAA2S0l vMl3rWV491jjqoZOqi9hEvMChKgcXHpDCG4y2+AqjymKMeIwqefjcHKHeW/DxXh855JZzBnPzQCj LdLoejGisgKbinBJkBuc94h6paVQa8AcpbDicmrN2aeY197m9Eca7DxSiTjlx3SyCZ2sADd7pqMo qie5cQC0F8HivW/yE7Wm/X40G4VXkUAIZajxTYlistMDHf5+7jd4pRnZ/mjBuRQ5wob87q4qOZfC JmK06FwKQAH246uysxxqWRe3A4ZonTFGB+KUcc56sJBBGXuMe053KZyG97VpJaas12aLUsh0J6bI lhFxsmTktsL79wWrOqXg5YaWSRT5AeDlyMirxMj7LkZqyQXJQSiHwyGGpGeqHdaKw/PlcAxPExO6 gmSyQKAeVx5TcECbrYTtJ4f+GOvrZrNkqjfXsDzGEK/HX6+hCO9ytMI/VXNwIGNO1qYzScgKcTOI DnG2xJmtg6cAtXqakXjEQfWkez0yYF3EzCcIRZYUT9vRjBnaEUOdduT3VWJ7xAO7aqlScpvQps/R spqbfBvdg+5Qb6+hWzhC+HJ6YOaXV8BKEqFLqb3iGpqhhHrW6AdjT0wiSvKA71+GYD8i2Ez9u/f0 yWG/UIWhMiLzWgfVPPDsKP4HoAoAjtzAxPNypftU4alVomPuvnQ7SwJhQuvqbPqVzkT6aR96cNrb g5lBhv6yHpz2tvcaLRaPFQIjUsar6cTKB4viPX1ydgRyRPO5Gzd0JQHKk0gbBFCs4ozV3Fhb/X6J 1HRiyf0C+cU/v9jfby2lXIcf3xxeDA63T35teasYodMQLR5UeCyvsa5mI73/ilzlxnyskwsmJ/rC D1zGoGQbKasfuTksWZ0YM9/b79gu0adoHVwIIlxXO8VnMjDDONcUpyDqshGmo26cJ0xvtBhcwAj7 NKSWAkP9zzX4002buzo6qk3125bld4dz3Llv8jgMv4PhZ0CfOPdtFFmI8YxAZrbe9hLQjJ74vK0G 1vwmeNxM3iK4jG7CL/E0aVjlYdGlCYSLSCd01Kne1fitpOV7+m8naWVi5uxyR+ehXmcazvGo/+KS xkkddJyGvMlz/78Ku/l7L23ou7iTWQsGnUCaf9KW3+oqamdiTg3b2yC6dd6zLTPkF5E655JJ0aI5 LFQZk94h5mQbQGGHafNRt8GMAyjt+lo4ug0fNlggCFRcMhDBiASsGOcstzqXhZis76twBh/GsDl0 kZAh9yw/y+e6a352LBw4BChBxpAOOL3Cem48+AiUUSKfHU/kRIMvAL5/NHSl1zBXRDD0NckeOg57 4UTvidlZbUWim2ps78onANIcsTTpanGg2m2pKHpuxlq3g/RsOvl0ESXjrHYCsJOdGrcQDosBxegn cQJDTw6FLJyoIm2xZCx14pkNTDFQb8lpaCVVtLDvYB7H1rXPsyTxyBDvHSs6bSRxHsaQhlYMmqBt bYWWPGK9bZZhAWvFozPy8hw5Gkbl989/s347B3qSbmq934SjL7yW0yEneWEajgDozTIfyr09liPm DjOetoKHl3RAkydlcy1MTqvu9f9QSwMEFAAAAAgA7Vi3QlUTs5DpLgAA0sQAADwAAABFcmljc3Nv bl9oMjY0X3ZzX3ZwOF9jb21wYXJpc29uL2VuY29kZXJfY29uc3RyYWluZWRfaGlnaC5jZme8PGtP 48iWnxeJ/1BqpDuJNqSTkKFZ5mYkkkA3EmkMAea2VqvIsSvEtx0743J4zM7+9z2PKrucmGD6Dtc9 041ddR516tSp86hiT3yVj+I8Wq5ScRaEUpzFycJNRaCEq8QsDsP4Ue3u7Im/O27iLmQqk6/wz6+i Z325c8MVfNoTg3ixkFEK/RFkLKXw4mgW3M8Ac3MO6BLhijBQqYhnQq2WyzhJpS8KqJWGBkbEdHUv Eom9guheuJEvvkfxYwTcqZVUQkl5jF3nabpUxx8/Bstp2pzPg+YscVfRPJ7JpOnL3R38s/duDzEL A1TvS4TmiKbIfnriA0hVLtxosnSTdPK7F8yaz6uHD7p9T8+tkr+vZORJjeeLdH2ZXMjoPp1rPK0M YCbSuRQB9sOJE3PQBFfMCaQhVOqm0Jr+pETI8EEkps/wbS4TwD9OgY8znNAinxl+6iBm1AM1AtiK fZjfpqi19r/Wd3cIWN3EfXmKTaAgjOHAYPi6WkxlgjpEWJRIYzFFXYO+GvwamSwycNBqtgicmaMe S0CjJCipD8Sb7f12CzoBC6eROw3lQcdZhaGPGrc+CO4gfpq7if+TODjuiKXpWlvAcGbPqLFGjonw 3dQFvGL7swcEesIPFCL3K3RvQ/eThujDf+mfg2lDDNI/h/DPsAJsJ4Md2HDj0/O72/PXh14YczpP 4tX9XAAkLVNAImBFuzhsoYL7yA1phs+CB4kN89gHnUpkbgSOK3D8g8JJ/+xPbQENfkhA1WAOECb9 82T6El2UcwU83Rd4H74Bx89beLHwwJTHq8STvwW+Ngb89ET70yFj4g56zT5iPwP0RQb387QA1O2W AM2pn4G6lir4w1qflnbpJsXA9DMaiXiVgjna3bmkf7ewyh2KrPK3LawWgAyrThJ7Uim2nxZUi38g ow97ljawY21gBVpY+BxK90Fbrg3A1rFwQjdyEzayDdGGD673HfrTB6AdPMlQb8WlKKiD2axRQN0O LEcLh6qgIMDH7be7b7s7/8EPfQRevt1+63yEv+6KLR1ouft2W/x4cCz6n69F7TbKlnK92KN7LO46 7Zao3QW+jMUgdJMgfa6T4qVgLMCCXrvRfa4ORUmZPiKhTsDeGVgd/Va7/tzn8QI+wj+ATaAwTJhm g40ZwG1CkcwQuNf7FcZ7h47Kg0xUEEeVJAdov95eXDQq9EUzdH5zO7k+HXxq/VcVCDQ8g8H59eSw 1a7SH43O2WBQpWs3Z+aw0+1/rgKDdmQ8cm5OJ+1PrVEViMMMotOtBvEphzisBnFUEOvk9B8ngxvU qZvE9WSZn5RiwwTWaDN9Sj8YNNRdkJ+zu3ONrkAprFTpJJFe0bWi7ipNVl4KekNqhIiMwVlHpPE0 O4fdD/lXwNMPUsAi3QWtiFSVcYBul2rCfmqB7oHDjZ4T+WTgVQee0gzs7rCPdDm7C+SjshC1Rdlj +1QPBAEuFTlmsMbavTZ9bIhOr8PNtNrkY3tA7r3FL3DKYMkEO7ab3uz+g2YVu7KkI+P7ad8Lu76v 94xuC7GFfKRJHL4vuc+J+6w8d2MaWyQKZgX95vusX22wShKIncJnEUfw12OcfGcrdSSmQUrK1e20 MmMHuxOK8nw4KFIADxa3B24V2Fw7POxNXSXBA5MN8elTb+EGUUMcHfXkUyoj8Jl/EWfXp/+4MVDq GLH0vsA2CFtTm3+CT/DS6fBL97hz3AF96HbNO/xpCHgdnNxdDPgddkZYc4jiqDdahWmA0yyov6aE GI96Y9guwS7bDXXaRRPXjGNDhCew5B7Qg6du2XhRXjCWpxTc+WMxc0MlaXeFNSpfcb/3RE02wUXN Bdtr45htPmAhCNgvhBZIkTjgv5APMlybEuT55xbip1bBzUyrg/tISJ87FHeYYcskiDedB5hXboBV er6/DLx0lUhc3LVWj5RmFiQKleN8eL2BohTJ8FpkaNaRnPjuEoQsixxlE6BbQSFRBktqt4AKHGwA EWENQviHMnSfy5hlEdcAoG5YFT51rgVN2RSesYBohbERhuU4547jNJtNkYVyAP/50tlEP2anhRQH mfLCWIELBX0VqZAJN0iLJKHyM6SXSxnZWMuQxtDnVXRXzvk4DLyitQB0nSNEd7Vyo7QJ3h24p8yo oN6Icv/nNsE7b4F31uEpIh5/D5Zr8C1R3BoK4baC/ktyN9kokU6D7/IYgHtGBg4UO3mG2DAA741A 603x2iL8GsOiTufg1QKcElH8KOSTF67QZwvQsV5IP8CFz9Pfr3PYn6nx7s4AYtGFe+VczmZKZu6z GQy3iisHxkPtNRBBs0li2N0Z8vyMV9OlDEena7C6VWAz+d+jmDb+U9h6wQ/HH3ERzWYffTlzweLB NMOaAsxj6SbevOjmIt6DDuIduU+wE2IPdmt3d0an43gGxnk8Ph3JNAm8Ah+K2kToLqa+Kzxwp3Ep RTS3ACFGp4gBuE0xcwYejQO8FjCMZSi9VMgkAZAFUyDbCa71PvbmsaPKjk+GpK2AuIEhwBcI6hfo j0NDvUjni0Wns5XOFzec/Tidq8p0QPUhIkkMqSp0hjmdbKJepTNCdR9KL1AEVoEOrrah7Iex9/1r HF3LWXF+cC0O5RSb0bzVEnkPsLA3K1yHw7MsZarOQve+TkxEcbSfyBlsppGJu9nqgEYSK6SKl9HN XJ6Fz7DmvXQ0cESBMBhtQLWArvvpXO7PcD/AjjAsNxSs9bQMl3HIGs/Dpx8H8QKsneLvmAbaWB+v rX5gVi+yhkVGir8JnBMpXDAty1gF6etxGkWyY4KaYcAICxrQWEh90f7Yoc8Zxl/gU7f4qcBGLpXX aHcMbd5SNQNrpDrAUHWCbLlGg/5qBnNsSLFHD3bNDb0VwQziEKbEg7mII3Aoi0N+wFQ90hCu/+Ci nuA8sXCB0qL52sDA2XkI0Bi74FS5vtwH5YLdIH2UYJEWchGDxUeUSH+Vulpx8C2UTxD3v4bf3iUt M2rvlloQpzoRqR+jwTfud3JKYuF6XrwCAWwKZEZ5E1RNf5Xg+kKL+TJXhq/cPcqx5Ty+hgEHcQIq sMaOEvvo5Mh7mFNYveCkYwmFaL2KsfMiRvycY1OW1H4rpMGM+vBXFAWuZ483yRxjU9zgbrw0Vkeo ebwKfTF3wZlzgRIbAzUHs/UYpHMARZZYzs08Hr025olz/EC+K4ouxjKRD0G8UsZ+rdAdQ55IjcWC LYreLcF/aR/Sxu1cgNVuZeiVGV2L0DtCkXuEneBTbiRj8FCSAIPcltG6hvgq/t4Tpfyiix/fd2C/ PoP2URCtVLdAaCxB+iF0mSzcpwkNYRKtFpMFd63tt8WxwGAM3O9IbBQ6Pp6s0rghfu21oNsGpZy6 czm4UNOMfk8A3g3q4BFN4gQjcS9KJ6GaFrkoIWWjJal+lpFMwG5Q9AYLGNxMS2duwFlRC4hNF7rZ 1g+JSpPHtFmLwuEHEPLCR17SZNR/c2BqfWm85DIneQyx6sntUBSfXPJgdE48zNjCxhkGC3SKxG0E 7H09ubgVNSo1kUPqcq8VtNUx56MAdEwjs9Hyhs+tgpo3HHhknOMT433STs9mggOKBiZITXCBdtHE DOcZaWeDdMsmjc01WlM4oZkcJyDhSeCLFu/9PDJ2hUmtPp4FEhbo0g2SbZEHODzTC7ASNIzbpW/K ZlmqgjydJJ6uVBqB1GryCcfLQd/C9RIIBdBJESuCVXV2gGERHYvLSELk09e8fTUrGss+DE/sohxA MPGCWBj1YcmBIOc5C2dx4lGYgSCjvqKinRb4+1d2dWBFDl76vHzvKi+TWw/FzIpz9pkbasf1gmlr BfYr4d0Mw4/MjLV7PM31DCsZzfbhU/uwFCvVLfR0agPLnathPSrntRzrUSVejwyrVbCKo4q8HhlW K2Ktymv3TVi7lbB238RrtyKv3Tfx2t3C6/uuhj3R//cuv90dJjgMEozzsseIqf+DC7C/dQH2f3AB rmFdW4Dbsb6sKDbWzQW4BevWBVjEuq7U27FW5XVdqbdjfVmpbaybC3Ab1m0LsIj1LbxuX4D9wEmk /5pu9YN9cK39gEtVb9CxIvYXdGw79i0ysbC/rGtbsDNQJez5PLaqY0egFyWvUxXkuOQzygTybCF7 iNhOHm4RLJ+wcjBuLwE8j1hTXgJcZFVuDpwUjlWZbHuGSCaX6K0aHCfLJbxxMwaD59pPi3ydnCDf FmJrJk4CJJ9dCyiLhjMns65JwvgdNzE8lrB9J5MU4wLxN/ElToI/4iiFFwDLEQwD997CsIYAWynZ 0P3Zl/eJlOvA26hfpnMYT44ig6QJKHBeiW8CK6AI3UgamDUU+jCIhuFA3Z6nl9VDZ7N5smMaQzp3 IzEcZIUPZzAS9kOLKzvFRc3kx7PiIyat2suYKDlF4JYFnHcyETZllvDU2zIJFi54/aH7LAsBSElO p87knPWUfUaOChjBH5QgoA6o1n4JcaLD+DkrQJE+Ir/EQHhNBNxKiLCeRLGyeJxLMAKrIPTNAT7L OORVJhfEvVxSrSiNTRGKMdTc2QycB6UjFgz68nJX4MFnJSm93BDuIkYwnDfMLTBDTvyIhfubx7go Bc1uGTuKKyaUjeFDmUrIJ+ipkEHgdYk4KXWcPsZY71mMCZZzieYcKMjlUGCdkl5jPgfKh6LykWPY DAJCuF8E/OiBuk3zTAonhD0YoQuq4LkKjQ4qNRY2rpy1g6F6aPwV+hfnYgbKDRMSgCXGdB7ZJmSJ keU1HJXjPxeFR+NfB+A0KMflk/HF+eA0x+C8FYOzjqH/Vgz9dQzj4jBexzDeGMbYeSuKbBzv62LD xqv3jfelY1KOfZ1qtERxgKLIU459nTfR+QlenxJPBPeiOKUMJC7Oawmq6UkdkeTYyJboRnAqGJc2 SJS3cda+oYUp8PZrC0u4a4gzZluipITbz00el3Axb+IEXlnZMzOgHKNYNjRPhBoZ5KcB8rIoB0MY gt1ABLY+ch0qUYRG7WCEb+RiGSe4DR6Pl0DVDTM055HJqIbu/SaarFlQey0vCOF+cZp5dqXpXqPl /b8u3UuE2iWE2huE2v8SIbHlwTOExIdFIcDU+IrSqCA4unfh60x5hFn3EA8diHG2Q7xa2DmBvTrB IgSbBAv/gipvy2USw65Oh/9nwuWvMyzqTPHE2Xbk+fYR6JQ+l+9XCvfNLwHEz+BvoxvFJ9o4sMmk 5ORHXUD0PMlZo1+ivDoJ2e71c5Ep68RZ5prgmbaNPgXnhVjZ5JBHBswcsCLMrR7GHwA2dO0V08mE DTPE+EIVQQPz3KAjnLBjgzZRUtrQe6YzQ1eOKXWZwZ/4/1yByoEdz4oJGTJ9oKhG5zK8hAtAaOfa 9aa41IqpxLrBmEpwH4I4aebCo3rxqeYqY+mMDx33xAenlbScNvzfSVof0C3UXWGdzrG2SIUsUMOm davof0njh7zPc30im8kr5/9eUdOtz564c8Mgq3EWDRwmj5B+cpx9awh5HIHksg/NfLRj+bs1zyx2 y/NV1gkfM23ZHRs9/QVkhSOS4oOBmQAMHZHE0s7jxiEo6txmyhyalSgi7jHxKrVPRTXM2U3tjXvu EheG/7HgX9WxAqGHfi3j3EPOh2s+WwYQq6oJO8excGIP7VtKlWQ62LHJX65P7O7jCgATwPtgNuoA r3PRwcbYG1EZeQRB0T3rkM0SN0LMkrVmSwC5GWpu1OvsoAe+lZWxTM+w2nuiLsBPv5HJoiidMW6j VA5mJ9nF6hsKBnrmmRk+BGGdETLpDa1L/cC49OC981jKzhWZEJsqOHkBR9M4vc6LvczkAdEoIB+d Ci7fWJVh2mLRCtMOdQybVEmXthVVGYKcVsmONFHsUEKQu5nj+kcZoqZ10osbQexzN3zQmxgXjdZ5 aVr0V9PsGBDR75QOODurNSgkajdKYiwCtp1UxfNh8+PX+r/jBiH46+wLvC8hUGpH76aODkiD1OR/ 1h/kal/3Fnb3omc8dsZgg7x58cjpSxipq46GaZPC1UL7k6ImXKNj5yOEQOyP17PTJVNzTB7WD0bV +XsH/edxyRlIWAaHJUwU3GmgPNblDzYaTh5hc/kzP2Y5LjmnWZXGeVUaTmeDCND4uQoNlFsJGfSR ML2ThwsQMJ5dn8AqKmB8ac70XGRXNcHvI+c80wI0p5k2TPiyVhXM+jA+BUWUvfJiOZuBkpHdoZOk mFtgfPmVBFtT8oNuwA3y8Uz+dMbGJLIyDuC0hPHj5HdY26DH+joFX9/N7iQASk3QZgYxdkpk9sLA NjmsKLzOhA7TEtftnOt5cD8vsr3GNaVqaC9C0nNpL4/NceQ0OjmNVyWDNPSNDR7fFirva8ayK3ta gRp4yOP9TefzYhqHFOnaD/tosEyomcuCtVPka/lsQgG+83osWr3bu4sBzvjgpH8yqNNdIRTyOlbj 6Zurieg/IuaGaB2fRJF8wnup7ePrGwdcJjdJKT9fRGJQZM0UpCMCCBHF0KF97yBv5pMVZD3ef/5o +FhZSGGPBz81wCyBTlG8L+3dnQFTPQeiI5qX4kwKY5kMZ+QtzMCL0Md+9C0GmLwz/IhSDXU6qSh7 woSzFoqI23EZESZwhPRp4fUajagJvGrTACcdfJr6+08F1XIoe/UFttWQQpfX4H74obR84OU07ceS mnE7Ts7O8APNAJlRXlA0ETM64mQ+dI7NxHDPj3ZzHQ86lRO1qY7ySggS/lep8ukvQjDq71PtDNCa klg/TtN48SIvdO5J13l0V5fCae2Kvb9i8KFQ0NXcW3lHkjgeQ9Fyjzbk4mT3gEr4s6NNE5fjAqzn uPMIQWO3cPdfwh2kL+NuCAgjg0WRGlfmGIu5D2SoGRujA8DiERJw4x4Jij24wfpR3N2dWyUNd1lc Pjotor7FqNYMIc+CIMbRaSEGRsk4RTOYPRZCPKDJnSgnO+BIlRbExWjMb4TqHNbYaO0GnCgIGXu4 HJ9xnOuZewPoT1AAnLFuTRWTx7omJZf8/rpwLRKmD0yoPu9sMja1SEpfCTxlrGC2ApQ2OJqKSkwL mdxLTtobmbB4BqAF5nJHYUwdM6bFMokf8tC9cBUiB+Z8528mbad/E0alpNeeGISgAQqhrXwlMQsb B4yRUrV+AAYIpjxeRVyT5AqZqF3L31cBJkevh9q2ZvdVMJgqOepbF8fVGLNiaVEzAf4r5+ENLOjP 7RJlD2ODnZXPGeQp1KWrVBPTTy3MD8C+CENv0488chePPvMYq9HrGHrpY/wCPQkUa+16NaqNYteS 9gw21yS8ZnWtr/zQY68OzNli2ZTc7SirUllzrrN6+bI2Rgt/tRJdz9NXH6qJxLj2YQzRQ45UhRCf UGYs4Swgysek7/W9CdeWG/JVXCvFFGwi0UTSkqio8TdbJMC3nYgxtBM0b3gR/hlPdntU5/RziW8U 1yzThrcoKLmaL5pI5590gUdff5BY1we7BV21vvMkScw4Z9bbxd8KErGBu3KUEdXGsqsog3ZeAcv4 4yqPfdvL1AMxrVb2nU5daz51hu0v5rP1Ap8ZZ+/vrxifUSdR0ZLtk2Ka0PsdGcDRbVpW/VjKZi7Y WXcmgEG9itAQL/D+0vVQxEtM/oZ5nMCHRfCSFlEihe7fSFVItNh+kqbEms9FIcCb4TNpNYfI5gqU Yz8vwb4+jmrYzzPsQ94e8ipjW9RMNrtpiRCvo4BksnybRRqvy+ZWoWC4+UiHJtZAInk96L/bjYP/ aZgENJPeJOhYBDsVCTovEjwsEuxs0utb9A4q0utXpXdg0aPssnVRvERTrO2Qgxae1itHeHMJIVHt yvnPj/vt+tqgS7d/63yXv8lF/6/iol/GhU0756iwPrObtUavN7iIYp2QzPc3POlFLKDt9RlHXnZ+ myDyQxU/xgLuO7YF9/n8BCWfioKpxNc7WkYyzZbEZ/xrs/IbYe9Le3dn/ba0ME+Wu93Tv51mRb9c Yp1TiJbs62syjB9FcB/FCadurbb/L+7aettGlvR7gPyH3hh7YG98keTLyXigh0jOxQMrka3EszkP K1ASbROjW0TJSc5i//vWV9Xd7CYpiVQiD4FBxlTXpYvFZl+qvoppgbYmlsMITE6/8LRs5AJPH+23 QaJLOO9hXX6p4SsBug/6wNvE8MnGMHMzm+pm1RkODmEi/e2mWal3xOGYyHzdswaKnDN0Gn2zwRiC lAZjfZho2DSGgrh4+3o4fQjSQj2xN8s5M7GJZxpEj4eqtq/+9+BsXx2c7ivgf9DU/WUV/6tenv0f 5DXCeY64gvJAXE6cttmHlMiiVvWiEzaxbFqwJ5pmiluwblZkCZkbW5h4tn/Ob9vlrZsWusSPMpw3 tGxWXEF5G1v1Q0pkUav6fruBZdOCV/jQr7JuVmQJmRtbmHg2fs5v84Lf1vttJorVir1ZznlDy2bF FZS3sVU/pEQWtarvtxtYNi14hQ/9KutmRZaQWdbC252qmXTzmzCOhhFrfPREseIsJe9kt8JmFPvK yS7vnZMDyDHezqgHz5G5Vc3cBB52nNw/5igzgB70gv5fe1rc69n9Qoe3GXGnrrjA/L5rWvL8X5J9 JASmpoLe5FGy0YAzweK697PJYhoL3ENV6aDoJN5duL/jRorRHnDaWFH1Os6F37Y+knvjD+yQiv7C cF+F8z5NFh0h3VEw7c51VLgWRKsNfaQICNx9vYE1pfkx5suKUUve0uT5nreJZMY7DO/mBwiaXof8 yYCzqjH5fjABcC5dJ+fqJojxAneQiqLU6bn6M5quCUkmRmfEyERo7iu3UxGOTIKB5J+wtdhYCdgl cOp9O8iGY1dWYbR47XKQh34R2SY90RkIc/2/vkUAJpyJ3jH0Jrf/RlqrGXby11nBvXiH0DLHri+W jI4Q7GSS9+UJg9lz+4GTAOM/Ck/21SlEacfNsUaiD7BK7yvA/U+wPz8bEJdc16ExhoadM/gwNbwJ B+QWwXhudvOUZ0YnaMZZvpJzWzobqKzqJna2cnCC7CqO6n73se3g3qNNhdvgYFUD2su2tWYHlI9J X0cNVgVvRq26dvJj/GlVFyPKGu8Y43hxol5GKb3hboTL++f3804TWYm2n6/JYhyyz3v0uTvnvNrU 9Mw8tr3a7hi7Y0JBJWSUxnigp7FZj7Bz+BH7nU8UAGKEZ2JYFePxzRzd7iaSvtiT+DkMumRN9j7+ t8bBNA5FzBtNbm+c5ySBQrPBwUR+p6fEHxWzbbrWtUiTmwvG3Nq9mnxTCa6WOXdeQ18VenJlxjAt TV+z9G9pPFEPOUzUAb+kALDFFxDQshZZdr0AGt7lizDBdufzZ5fVM7ZmqqEx5VTvlS03qWwJO8nU rcZaJSoM33egD2l/lpvYvBizZVxo5F30Wo0mbwV25kl1C+Oz8aLnpPHqLUOu1bFWP+rtcPIt1Khm 8iT31WDCj1Gg4XhAxCTRZWxOjEj0AWlezpHJKEDyXIw8oSIEkxz5WnniGMKpL5BS4q4/pQG5Mtw3 3W8NNMjvebkeX1jgyE7nsmUl1XUYXpMR8ULFPw5s20MvFv0oH/IuYd3qdBPuadZ85CV40ptIAQ0S hIbBtOPUZyApjCOrf5KiDNiItpCDKWH0RTnXWJG9H/I/++oVD5QT4eF16cvn2/kEWPxelyxzhy8N J2g3mADCWgV34iIGuF/ma1+avSYP2RLhcs4RLs3599eD6fwquOdcA9jJt58E+1l8YtNQ6XAImlKs 9afcXfa1VO5JhWB+9+CRPA3wPyN1AERj1G3OBBzAOWQ0wyEPyjpkKLI4EMmAkzKLXgx/eiBXf5hI yrtKzGLWyt7vNJ34BOA3Hnabbrh2PvMGsHKoJ6bLaeYNAdPhtZcfCcWPE5StVX1oREGcEuGK+RDe ywEJ2kl8NzU+kuMXC+OTg5P6FuF3n2aLEIWCEuaGL//MuOJqxoMTTbPH6t/hbKKP4/aSA/WPNOPi WiIC++rid8jq1nLFz7GD4CGHPeDC2XzzJEg0urNJ9t4j1mV1UA+AA4Ey/ZJ4qC8qdRkPulqQ60j4 FVuLtDc0zd4SGvphCUUSEJuimGUotjvnc5ITrwQ2+XMcAGl5HenmF69mjFQRyudQsd1XUBKnZ4MJ NaAzBnA58LMHS7npX6a9WJKnooscduyO9OAF3U8UMWCg5qEYbQQAUBPeR3BpPZpQW+/t1LHPwi59 xKAqhzIc8W7IlaOHd0Dv8Uhv967h0c7jkd56W8OjkcfD305by8Ou8gb57PyspLXsOrn96lyWY5IY +Pkz+VXexyybs1PMHV2H856QDnwyZ4YLDScSmCPKCPumSOQWl6nnCPsvVfuf3d3r9kG1tnd0vOcr lDXO2atchdq/QKF2AYUaRRVq/AKFGgUU8txxlUI5jvgzuiVyV6rnufcq9Tq/4gl2ijzCzmVGpXwn 7/wKL+8sc3NkdMcxJg+vVeoipU7x+tJIHXJyHhfumvOaV2YT+tweu3FjmkVD2+Qcf2oSdvbltF+C gGhCkNp2qCP+xyiRWVmaKUdpJXQG2EZaZOLCN9ZCqkqUUoJzuXkzrjmZufiORonLO2yEJ4aW8KNI xw+Scosxff4k9CaOF6Mp8+YgjkhKpg6/If60L+wFmiOkr+gAR0SmIhPN24nZzC3KdMzipQGnwg5M G/ZFWmvF0UhWQ44tivTZ7HTR6+zj4Nhp+CSM9SbnN+fsCzHECEN2gKV6COeTRYWA/XLpj0BBrZnY 6gliPF8n0WGd+eLubovy9IZ0k2t80UQ7HPDEvI1445TPCBwer3RlAm62qZ0tHmd7ZmqzGhxs9Mnd VRj89aOxwAsQm4dkUAtTl3uew2RK6PTiA6WILC+8eAn+BPF8McSPPf4R75jeqJdsTxd1K9Q1s+g/ 8mL9QuZI4HmtFZGSwAOuiNASvqFSrGXOGy4oJutTxNoy4raX4zdXwE/pLHqd8CtksPWTLW4L3sRv iM3/6NCoH/Qi5LQqZrAr2Y+2wZXFeOmQWIM083HqbtzWzTGgJo7R0gbdo5wAL6/828FjEA0xTd/z WV/QjJ4fPa2qmfUZs7ZrbDknYVbJ62gPbAeG2mfaDmk1Op7TigZc6+q3Wg5THryZseuKllJn5jFS XnM897CetMGNDdofm7LqrHDH7Z9VXoTYP2tbPVQgzlzDt7/tgm58YoCPlwgyWDyuWRRKQl4YoKeq zuzC5gS/YCp91dXJaaVWUVz7Dy12e1Nsjl9KHux1O9O+wv8iPYRb+JBebYu7788UdN7++tNEy/d6 Si42DccDQH3yCbC87udcpBChqSbKvsAZ5Q5vo0Kd5HCNbAL8fwbm96+kj8nQBrh3/Upz2QBGHywi WNen6KE6xZ0uYGOmEvMJEDpl6CjCK9Ej0FOC3ReVF1zigO40PqsQWfP8ydRlrgSGjz7RqZfI7aSJ z9Qf811VrdPHG8PrjGtH6/u/q0qdv0A4DdT3cMLUlLV6OmQh4c/vhnZZFnbI+2ixU3e9QHqXlDqd zKL7CJ/cP1ryDdDvXCEfQASCS6QnTDEDOkYyvUElBT2C+5WOeMziCTa6UEhezVV4OlxIRZ3hMLrH uQG9WjEXcYrM+YuX/gBEElQbwxNwwYP2Cok+dkW/VA8/ejOampF3DLBp0vfNkBGuswNR7ZEbJlU9 C8iGS8hShF7UGwwL5qe6qurC53MAvDFz+pWMC+wGUeMgFReEA5FgJs/GwBe2bRgULzcdB6wfs0c2 PPEVK75yeLpafKOU+AM1N/CCkhlQKahR1dGodrpNjaoFNao9mUa1ghodP5lGxwU1OnkyjU6Wa4Rj q7b3VmmNTlgjVxV5dxfYXcadIK0VH4HR7Xbqtvlyd1633mCUWqbL5RJdjg9fVdbpMk6/6T+rTCsa 59SeNMuWHTWKxrRwHZmKk2CVbFO6oyEzC77nMjupaWbB9xLMoFle1mdKs0YhZtAsh1las2LMoFkG Ryqr2WUhZtAsh1las2LMoFkGRiurWafYE4BqOdxOKr5qBbmxbtm8jYxuxXrKumW5pc1WgpuGVvZ0 O/G5cQobtwIXPd/RkxyEhwhE6JbXTHxEzNPGCxu5sI5s0+v5szfBbPgDp5reqsmdp3ILLiabLG7V Mtxfqb9pihInPBN2toV7iuqeHefy3aYJdqS4drzd3Sr04cvn27cCtOpfdZs6yyXqpclupX5yXjnH Cr6Oct6Iwqzrut7HdS7gjSH+XeNynAZzU67Bq3WEZDCg2D6tVd41bhAtBEF8D88M+zlYPg8nixnX QUixkGrhEmhzzuud0Wgy1tgq1frlWJakJuyHWBIjniFchNP5Ax9Za5avNEtpgUWr4jb8xnHDfqoa 5O6rw8PD6gnPIvbSrPXh53rWFqYlVYlxJfeb0NSId5Zt+h6+3gNmTwNELCIhSEPTLXNkgQtbZRkN KFbeMj7rPMvksi5oGVoy97IFIJRnm0ztZubfO8ApgAtY3pxtxmmW4WQjXV59f+UutZM3ytYFRYGX uWnO22Kypy6LOlSSsb86Kc7DH0nJQK8N3r0Q63Te/0TEn7N1b7pBwo0TcDPVsUtGzysuBPb3zbjf 1hEIKzhdGIzgO2IgW7SaymV5G856kzhvZ8tYRibVOMzQDB+FBGUECySzckBV/EAWYGNqUHMnfRkY reE8iDgm4jj542j82JNAm3fDSS8YerZzumz6e8+teLUN3JQFH7Tw7u9uR4IRq7xF8TiJAHeIvXuc 8CAYcDTd9rfj+qAVzGfRd7XLX5G9bQq7HrGo5KggsdmLr135UYNVk33lOFW0ayNUcjx/6+U86K/z dVf3gHwMWc84/EBjbJNqOmyt0USRHql7p407x+6d3oTGFJTi/Ad+3LNKABvfUaHCyyFRwlT/6Zqh 8KmUqOYpIcPO5ydTopanhBT3vX0yJY59JcLZ3/E4TvKUeOrHcbpciad7HGdpn6DPzpM/jn+mLfF3 KPEqzxLGJzAhkHnpU6nzW55N/j51qpWl1rn9O9SpLrXOdtXZ5hd358YgZenp6pOcZYqs7Jc78+m2 IbNaO+/MkelxYuJmFiTh7GS5a1eQO6vg+YRMvE1cgBWVLwPJQ1DdBOhbuyUsq57qNpLftrRVIv64 /XTwoUL+5Oi97ynOxIZQYizzpcgEMxHmAZ/hTOvrNF4iRh0YoKajyXBghY4HPoq+CJUQAf1L5EDm 41wSsjggB4LTuI+HxWbaJo8q1qE9QJrFrpTZD+a5fALeBeyss0PFsIYBn4waox4mHUlWiPpKWQ/b 8zZ7IFGc4XQDezwnsxX77Invn2+D/nwyu7wxAIp1sweYfeh/JkHml0c23g8K58RWHJ1UfjvLyGmX lNM+sqGOpeQ0SsppbCLk8oORUkxIymg+PsI6w5WUlTJcKVmNkrIahQU5/jxLeZ4VpT29jCXX98yK a28irrQXWnGNTcSVc8bEkvqxlZK1kU8m1txE5EaumVh0E5FlPHTVB7/IhbjKG4z6SU6eScemT5/7 Rf4Vsj7HSKdirsq7OMxOUmKKaaOWVGYG++5FFoPaSNBf74JC8DQumt7W5QqxzZtfKDYD/r2mx1np Pyu6eMev290Pi1FGOkLvqwe/nTtBXddtmsDEOn6YaLvXavfyqH2kXd5ast1NRzeZ7vRRWYN/5GBV CXazbB36W18fn/52FTUfk+VT809olJwraWh0GM6C912341/xci67iDOi6jlQqqlLm21/j1BC+SFU y3StU8E/1tmGRjudQc0prV+nAJ8Iu1xljbMld23g5CCJnBxse+GlT0HZ3Z0yayZezgZUxtvUAmdj CDDLuLljTK1jmOgoR2BqzbUDCPK6AtK4Bt4oQsPRfmwbh7BwNrOwgNjPrffhd9RSLyMbgXsdrqPA masb8UAEno3tbieV4P4lGQO6P2/a/+oU6Ax9q6DDRSc7ptu1DL5WHrCJEYqc+4841sGgYPvSsWUM MixT146T9JnkfNrU/T2tXEefILqX3Shh5dCge8czEdZlEN3xVIKWcSMEBiGdP/6Vuh6fH5VxGA14 jyFCQiyAUBRPQ3qAi6nxfzExZ0vg4bWDOb2cXjEGdFtHb0gMgEJDi3UzszUE1VSIC+Cay/FePMJS fhABgFtwh+KviwCAv7VzVCiUyrv6d9P1YvGi51J0N2F+cq46jba64rsX+m4RVqfnqt26ffu68wkl g9D1i0WAIgOm13JZ1zBr8KQe7uYWclOT09aqWWsVYXa8wqCwjW+tIhxP8wwK7K+UtXibR7+7k5k+ L8xY689oPJh803tJU9u6iCJpO7X50FcSJiQKmE8x21FfNbAewCN5aX5yXigoa+tru1dme8WGN5ZW VHmaZkce6KALe7dCd86X0SGWVjSScNXWrWjCpQ3TkfYZTSTdhaPu29vQohWNOd3GG5DtZ5zvyvjL w5IJV5vbDB1UCje1UYuotXrYDHXFg0OtXDjIU06bKKMcmScYu7pVt6lb8D1PNzOWp3XTsXRPoJz2 c64z23rjcUm8Czqhxmw4zIFIcOmlbm0ZetkHELKpLdLnck3ZbRnXJA2MY4tmLot3yFDI6ZgBoWdW EsMSAPdIYH3uiWrLM3TVeXP5ZPPwT7TAbQXTKXWTxLqHIulVDVqSE3JTVnH5kdOexzcVVlFXL5wf bViFKcNEnFu0dgru00NJ+tqxlZsQ3g2FPgHJSBPTCsMy4vvORRq8P6ydnRy9vm2aSB/OAuWG4GSZ 8KZN6/YqGkVOKI1hU1E5l0w+aY0tRFjqzFu3/81/ZTicVmsqc+2o95NZ9G9akdH3wzDSZe3n4T0N CkgG46g6sP5SivVtSO9Tfx3jbTod6fD5qRx8hw9zHoNZpL+FXMNAI7wFdyhrlJSnxYSD888jLpij dkfB+IcKJOBp9MNls5grLlER8xgq0Al3i6Es9ZM8s55UJNBJ7WxXeZvIAl5tvOWX9TL7IqatB1VN pNnUuU/tukEMdIEuD6td5Ot29dsqMK1pSXlEg35GJ4+oKkRxMOt+iwYGXXTlZSWB6EG2ftdelgiZ GzScj9f1J5+Ihp3ZhNZGNG4soUmIHumLNOnG0T0toRmxtYj1hOguLxw5c9Fb6hEthsMuw68tU02I tKQ+xxV3B2Hcn0Wct71cvzSRrA6jMD2opYhqQiTBmeEMKLnIKQ1nOtZyFZHEzXW9wtbLLkskp55d Azy78hknfRKiOACYIWjlYc0n064UJS1B1OOCoyk6S4Rd4/F9Ec9ziIBPzQMr0REHmowvv4DKW0mE hd3YnRyuojurWELG4u5ymoUAGq/zJgwh2CZ6EGQRbwiB79P9bnK/gJeBqD/tdfvUKkFTzr88ol40 F5XX9DsjCZs5pYisJJ4LL9cyX1IZoscevTj034qnkCXShaFZ4ozWkCSQ3nQa47uSTp6AnNeOff1W tU5EuVQDotI141cRpajYPSXaQhPk9EmoTsTFHof9XBd77G/gYiAq7WIgKu1iRlIpF/MkFfUWT1IZ otIuBqLyLmb0K+dioCrvYqAq52KgoumdFgCHWm0OO/RJtbHE+2hKDNArJGjQgnmkZj7INeRMo36X bi5onrTuO5AYHQzn4Nh1OK6buYx4H7j7GPK+DU9kWHpP9sroE55wsLOxUfC9y6UYulPdfBCO0yW3 M5JAhM8UaEa9FSQO0XByX2PK0aN5po9miZElqp4tpXpI1jzLqPAh1ZVPu3ceqFP2Sqgghmbg+nvY W+AQwD/AS1Ntb0Uia5L3LTWM/jK11ZX4ESIbtiu4cYVgtkprMgttyBW6jBUGJ51g4cq4E8ioyQHR TyIwAqn/Ki+OrR2+ZldRah7HKCfiYfwItIjlLUEgiai5QTugHlwiFw6+hSBZw9fpgUGf+h2iFgaG Kpfb7xo21NSEHZbph65BgpLaDFIWzhMYwhvxUM6fef6sefM6h4Wjsl6MkiYKbdkxaLo9QNX7PrBz zXqS+lSg1TrVOeHKdttn0Uf15X11Nfl2gSFU/QePJ+9bpxXqXMd46aoevG8dnB5WtHraIJ6Lm06s bZhV7/mzqwvoEc7n3uvraALO4zDA6Or5asrX1j9fYYUdL8PuJdCd/vOkXq+s5LyPm380P902D97+ s1JdJ4jPHnlLgg0e2ce4r2hVgsxox7iRBEh5tTGtvZ4/+39QSwMEFAAAAAgAIoV0QjGkT6/+LAAA vbYAACsAAABFcmljc3Nvbl9oMjY0X3ZzX3ZwOF9jb21wYXJpc29uL2d2aXpfYXBpLnB57X1rc9tG luj3VOU/9MLrIjiBqIczW7ucyLVa2Zkom9i+kZLUlkalAklQgk0CNACKpnX13+959QsPirQ99+ZO DSqxQKD79OnTp8+rTzee/Mv+siz2R2m2v1hXt3n29VdP4D91mi/WRXpzW6nwtK+ODg7+Q/01z29m iTrLxgMp9FM6TrIymahlNkkKVd0m6mQRj+GPvInUb0lRpnmmjgYHKsQCgbwK+n9BEOt8qebxWmV5 pZZlAjDSUk1TaCf5ME4WlUozNc7ni1kaZ+NErdLqltoRKIiJ+h+BkY+qGIrHUGEBv6ZuQRVXgjRd t1W1GO7vr1arQUwYD/LiZn/GZcv9n85OX746f7kHWEutX7NZUpaqSN4v0wJ6PFqreAFYjeMR4DqL VyovVHxTJPCuyhHrVZFWaXYTqTKfVqu4SBDMJC2rIh0tK49oGkfoulsAyBZnKjg5V2fngfqvk/Oz 8wiB/H528cPrXy/U7ye//HLy6uLs5bl6/Ys6ff3qxdnF2etX8Ot7dfLqf9R/n716EakESAbtJB8W BfYA0EyRnMmEaHeeJB4K05xRKhfJOJ2mY+hadrOMbxJ1k98lRQY9UoukmKclDmsJCE4QzCydp1Vc 0aNGv6Chr78KguA0zwBEVao3xGlqElcxUArIRXfYtPDYb2m5jGfpR4KoTt6cqTFgnFUlgbpAHpml oyIu1moMJBolyDtE+HGRxBWMNqCLkAZ3LqTBC2jngkZsWdKf0frrr7wipRot01mFtMcedOEzUK+X 1WJZIdLzGLoE46uKePX1Vz+ev34VKfwXmKVc5DQLfozv4vNxkS6qSJ2e/xYh2dQPFz//pCpEg3qF IyFsOc4nyUA6AMy/Hy/Sct9Dc5+oNcnHyzmQhdFilL/+qhNnGgRs6vo6XsIIFNfX6hj4C4ZO/Z6k WVnBP5H6OS1vY2CMWfUxKRD3cT5S/xWX79KMagP75EWlxjepvT8Hps1uzl7bJ+WduYfRTap0DqhV xXr49VdKyYu3Jcobmehn9OxlUeSFW6ZEbk2wpIpLqSGvqvUiKRGjr78az2LgbTO8Lwkk9Ds0d30C CgS4gGG9SbKkiGciY4h4o7fJGEDeFvkqw9ltYA2IaEotoIXWxnCsX2Y4ZkWI+A2cB6ZVYoiEH0Ir caVugQdAphB19pE8+5pOgkwJcqwo4Ga2HsjAKTVJpur6Os3S6vo6LJPZlFtQqt7ywCsVcaHuq0wW cRFXeVEeh0EURCoYBv1Ha8HsXhbJdVyO0/T4+3hWJn2LJvwfL2cVt69yjWg6BTmHzIYCPcwjwx4D faNLUtl8ME/HRV4m4xzmzPGxOhharJ6oM5byRLZJnpRZDyl7l6h5uQfzL58tcXgjNUvwITB6DpMW 5MS7JFm4cEDvZDelKufxbAbEs6+KpFoWIIVhuJPw6STy/+sH6qkKfTLlg3USw8QBzPMM1NWeOsQf k3iNf27zJb9LMxDyeMdd62sgCVBxuG37XxSFqA7Epfy+Ojw4OBAsk9nmUbQj2Io+o9yN5Bat+Hwi rVx29+1Kg3SIK7XKJSi0sG06g+7GGTbQnJz3WwVAyPPVzPXfi3hREluSXkOtxJoPb+NuHWdFDk+i U9ZlZBJxE5Fa5IvlDJ8CK5MxhE1E2BjYScC7oAUSbfpc5D+eDwbEy/ME5P2kRASk17EqSWbDbzQM rBaZWsxTVoKs42A+l6DCRmQ4IEw0u1D7jmFuge0DbbMaL/I5VdMiFZtE0y4F9MGwIZMP6qHFR1VJ 2GeT9C6dAEHUOJnNykiBHIZ/QcmNYQ7Ps3JA7YGIyXXleT5Jp2ue/qTMS7Dj5jGCE+sFTALpAo8Y DAN0ejkGMVfrQzyZqCxZcQ+IhAXAR50OaIDtCOQitlMnuptQgy2OOOMOIJNWaYyGmzUz5suywmaR hFiYTCtCk/SJIJhbkd6vIVYkeaHNKaGE7lPOFgj1nS0Kog73fY2Yg+lZoA2KABkMKDaGMlCoB4Wx 5ZmUAW6Lx6B6JsgdgnMOvkCaxTOERA1eMzew8kTVARwGclO9EIi6dQdmCcbghCxigwWCO1R38WyZ wAB/jyY0WMBjBAq2XaRWCQNBFN4l65KsHoIoZLrQrIrdN5zgIYeW2XgGYmwGvAIsEaEdYXhZgW2M EkEDczmJ7PFkmmYb+KhXNptEWA5JECzwfyGwSpWAw6FJviyRysBdS7ByYPJh3TCdXEZk3cCfWTxK ZvB3DJyUz68XRQ7SCvpRXl1d9f1RJDqyBQ91AXuaCjTLBQ72iFgQcEMynL1AFYuTycwY5iRuTdnW BBpwZDJfVGtnlBoQZGiaI4FM4FYERGfg7kRIT/TckBLu3LM8oqFg15BQIBmAkDjVDLgUHyLqCBKY 6SUS2WkM2CeidwgvmSVoN5N8ccrIY561yR3cgkACthklhg9iJoMePrd7hNlA/QAM1SuJUh/iOY+q 3+8V8pzmaRIepeaAyDAyDya9QaxJLq9y6b6osPuwF/ci1cuW81FS9PpDdRn2Ru6TSIW9MT5gNuj1 rx40r6OfPUs+pKN0lsKApuKPQaeREhmOXkmyGkQA+kQTQm0eZ6loIHhXUB2Wf4Co+HU8N5bURxCd 8/gdQCqNe0n1gLNuYIYIr5yA+NW60spznhuGX/WIJ2V6Q86AKdkrWxkuQt02i8cIpTZehpFYiaLO EU1KDq3iOYpCLOWhFM4QMVDlC7Ao72BCAdxZQiM7YJquUgA1Qg90lBKvkY6D2R9PQRoQQWd5/g51 CuvW2SxfIYbCLUCpW35Azlxrt0Abj9FetSgTLFDjIAaoKtYRqXYqWiMuLSNx1y8B+UOcfbMj+veZ GEmNFomv4jpfjTy+4qoniwUIedR/obq8BOC9j72rSF1CA70V3X0Ldznd/Rnu3vWurpSYexeCNN7H So3gz3d7e3vYNYzfGIGg0km5T+Ks5MKHSn3kuyOlVnz3LWg8vvuzUu+YEi8c0TPV2jSS6QhTkWcb P2eqNichjahQVN0jAYdER03Bh04SfuJkrVMVhxyAYbNHmrzPhkxXoPBDFy3HhlZHhlzPiE6rBnU2 UMQTTWmF9nFNqHskEgrdWwo97EKheyDQ0DyAV2P8KeR52Egdrnqk63zsPRCd+PG3+vHKQNmRYmTo d7jkUducRcyOX4F6a1Hl9Fx7MwD3DGCl6BskjhdBIpGMa/1DrBQcljCnZlBb9am8CFZlAnxsufgR o6nWtGnGNr4OI9XBaymvtK2moZ8UN1oZtQ7piQcrcsSd46foGJoxyjTAlgsEMI3UC9vKm7gA6wos Z3VOrVhAWoR2XCJOMlAuZSRUxpCS2BEkYQZIwA0wupAh2oIZnSxk4LiPJrDAjPpaRm2AcYybFCyO CIPfM0e32ZA3vefBNXavj5lVvGTBjBKyVEFwoeoiONqwzZqD1dLTXfnG6S+jCV6MD1H7WkRstCLY JQG+RZ5wZnLfUKoxW1yynbiihyaHeLVgSOi727jaMIA3ORq3mWt4gPXWsH9Fu3O0eQM47tP4Ns5u eJWAbhEPlAyDRmfMTPolTsvEziXjQpoA5pCLTNDeNlJBi2TXDp2kEzLIyUrYGMIj63firL0kGAzB 2Co043OsBEEVd+P6Wgv4Y37QMQ0aTNb3gFAXjtXllfO0QSEocC8yGnrefA2jgh1AEWqo1wmp8cwA pgnp1f8pj5kX8ZXENf+zxCkw5nCKFv6neVKMk99QMoYkHyMWk9coTRyxzuVQo6JhOzOK1DAfem3J B/CjhP6oYLW/rvnkLAMGA94Hx3UGfZDITrtAJvhDEhbc1Oo2BbMWDMwlmPMsHjAuZSWuxRtmGUvo gOcRhoRZD+PdKM/BrM3wFqiT6L8YIwmArdqYLsCX+XQSrwPL9BSLsgifgHFXJXOtGMSfILrECxy0 IqWIWO4IRIsySDBCtdTg0GbkiJHuJ1b9NUsxuifuxa8X3+/9O0fm8Sc6swkMUgkCxYigs6nx0IHb RE6nlUPINPMVmtZyOIls95TaU5pDeHohSvSgv0WZqCmWTDXrU9YqsQmnowBdvr0ymsQz5VgDNMrz IiGKQ/CbDJUubOypWQW1D4bepYSmjdc7pOCYw2l4YYCMprX29WoVTMOvuR4PNQX/Y5UtZ7M9KjZh 747UX502QI59DDESuqZdizXIbwdhwkUvkPookHLgqajAOwXdWHbQTla7EAzo4vE7raKQn9rHgbV9 ExJyNy8imfAURnxp1XhCt6fA5hqeRIAdjNFhBDlCs0uG2plRWq4i5+ASFGObTDhMJ86q0S5xtmZA 7nIs9lGU8B6OIUbzcDUPisbvEhJu8DpUfUJ4asWGSBcttBL1lsKoiIAKYIbS88B05aV4zs48c0Uy G91ajPUlAM6s1V4jBNc0+PO/Bn0r82w187K97uHBQVtjATwP2mscOPLUVqDVtB2MAyvkySbAsfAM AY7QwM+9IhnjUj7Wb5PT+lrhYtHUjrXHHL14NO7ZUKP20OrGgr9+I9OcBKldu3kCKg3YppQ4mYTB YNCLJTM1BX+my2xs3BPrg4oDmk0sNDQvN0kLwCmcJRlj0ycCAWnQmX52VVNdbrnjY3D+kLRUodap yyPwwnHG9vt9hwsLHLa2Veng9yI3EpDIaIdO8OZZ87QcBOrppmGSCycSY9p3OtqK6+EVB5fLAavL C7xX36iQH+K0wEfRll35vqlvtNxAjcNcs3U/EAeDp+3L2/KaoR87q2QNu+vy4MozvXRtWfIKNZSo D92VRoZXepJVpgmLRN/wsemcZ2gKZHrpFyUMkGvM3K5XwuemFX5HK5616iKATO3WORWmGM2e5Ujx 6SyPK3/wGlg+zpvU/tMSDYvMGqWCjHqqqbURdZGCm1Ffsjn2GL7ty+KW7QeTBMGEwbKa7v17sBEv Mlk3Y6Wt2ZakBNO4V4YrypI239Oytv5hl7WbC9ttbe5Kj08aTiLEloNpzfcvSDn8RyjHK/dCOVm9 51+NBInN7Xa0+eWpx97OdtQz3tHnE+/Ld8S6bluJaNNd/EUpOCtMD6xoLZUcoznIu7LVRwOzgvWD dZc0HBt6YEXEz7t79Gvm14B+4WjYtjb57C/LcbxIQHexlRwmOuOD+yYkfUzuB+hmBM6o7zSiGvqj GU5p1WOitSY1kfcgaU0lPigX8djaOw6yyQoJ2ZnG5EiwLdigdjkijzN5AHXwCNn2/PH8UwFiytKn 1iWJ8qmVRQR9avXtkrq6R+TLDIpqH5dPHxT1eeOiPnNo1GePjvIH6HMgbJ0d1yYJmhlyDV5ojH9z LM1YmJab6W0i2Qb81zM4WyXjRc5uQbibJAwpL6S/WRiGDWn4yAB45bctS1K2QWBrKm5EsWGONrVu R0205ze0OpjlK1wZ6h6px4zZjuAzhofRYZOYuxttlxbAH6eXTui5mb8y2Cm07K3ytabDSEhqkZdl 6qyAWSnYSyc98yPEX1G/9lv1UI/3Oh7DX1qke/R9pO57TuT/EFd+5TfQ+7D3IADq4Wh3SVyvwtnY LiakDVU6kdwqdqojNxjRXIFYSbqZoAuzGNQ7p2ahfreh5eT9MpZlwHQyqFUga8cpL0E2mJoUdxut dUpYvWJ7ENGB1JrfZcC688+2ILTbLkTVwih+mAp7/MvLqBaJWdZtPTQjOYOyJeaE0FwGNfOs05Z0 lq5UQlsQNB2cF0Qj61k24yvegn/YiLHo0Ff/ExHS5rrs6JFRzwsVuKRqvQIJq6GVzrEYDnK4wsLt WFenGn2yfXEpday8agbyE3VSzywlxMC8nSXZDXrL4ErgCji9wxmmK/6eqLukwMWFBP6uKV8fWTOX 6cDU4NIUtZwlc0pqs3hcDp9ducZ3bfSwxsYefup46dzOLcZJ6aBJiYs9RYEL9zr3TPd0t1ga1tZx NKTFNc5sXFMN0kkw9MhzcNWmYQMST9sVxRahpFkybCvTEIpQ4f7BrvBizNVlS/VcHXpMRj245Lau oCcuXodXvprtgnjkDKoDk7taB3p0ZQu3g3s2dHu6UTBcPtOh4qFPnU/jLZHo23AWXoEj+jU/ITJN btsaos+WDbEC/bVhXLwccjdZoU76Z1c1wrYQ/9vPIaSZmyx/EJxe2UmnLeymlws2r4pvQbvmunnk xtisoOrsjttIW9caOrP3tOzhEDV6JR3WwTn9epOTsGW+B7A6YHt7fNA0RU26jZcjLptGKPlBm6PL MjFmhlMZc+r3yuVontLqg+QdObAosSLOLCBZb0FrhqGN1m6egaExJz0NtD3Idt8MauoE2gViMTFb U7bPhvO6OrU08DMzaMOzZ23VLrJGN2XQKZBj+cpmm+EguHlTaIrRQwMhLaBrnNOs9zqIRHBwHtRw +lXMzSKBwiWYR5TKVbJuxwRzWbXrTPj4SQhaS8Z1d0iY/UnclJ9JL1a5BtdhklNPzTYDMJ2Y2jZK aYx6g9geQBmK+W0SIcx+BC6BiYNs1eJdVylEYWgS9mgiSkkRtbKhJzWpPrjJCJSYxEEVbR1X3mXH Gao2PECbO7enR7423qYtk9BenzwWgqEaOE1IenSrUphQPbQ8eyUMeFzwUjDOilQy9mWqJXGZztYO Pi3ZfOQWbMgx0flPDAJLs6BKJv5sL2mOVgm+KJKbuJjQln3o8C3m8VfkM5ANv4vTQhuSlRwr0PBd +FV120q7tsukaBocGtkLJ20NSV7FYwlGfzyfWlGaYexv/fERHgrs2sNQWux3PG9i2v5+e0zPRCKv F3YZ2+6LAs+kwh2ZyEpxKQ6HmyOW6QQoOjZBtluJY41wzTOdBeM79wyh3UUXKCvSem1eumEnTJFe LCu7ZQPtC2fDhjEx8MeIiDPNc6TJCObxQ98YXLy9EODcyxjFlqT6FxF6KG20WD09kjlQ4gAT7rUg wRokQSLVa8iDHnkDTVgai5GHxcjFwuna7qi01GjFzaPWw1WD7PdAmce3dhAONMnHdpvHbjTXkHbp qpbfX5LqenPGBjwOv9jojz08DAl3I8uu6DQHub5VxQ5nTNtW1Db7Vh4dbgNyN2r/YUf9k/Gojfrn DvcjeLTMaZi9K3/2rvJigkMt09rlg2VW9fqqe5BXXm8I0G4d+nIDXJ9OiPpnDrIYhDuRl0Rm2DqZ Ip5KYVNwjnr9LzGRXLI2+vmFyDxqw8abTrZ3XwobS+VXry9ekiuD+4LoSC/cnjofpTdL2fhLbovJ wHT8K/9sCEPtaX0dyU8KrpmoLWYs+8+WDdQRtDqdJuRvrmJ04jRTjFh89h90Xcwjx040sdDwzFoN uG7ECTpEBcDMjhk2xmgGsH16pJ3QIXnW6NIZDAmKrpkjKfk9QTTQx70BhqnHt3kuu2nYq+a9ec76 iaydMMhUsl+xvKwm58ajwYd8DBslMXOOuFlSq3INEfdYU2HatElxDwlthekgGYi+6nsE7VPHJxO7 lcsOiBucx/FcltgEhdwr3r88S6nFtDlUkdiVD3Z+7u3priHBpF/ioiMN7h/0wxZHME1mjUWeJ8Rw RB0OPdC282RBJjIniqMDCQxC4kiHlUK7ZsJLMQzNX/BoCWJts5bDPI0bo2pJqjXvvGtPlAvhMiAx IOFQuGsrYqQBFQu4pyZsK8G8S1vDCN4n6jzFw/SYm8jLobot+1bNRkI0kag/hmJY7zYuweNujfsF 19dY5/o62Ga566WOZ8eZacqcecOLVtuseeAwtRC47yG9eaj90DytO3GwvaT0+WzPXRnVmOKmJePH jc3WOL2xjVeksJnWnZdO/HpbJsLa/bZqnZyzkXewI07AX8c1Y9qPGdqK7qoKnd8jEtNW3S74Xhvi Ugc+AeY26w4BciR5wAO7DUMYXlDSnH5hBDYJ2dSPQ3h80T0uG/jWd8PdFfVYgnjAbOkkebxbgaso 7SozZdEZ5Ujb30ZJtUoSCdytcuoZxblIkFMMt+QAsNJBtNQQBCvN8xJXMTASamnBojMnbFm0somE gOnsnZDAV5g5anbOPNGnBOABTmN3d3BLC32jQt0oKAIwORNPdJaR3RKSZ7O1OqRiYTr1qkvbItRr wN0Om9Qle9COOth7RvO2pI7HZbmcJ5pYNSppUE5XBvqZtq6g0iqmPXPuYCFebHPpgym13UXbrXFf dWlFKu03aYov9S/HQAA3ISLcJMMGOFphnzZDNPRW381PwVY3ASKyGVCk72rVWxF26/XVd+rbvitQ L1pJ7O13e6MDyWubB9wuV0k+myOiZDjxjFZAAW1JTIn1DpAqSfPBzzVN1GWWvrfJ1Mi5dE6QYcKS ls9aukhNhd4uC8KFZCVbMmzmEzeCeRkSYPxFdpf9KWsVfd6P6oKrS31n9aU1Aa22sQqvbfUJoWN2 xTiapZa4uiNEAfcFNRWyyU6aqkstMBOCuQG+Y00Oks3D+0grZlF0CKA/MgDbkmDDzOzXIXVQYztK 6P1NrrGnvvE1jsVz27Vbb/o/qr78i1d9ecXpG3Woc4v+U+x6Ury4jizD4p1kCka+u/DKfWquUA2M M6DTJ72TCbhBbOMVqbHX01/y1caGrLqjQ//qq6BAP9A0eWF32xJKDTRQJDrnG/QtIudJhTickovz xng4cmYMH3jY8OYdZKF+p5MEIoW3WgCYsNSnCCp1GutjOay3XLBh4Jna3GlhcNMQg2xvDg98tOcs Sm2u762D4xte5IM7cra5pyiak6q7P1buN5cMT5rHfDhmed6W6Gh9ZWxVd8DpdD2BUPs2jG2rO4Ns AtoI/4pGmnL3kEOo37ZNwxBYHCdwWH9GWrY5/pZ/zIEUzDBYcYvDhLBWSYdbEr7i2RM7EwNHfEIZ 0jD5kJZksnij+TOYNXyypDdcblrrVJxxPhSTatOIu/wjAs1WckZM85Gcmmpf0N4WfaSa2VT+Jxi6 PzE8w/Qd3If9NNxXMjwzdxmyyNXN/OazV4P7hJljd35uEJktU6mNEzcck+IcldPBBw7jOIV3Yh2u V9qTUd1Tcgy9ES7pUirN4pFZgN7IEai04omROa5kx+CR41DJTHZ3+srRSuYsR45H+icPieW48+FX DA8dCXMaH462fxAWGzXb8BsdDzuZ+GSzZ5a2HQ5LZXzOccMxjOnnsGpkg7qSq7GBT9vEqO5RLEm6 3tzbIqHCdN+kQtDB3bUU8GbSkRP7k3X6efwhncczSWwBDjyInDMmSLeBx4VnHdREnoYzo+NYOQgL JhBJhrmcC3N9hm6JnTkD9RreFqu0TJxWDCQRjfVackCHIRY7534QzbdbLvcOr4wxaAjp6BXiMDtm XLvWbBjeP7SJhIh1sN2o5Bj3OwJiEXLgSJlGXZY1wGx32DneNVoa4QNPUhAXHxx5QwDsUQ/IZCUe X2Y038Bhgt91eJ3DvSTZDVDU3kRcPG4lQaFUGZcMncCPdre+rfP82DXepPA20UvD0jVG9gKLVZ7D g2ThhnZeJDEdfGZWLCRcjbGPyDKtCZiXcsivZaAa85jOXNX8BRsgNv2pDQyYH5cboKWT4Iqck9ie OufoJ+OB+UBrbpizw2AHxCk6adCumWfMTY55RjlZTuo1vfejultFoj8jDC2BaGza+r7EsRTMysxH YrTQAfLIyayWS209FncFn4FKOW0UfUCWt5u4SSgReJTPK7FzUL3ZCApKERPaqMmRXWYCXhtmQ47b fjNznLLkQOk23YNzPo0Fna14eFm0vzlWh5/NmzRO7zLU3rfW/ZPMWD98TDSXXSmkvGHUfdn+CCNu wYaONkcB56KzC0s2GPIJL1Wi6EwlJdQVM9TANpPVhC2Ot1Jk1KyeAPqoHorM6TxKp7+EDwXqXA4G +BSa68BpeNXgamadFqZv5UBTQYs758mX4S45o8xdSco4UZ0ioWTO0AD4zEStcQjJoeeZWT82Ia16 ciBHuIHYMS6X5sXEKpyGsMHNV8mEJckSbMQZA17kaWbtzq2771kYEl514qrEkM542PpIesC/DtaG zvzi24gNOWzd7UHD2rEQG4YLnkf0aBiM2AUauopcsaQOXTPpTYHf2klcG4k+aXA9Wh/biDJulOCC pTUEaGNbBk5MwT7Mnv7CA67ljtYGTrtvot+6GwHOPc+7mcceln0TRB+to1r4Xy7v9GHOrZ+kRWKs OKoNHrb5OgQ9MEWaAFP6XARmlbh5zvo7W+zsJZNhs6Jsy6Fhw84ElHvwPacCcPRLOFB/NCGEhvrm mxJ1eGEDINgaUON/o2kHtkYL8BYol2GA9Q+DyKkbKX565D290iBlsS1uoQ5edFYijRBt2o2Lghef 5Gh3uAs1yh7G1lOr7cSwbhnvGJKtMSSad06aP/fGV2+a6gEavGsAcekZPveEnGFSX366Ikcjwv7I NSJ8TXjaGIm/PqJhtq6H4WKMpXF7LbP0RWaRfkGHwh35U0K/c3YiKtovBn2n3V44Clf9xpzEgKBp UEScIy8bVPE7aBaTOneu1mmlxTZXPbRmKh1uENZhh/yhDsl5MZSAd21EwAte1WgQejTob4sdhUVr 0NArQGCECC6Nqj2vC1ueifTS36HLJ2RznhLJ/OFWuyCDGl9bB4+C/tCn0/nie3BqMZR8SC74ke08 8P94vrBOLw46T8GBOs3nrABGa56I2F1qbZ+bwqeYQFpax9hZxYSC13OUcUD8OoVdpTtfXPOnI4AJ TZ0/4XPCGAZgcJNUNNiMvfvEUcdobBlYvrMgi3DmbW1yH2iK6cnO5oEz5yOsfOwQ09Go+qhTUaYs 88QSuKaZIwfvt6vZ3wtwpxwly2FE2rHy47mio4LNXg+u5J72uuLa5nNaIHl1LQ5JcNYiHWYpSxD8 9UH6SqXhSicEYNZUyLxSMJXTMX2GxsS/J8loeXNjVovRVmvX+O071Jw4JD1e6VOMqQGJYRvMesY4 5OsuLlLCmOrqVTLKbpjortsApTsK3XYHfyTK7gMUsB2Tz/3wlYa0VvY7OTEF9Wn1/eyF/VwWttEB EYqw2YKfZ1nFmbtGIF1rUet0vcorGWn6lC2GdAmPNiTQjtbfheoyJWESISD+YJpp9PNNtxb833DI PWbPL/ct005D4aSD0yM+VA4YPTIcXrazONkTLo+a3B22QLxVVlufAzGmI7JxTjXkTQAsioN3CPIM ly42fwo2xA8RG5pgtQG4SqdMQmebd8z/bCztbAXnfzaWdg5RH/M/rcVxzTg8PGi+K5PqNJnN8ADh gw7cnCKH9B8eWBep+2Ca53hQwygugoeN1Y5A6xfLxCsjHxVsq/EfjEtbV5wigMgzKPXsXzcXg7an 9FHRvwQ7GJ/Gkm1ZVnAiNOb7Lcp8l9XJ5nA/6mr0eTr1BRrOG+8wLP/tsbKRg+7IhVisaK2jx6sd 38vQ1CVl1t8AwYko26i4/nikXev0viOC044rvS1pDh/zvHlabjtr/pbhYQIWjo4TNRelNHmkpW+g qaclDjSBemMzIZ6WGqx3ugFr9NpBZu1t9X1a6AiT1ivNVTakahppwmrnOgm9oex3dMFO5qdlpPj/ 7h64D2qd0aOPDHNljmXYoYacXLJLFWQt77To2vsGbQM3stYYSyaEO5iTTnLoIU0bo/o4DhrlxkiQ nHw6MQ1yE/V0HJ8/MMx7k9fWCFEZIePob8BZRgkB4ZCW0MaLft9nGG7EC+4YR7GWUE6hOFkRNEFy vTEfl/nY+U4L32ghDN6KNNiGWfWoage84MQf+EPkbYgvvHDxJc3c+DqvGEh4112J13CiOucI+3po bJWuOAbBfz1eoCzyPK+UD37hbEI6it2r5lWM5BzYGmNpZC+PXMT8gOy0dpR5XtRWwNf8GYPZzIVg GTHUUwH1F7H/REsFMxF8vM0VmgnxtjPISAPwcuPBtRgf/az6GOTU1HR9u0YeaHP++53umPfOzH8b bYORL6EWmyQQCIDPFj+m0+KJciOur/lDNZ+Jp+lNu0/0MTP1w8XPP2lfI286m55D57X4T3/qH8Kf 2sABXMJ3dFSIKMl9ar+sQ0gnK8ppcaTqd7fAr8+/G+WT9fPvuI0R82twGDy3nfgO6scTKFLA/7fP 4+/24V+8G5m7Md/tY5F9Lu7WpyYcqjCoyfNDKDyhu+BjYO6P+A6BtdRB18BWW9n7tlrw028bHmBH oRx3e59o8HdyIfCGmruuEhgmNLpBInWT/W/B4d+C50/LdiQFoJ7nHkg7QlTbjoJOQAYDqFaDQFNp urMFa+UMSCmBYGGCkCKo4cAlbw2mzSITLkJ4caE/vOOk2ydRY5cRnJq+5K3jjfV00LqVdhtX6Mc3 6SAhLdhl1vd9NJFVAM0GlzwFlhy8zdMsdBEzvSQGqXXxU8xgsoCX2ZL2GiwsXduNX0ssoEij/c83 iTcOEILH5TReEpfI1SphpcQP3y9z1M1hENiDs6zV6xqiYk2LJY30cU1pFBMNc/r/ovG8yZJFXFdJ D08SyiUdlDWiC8COj2blGg+7jEod8s8Kpy/2bLIZP7cBB7phZQ3Jk2nOPDBNGsMOa8oE8iWmrWWg 26nD5mBN0D9VZqIRxG8sdG994rS8285kRJMYTZoqB/0cBVtZkOr0/Le60fiaTTrgSjZsKZrKnzoc JeNYf+1TDj4MxuVdoOb5ZIkWSJz1KslbZWD6g4nsBGGGmXuIL37Gzcus/qfl+g9nuXIpw5r1kyTN Cy1X3B3KnD2zYTnBsq+qp6bLyOqyXRF/PNsCz5zoje0ZcodR72MvOjK/n0V48E6v93eyAvkW5tH1 aInbf1E7s+g6ez3QN/pUYlozpCLl3YB/hLYqnlc5S+f49NhQ9v+fGDT3R7qVr8LLdpNGe9z2Eweq 7epS8LWY9z+yAfMPZYkM1K+l5KtRiiEtZ4NU3cfD+2obvm1Hm1hh1y+3PkOZr6b50WHE1HnTY86G VbMt4IONgLcwltosok6I9WnoGEJcROdkGLmDKR0EVC94se1yUd6hTNw95qX31saYU8qZAvFoTyRa MtljzgA84gn7x2v187miturawoGBRszhv4FmrSp4AGRJY/nGTYqbm3iVKx6VWiml7ianmi7aZKC8 gEl8QzkNoNPIgmtRwa2FPMwdPef1vtYB6BV0ivq4UQfWNxtrnkAD0+uAHRTPpPxbVZe09U/NGIZi Qv/0Mug77HDNXxh+PXr76exgDvkulykbVkC8EZ09Yj/SjeuvW42TtUROtjH7jIHnU8Fcrtk3N2kt GoJnbp5NndNhO8DVMNGnKckI/z806sLuTFB/B6E9j50Mu7X+xjQ84LtfknKRZ2WDQ//whsoTdYrD q6eZDBMynj6WyDYGD9z0UoF+nU42hoawmjKf2nD1GNSUFdg2zjGf3GhWEeuptRZpxrZKrDLNaWw1 ncplNq/2SmcugwUdPrFV9RohTFKn/O4aB/Sg1dsy15sS0LFvIb+swu5ku9Xh7GR+tdlNlAUJFSPi 7P5WFhTDa116FRShMf/b5B0fHOtaQNVcdwfMoE2PB7eUv5z6XB2SBanNn04L0oK/DKaB2YkFVbqB d63VOszEQNyPrLTaQs1uOX0yo+sFlpjLuISwEUEY4yzRNbxp4a4vSg3D84saqNINPbkMjcxr28pn pUxKrAMGKjI4PNFQpP1tsmcYrEaovXgtYKUruRYdSu1PV99mR7mT3bqUrfuUMWsT9vA0MdrkTad5 MKjW3FkSui1w5VAA3kkwMydb/pVSkxjeb25+kjp5c9bRPn6rgp0x0eISXjGby27z0sggL+mJl+fg LxQvVJlW/JE3MRNyRbEx7XQyLDZrgCAcYBuQLubWpZf6iE0uvznXyu1HpJLBTWR4YjAYIGbzNZDq RqJP2JESH/m9cJL2pLkyqV5nuLX6FMyUUTx+F06KeEVN2rQ8k5hu3oV9de+Kx4K97a2yxq7n62tk v2t9GMHB4N/cFMD5msoNsDHeHWZePuxmDf4zrNiFyh8krLjRAiUT02F75xgLJ3veEzYmv9FOQ/Vp qcQ7rrDfo4jHs6fTyRCzhMlEoztU/0OdFNx2PjTWGJkaI11Dko6bNajC2FQY15tw7cKCzl26vB8P L+/vhocPEfwbfAzo79HDFR7rMLzHV8+i6RDX27nEiv9injAUcgEuhoSC/wGEv2s49fG8XOooa7pa Jo/Fm81D67h6IsOqu34jllLXmdrT2U534kEr78E4Pm45yZuvQuBd82ILuOet0vN/LZNiTflNUr5l Wai2awW0qQbu6VMmFU3JPZ6SsRrPUnZFGWa3frYQc7McZgFQLNIpIVOQVXWLln5PveLmZHJrpV/k 44QEh+xBxN0vZrML6jk5OFu+S1rlFDDH0G/sro0Rcr4ORNVIm5sZVmzP6iS4OwYcRLwB9jEd8Ymy kMMxZGH1NwrXrSszF9WXXAyp8WNXMOowIEWa3FmiQbVlUlYOGJ/ZOgHK+1aoLiPbBrqFuMs1VoIT I46TVOCCFG/aXMT0hn4srZlZDECzbQlImJUzCdTQqDuC3tPzwqp4xG2n7NcSXg4zI1+TQpTpLK0c h7Ld1GlM1vDeJVoPuBQPK+8Ne2D54FHpQMazCf7s0fcl4mpZwq/X/+1/daFHLI0n+4uyAWvuKtIy Hn880DYOroMmA8vbX3/5SeYqm7aNyaa3fMV68+8S/FscFdfG5sufw3+NJzd4TCCQZ1rk89rOL0eI G8YTj8iCDIQYuBEFqOF+NjEgssCLEk/goxng5rUGRA58vaVsd+sykbHR/J3EqsQH20nfBE95vwJl l9Zn14aDAup5yQ552qL5CIhV0K7qp3r/4TjoSCHgbwqYqeQt6DvSQzOLczjb+w+tqmJhv8sIRer1 Q4n1g/nIZnCK3yqcphkBZWhkujVOaMNTtmgxDcH4TArA2rSLHmtaFHOO99yyy8LAZ5Xukrb8ArgJ rHlNpvD7D5H+4iFBmCV3aNvrRhhUWLMeODgZoGceRJIcIs8wDyPSOcbyDJNJ9NRwVmPkbVXe7eEZ V7OAd2XTSGl0pKv2QK1bc9KQpbmDNY8ZbcD+JE1oDP1Warhfg2R4G/TirqBgKJoazeNBUmdW6/xw cfFG/fXlBbg5t1qRaFaUC5sWxg2AKIdDijod/gXuj/j+CCRvQN9r5P3Z+mAXPlvCAyYxuzK3B7To bDQ8hPIt+nUTOZtTH01h5opnAcnV4CpygLJcJR9AIVpGLTf5WTXtrJU+G4nGkthAfQH8uPX/2n6t 1KLmCxYdeDSfra0vKUAZ8/lqGzbDoXfYwFsYyBfVoFyA4g6DYcBTBh5pQSZv/mKWTRkaQaDQrtFQ EWsoOoqd7kyL232e9zeGo1Bj6E7Td1OZRRsd93a/PDVIXRqE7DJGA2eUU5HIFz4qgW4txjVdBbTy AegCP/D7rT5nTNfW/otFxZ7tUePnDk2+DS7id9U7hQYFnli4HYiaa1Z/IF2gyLwdHSQ9n1lHUnvY 3k+S7l2WyiNwUUN0gN2wBvwYVKtFOmAbtfNYA07gfruZ0QMselYkDOkr1Y0JEXiTgBCHCfB/AFBL AwQUAAAACADpXsZCBEi6f0U0AAAEowAALAAAAEVyaWNzc29uX2gyNjRfdnNfdnA4X2NvbXBhcmlz b24vZ3Zpel9hcGkucHljzFvNbxxHdq+eIYciRYkS9UHJ9nprGXtnuBkOJdlSDK7trKyPXS1s2R7K VlaKwDSna8gmm92jrh5RlMVFEBmLBRZwrrlkD/kDckoOuQRIgCBAgOSWQ4AguQRBTrkktxyS93tV 1d3zQUnOSSNNT3V9vHr13qv3VcXqfx2b+f2/u/V5R9jPJH1/RF/9V/QIhLhHT0/c80RQEUFVRBVx r+LKVXGv6soT4t6EK0+Ke5Ni/4R7rYl7NXE3/o6YUFNiZ0akO8LzPNt4BI2xJ37Hvk+Le9MimBBq RnRp0knxtRDPhPjZvaMiqAlVE9uz3DCVNxwTwRGhjnPtdF47B2hrjRks5YknxLUkfqTSTMvP9rOt JJaBn/kyjLPElLpJKn+cJJuRkl+Guu9H4RM/C6nf1c9uyU4UqjjTrZmZO1uhllG4kfrpvuz4sdxQ sq9VIAlOJ1V+pqQvNxlO61EZTus6zXLH34jQn3829mcGemi50Q+jTNKc2ZY6FJmW/LSf9foZMN71 aT1+qmTq7838dO3T202Jp0yV7hFARa/+I3+tk4a9rCmvrX3ZlH4cyJ/c+eRjmQEJWtGaUnIry3qr KyudJFAti3wn2V3xe6FeGcBxhekUJJ3+LhHE4GTwnTkU3xn9m8SDq7thJu+qMNYZPZryk1Bv+XJN RdkTlQLPTrIhP/L1ThiH/0uf29k8jcqJduNxR/UAMpdTYqn4CMw9Tg8lWEIFZLO91kCbvkiPO0TI TRWr1I+kciBksrGtOhlhnSZ7xMF9mU/TalRpVHaEHuvrsb+r1tezGX7ZTYJ+hNcpfiUSrK83gEfx 0Af0WOnsbwZp+EitdFa+0CrVK2rb7+gsXfmE5rGE00Tq3Z6fhpq4tGIop2+mNN9eku582k8/8/GS Yfij3nvrj/T61qUr71L58TqY1Fkvxq9sPgqfrBOrWr39tsNFT9Cj5tW87HSZihCOGzEgpKN0lEN0 pF1Pe8lscBQmQFmQR/82PVjOlIFFlPQzuUWiRcvAdlIrWbirVlBCwRJcy06SplSI9lsdz05do+81 N30mxLYntiviKSsd2vykCLKqeOZVPEJqrYHet5kjWtH6/SxJdQYwTX6uZrNYRKz7qVr3dScMGxWq aGNYG4xrgC4ZHttEuuyoXYilieU7SWBGjIYivOlHWrE48SCtou4rxW8s4AJQwQqFN0cc72DF+E47 yoLORNmnniAiEX2fVUT6DV63mck79Po5mIyaKj8noDvPoTTJ7zV+TvHziOjWxNk1YszL9rczTYoz 3SkaGcclbKYZm7+Eah8PrlulIUX/Ge7/72Nm2SRtTwwlCSDhoU7bx9DwzBNrLDng/u2Q2bYgeEuo xttBc/D/Usia47VDO3Cf/6harTPQZ6mBKpbNUEPN+XFHsUS5bcDitht20kSrThIHLFL7yk9Z1HZJ HreyKvff56atpJ9mNR4T9wlEjSUwH8lgWZ4BGyB0v6fSNldhuYHq+v0oM1vgGGqxuuSVEmCQ+jJQ OQeEvHlvrlr1litVr0Hlee9N+p6tNLC4NpBv81pAJBZ9Hv7qaWFwYFnYXUlauDI9mWE35np4wNli 5fuBN6R8X+P/pIIr0Lxq0mphkmdyl/Bada9T/DrhXo/w66R7nebXGvtLvB3uzQh1FB6T7TBrnSa4 UTNcOM5TH0V/eFFUnuUy+XPHuMNJEbwuguNcOc8d3hDBHKN6il+/I4IT/HqaX98UAQ2ZF1+Tv3iG a74rglPc4Sy/ShGc5tcFfv2eCM7w6zl+XWT8qeeC+Jq8zPNc+RsioNbzDPM1WKa3QMY/Iam4m/o9 zS4UO3ZwzIzrh6J/uJNXOAEzM1JeM85cBn/PmK+m7CW9foRacmX2wmyLJ2hiqph8wSgiV4hsXZfn vpP8dK3VahEkkqCtJNCYPVVZP40JCZLEMN6k9x65aoUn1S3QDo0XaJw8GShNTtyGChi3nyV99j07 ESkPiYmNC5smuzzI+TeYkJxTQrdJvmUm9824OMnMUAIVxkH4KAyIFLKjokg3JflE9CQvr5NE/d1Y t3g6soOJG0uuUNjd55nYiZS6s6V2fYKme6oTdkNyhy36ncjXMPukDtN+h6z1AP5+EMhY7RnsmXYp AYc7SzhIWjZxj3RbS151S6QRxtf2Y0YeWjYLiSVBwT6529cZ5gTt0BeIGBRlj9Cx2CXSWfrG0gBW qUpS49QoRwO3nMR43rxq40ozXcyy94G21EmaEWsJnoFC3qUB0pJwRq1OtnW2D4mY3yHfKIBMWIST NNwMYz8iQDzduhEB48D2nGJqyesWoJu7BFJ3VAyQzQIJgnZRPvKjviK+3iRy+zIIO4BJ8UxT7ikD AwjsqH3N3j4DZArdccKJlefsH8AMwUgnIgMXkYCQIBCVdCG9ckulatWBKgsPECbahPFzZKeuRyck UCViACoJfGpBaan8zpajdV+DvCRS/V6EbUpDG2Fwn/bvfk/RT+RvqIh+OyQ+ye56L03ImtIa9IMH D5YGuccUZOJgLOEO2ectbcFgOSx2hBkocOu6DLsSmyffIkZ+zGSymMwAIzFUu71sv8SdEQDMklEO gPPlYYRkFGrSAETJzCeJJyKU91ouGA4IVgUSkRYgEmJr5dBCVAJtQCQJugHyluYimWlyG4FTkYKR ZVVS6mKrzSZVj6hIuoeEZUPl/PeZAo5t5bUxXi35E5IiEgYQ6bG/a7g5uOg9CJoTY2gK7RjfzIXX MJFbgDJr373Ern2VBkn5VaPu15uyHvd3N1RaX1qV9xv1jXJNUzbqHVQY9teXHhwY8Sa43Ug9DjfC KCQ+hjbhQOsFEWKwTbNCpv2OuD9gvHb9OLQ2htpSHsOKjpC0eQuzG/q8PFKRu/4OASIboo1A8jAS p03aFCwhV0nJOkNYqGyzGXIRdYxWOtyMIbB5z7oeJ2VNmK7I7wDIEJ9y8TEmElbF2klaIOQCMgNt FRoOWnmwmz5LejIisYgAlhwlTp0Ycu6FBGkD+ZWNEALGJoz2ut+lvc+kjJJkB2bDGM4oSvaAn5UR ItKWqUC2YuyayNJ2ttAjx5dBkYmmTc8jMYb11zVrGHxdCI9Z9X1C/CJ2W3SJn+88YFEamY5lyR+W pY0BWeKRV3s90uMwbw15/z6Brj+pP2jK+wS+vseld6mUcOkylXbqDx7IJR56x+CLoi/lBv28v7y8 jEWRtPj55pdhoFdYb2nue1HKJ1y4JOUeF94lc8aFy1LuYP3XSwqm68xk0+472nNmX5l6Q8nR7QYe WjLKr0C1VSaeI9vBYXT7/+3KYVKCxwQLk15yNH1n1RCTyHownoAdR6BLjkbvMHX2hojyHEIM6J4w Q05hSGOXKWMJ81VBmINvQZiviC6reQU1dfBqqXLwPKKYkZfckCf1AyaPqX7XVe85IN+CUNSGAAlf RHOcoviSHhS2bwsbs1N53RObXLleEaEpVMXTKmcspkX6PsqmMqbWikjbDGESZYLgxZxCWuPoV/+c ZrtFzl4Il1+VggNWhuw4uxfrj4BTjYQJC/u0xP1ZoUqJlGnhoQxmQ7vOroax8d1dinQYuFXt0rlj BvTVdNPanrEcvjoAp1nScqXQwyWGc7fLwhvzIa3LnLteTEJBL3lQ5BPLNZ6kgGMV5yEfq0qQNCVF YKhLzpFzGFi7tEC6w0EchgoTlTxk1bP8MgtsWUhGaD+1vGrJW125SaE/bbcumYySLTMWCa/cblia e7UDeBVWlh2VDcWOKOkt2CoG4/zWeJRPo8v8ttJSWqxBkoKTAYAufGI6w18wkQaJKoShtKWXHJVG 3Noyya6W9Q9vBxuhktPgSuRtHM66zQSua1z2MchDG/FurSk3ByeHQzML6mz58SZ5JVgYisAC2rI1 shS7edp+qFW+ffKAMD87WDU9ArjSuQpwKrnsZwZhwL42OwTNw/E0vq3pi0Cb/al+r0cxFM0yIKa3 OXednaXHeDHPTlHTeo70+rq1ANmJoXpgnZ2kyhEycDbwNmkCTjt+nPhGBFBr8n8YNSKtLpnot6V4 xRJpyPH9obDZVrEw703Tv1n6Z9PcwHzK2RBdMWluznMiS/zXIuOTBLIGwWmxMyX0j0s1FU58/54d QqbiPA4aKmIWdZyBziZt37P0/QMPdsZ2nqDONaSe8TyCg8cFGqn/mAdOimza9RocPCO2j3JLTZx/ yjgeVGCuup7t/92FNTOWxhyweQtOiZ0jIv0XlNee8rEn0P5vkR2z/bj2CNeueHb9x0U2J0hwuryi 9A0Po4HbNKymw+iCh6EzPDRwQ0/yiNtmhCPA9jzygZgs/h9Y6GCWB/2tG3RKbJ/icb/2UD7NlvgM P8/yc0E8Q3o+732ae/9ZjtexMl5/xFMc5yl+UBmewqugfI7Bnufna/x8fWiKc9x7oeKmmCtPcZmn OMFTrI9M8XE+6GR5EB8CBfMYaquIO2uNMxC+v6nhhFmlHQV3D8FVlHt5uVZErkA9pvjdagd4fy47 ZDTYrZg2CWlkuaUi2tQ2dzjGN2DQq2y7zCx7WyHFVRTi9CmUNOYKOc/c+HOvdaBAet/4CotGsy82 5aJxEFHaSBKKq2IUSSco94s83CKpuzG6cBFtSTfw9xedHuY0Z47rVQowMrXr3BMbxzI1/B60Vxpy qjUpmeYCXTKmjKa20BC2mGykWyFGfhGH0CQ2rv3izs3l98zpJF6ROVHEGU3WzZnDW908FUQGyfoL YVaiYBgPOlXO04Jaz9cm5bJsMLJNq++BEFcsvbhLc9RCulFFBmNojAkoXLbpsBySdO7MQFxh/JCR 7pzIYrtMwboj0J0irzk6Ah5Q0nfJqH1HloGlgXgdztPig8yrhG1y2YWh/m7aT80ow+It/xHi/bgf RcvcKzD5BHbAhulCpFhB2pqRdbMWKJMXUcKWMTHrVoMIsINi9p0MN2NyzvQhZDMXChgK+YKdHecl QYzGcsD4mqOAINLm9DxPfuL4AH4gsRfFayTbFpw9TijQRYKCNAbvJ8vi0h4CJpw2JIHBybtBVQUm /WtzI87F8eN9A6d8swXrsz7gMpiHJHFIo6irv6NYh1FzQy4xtt1cR1hN4vSTktucl8f0cpG2JNcv unXcsFmaYmMZdfolejXArmausJbsQYoRqLEDGpep++W3FpcK5VaMyhvHDr144cK4qRapfnHsgAsl tVn056sDL+uXFnqc3VGwYMAHNRlAel1OVSchtYfxz/FL9/x9VjZ5grQsEXV/o1MvstcuO2A4EcKv CnHCytd27qZJvrd5SIGl3X9GLt7WLXN2Dtfx5qjGciIInWVwwQh4dXxUbcnHR9wGHb2Yz85Yvq2h EuPCfppu5lDcGAgcpvaz7vJ7bZzw84WS5wFgs4Zj2dx+vXAIerbnAPytlwFOvTW8+i/iIiiw3W9z XqIgduMNerT5BgGWwYaJLwNEyjrotHv5eg/X0opNP0TYfK/AGMk7/A7vHzsDb+aGABXamIG7lmS3 /T0hzNUWcIBBk7vCFREtjufoRgkxE1zqGyPLNCevnYpMDCZ3G7FFG3e22lhyG+f57dN4wD9qI+4x l28AksWCr0oUdp6x3tbrpg3TZab8SkUkuFT2p0CFeVGfq85736do5JQn6bngnfXmKohPJug7Q6Vz VDpFv3PeROUs/c57b9B3onJqpDxRqXnHqqOXd/5VcE4sEBwHnOCcFsU3uA5TwbUa9rrt3Rkb0/gI Xsw9GnOHhiKLc+Ov5UzbyzyTL93fzlRzl3k+EAU25nLOPyBIGQ+OL/PAWT86cDeH5ZWFDpbeXNJ5 HW9qD9ry8Is6bz63U3FZZ35cv6XGLCQTO4A3npHlE2JUlgfFmMWd94C5/sY7mQXWXodrvyderTg6 w8pu6I7fU6SajTdxzLPKWlQgrvMkuNPejFfjf0dL5Zq5iFPpuBt72MAsml8LEw0Pi6awoolnlZ8T LhL9YRFUu641E3BygGurprhqt+hL0vdsIB6dhqzn8gO1dVvz/T4+NV0qTAHf/x3mMesrVlBNPK7g cUlY3URePrHwtwCMbxy9cszEbrmTGH1fBxfP5lxEYmSOOEfqhr4nDM9AnTxJ8hce80yfQSoj4D1o Q9uccVUYhC5rFn2Tu1XGpkJKA8CuAK9dTxCBqPXxBywaVSGvP7goDrySluDuOmHIEwzZK0F+mOD/ 3XCCx0+K86RqrrjilLgSHEEW4wopiWBGXDmoQIAMasFRsTMh0m+QVKDyeVJcz/hkgPq/X/SaLfWa FefRPlVur3L7rzyzPno9TxQHxl8i2xEcs7RAwwA9bB3gzZThHWd4v+TBc5beD3/pPfyV9/AbL3YI ng/OIkOV/jn3O+NqS+ArJOjs1/w96RtOGZYyDaNn5a2XzyUMnDCMPXe3QUkv0TosJeBzX70eBnVX buCluTT4Kusw8fXxtfTLxwMvam7Kr+qlnOdFHEDZd3IULtYPzPih7EP5UM6l/4tgHrdcVmUY2Hsb 5jKIO6rGZyTJaiLzcvx/q2svfcDJLTIJ6mHft6cPYdAa7M9eYKm7ja/IUeaQi2JVe9VkaNz42LEE aOzFkRxqKWLI4X+LCGWMZAxGKVhr+0ZzME/UH/Z+9yiINBexzOr0D0isS/lwqdI0SVfdQkoNvEj9 w0O6O99bEZtVHrO6+wgUdxCeiDrYgb71AiDulpAFo5GqSVOc/rgbC0nXOfM2kGFnPjBGBPLQrsN+ XMBDognKmD1+ffcFk4+y2U0Gtj4fFbhR+vvjJ8gXRVHFJu2FD+W7bXRtvy2cWWQDyX9C0BgPY4Sd 9bd1nQ83dCkWKwVypfiO/ywBoZEu34vWA0FYA2/sXRuLjYu07RYeSzk5ITDtH+GBGNX8zQYim+FT DdCHQzw0rIN2r5QlPyEQjGFPIVIzx0BXYNE/BIILZMsr5xBcVOa92YmT5IXVKgvece+oN0U2ft47 Td/j9D1l6+cp3Jjypr0qtbBEcjQB8ufRxMXyGQlctKq19OlHsPrbzswf8F8DPOW/D3g/4EMKMm7v 088mPDc2bmS8YRa34a/h0OPIqItgZuI7/vqfcJx/UBWPP0Tl9QdXxMGEm3NidM5aPmcVgYU91H/4 C3GXKvQ/8qRThftClQgs9H9yw5GSX3PUGeJpsUMjP7dnFtuz8A7IVJ83lAAN/tm1Hcvbqq7h6GCD 9TcE2uy6fo5zF3SaQyfqcP3BtvjdijiYFAc1pkVNWHi/9uzCJ/nspyYWzPrjMyJvoNpuZZQus+Pp su2BLms5D4vlPQcCcxNDTgwuLmBfjQhGaHkLaw2cHep/O5m7HfkR78DFQ3vrmM81nOtBdsdamNJQ 3NBc1v2N3ZBzRPaYe8Dd4Bu+BRibf4IVY2Ab++WThNxcmSP2lvMAjKmPaKC7otUDEkF+s/klr1wM LLJbvk5QPnPBHo/KFnbow87H825pSDIZyV5+qYEM71b5iP4On1H3AMQCCFNalbks567MWrtQ9gMH MfrCuhepor6aFB/fGdDm8AV3FvuxuXM39iTnY0vHofte5Vu2+ZV2M48/cCvT+l8W2iG+Fy8yv65K htyQeRf2Y9B7c2gtE5BV62jlpxzuWqvpgGspxolB6ZBO5nSMCY0z9lJC3RpaexE8zE/tcDOd4kVj CdkZGxKAgrs0cljXF5czlh2/h7icz5TfjxzeLDmAnF7kFYPm8JtD2j91eEB1Cv4jPzVZX+yC0N7+ tDtL+TqM9gtsxlwWGX90URwd2WNMA8GcSkB2VDC4tTXvyEyhIVWbfoq/GWT/Zgt3QjP2DtnPe2nX 9AYcE5MhH+OhmqZsaxzVxn3ymz92/uGDiavjJrHnJS84K3ylwiTJt1f8wdviA6iuWsiDdQ073dL4 6hEkxze/NJK3rMLd7xXnCMUV+j1qwR/qQHD8/2vvymLjus7zvXeo4a6hFsumY0fj8ULSHVGiBMgu rahwJDmWHUvKUA7bOgw7nBlKI3OdOxTJiCyKOkuDBg2ah6Io0CLpggQt0r606FP80qIvKdCHbi8B 2j4UKFAEBfoY9KH/9/3nnHvuzCUlxgJCBKHEy7uc9T/bd/7txAareyLeFSvEbNYSxXyzVUKy7p2V aKU2a5pA9p7LJLLJ5Sxr22W6D3Ts1jbaibYvUK+n6+twLx4WSJfF1VWQY0HG667RAS4a0xNJ5oFp mmpCTPtEEk+bLLrVlsY4sUiAc1DftNMFInCeKBfHuoa9fHywu9uVlC3DQqoMC34ZvHoduCDdETIL liLU7lwHvR8ITR6uGcwCcDjXnJbwwYhtEzpALe30/BjJbTV89y7F1ONq9FqqFI56ByLJQQvT2bid qs5JM1ap9lx8BL3nhzazS/FAdD6krf3jlqKjtT9iMz+kFF1jWEbrZnq0ypa7jiY2w9hv/42V9thE cc/G3UzVhOkcqDKPrWE7BxDK/dEa16C7AxCWk+N45vAp6+AZ754iF8YmHsPQ8SnaWcfHQ+CFrLKk BlBStcdUFkvfGzdvX+NWBJrjzTt3qTpeXV5o3tkwZmDcd1Tjbpu1tDGwpfNiJ5M/rbjTgTczMKnu eV3zF89LnouLDe4TN6vYgdnOsKAT5cSujQodL1ShuxAmOcdQl30Xe4BlREpaTrFaMRZ7vQLO83b/ OM39MDZktnxMxEZcBRn1MxN0idfGJouzUpS7q6tG6Vr3wmqukfC5DY9bU2yuKNkRXL0o2PDGVrPF 5qKikSpwOXFHe9UkCGM7hqVhD7kUhqc63pxsTJpVaSJFzAnWul5P9PxdW1i90A3TkhsxcqAgoK3G bEtNZtjsbqWyQYu7bkieOWPrBWKZSpmdNQjwYNe+zNjGNRtLBvaSf81Robo1nFrIRHXjwfpJkTV7 fj5+Xh6uWc51lbqeVE9yZvPKdydDFt/omMdnLHdEiC1HBVhfeiGB9WQMLxHX0hjbl39UzUa8uRI3 66m9nvLdwQ8lb1xZxpTwZ/GXn8HlU4GR6N+txrJZbSk7+pyNTcJUaWNBVjSrBm4GP1BpRW9jsslJ UWjAxpVnkTcSroBqlTcRGRJqHaRQ+We2VvWf7HKpCRVzJINDJ4xmheBWJL6BAr33FMXPA2FvrkCt mAK0Wsy7YxBOR9BzKQxA92U0fCbKR6cl5Gj0hAnRE43yLh+eCmtW4QC/5F6DNDu0EjMunii28Jh9 hr/XxSSZVFE+1EX0bviw0fG2lGAwkqKAZR/kXN2dhRztN7T6ITUflAJXOiigiyymSvpQ6OQLwuBF xn4rUTQlrSbVRwzFKqcPLZHo3OkGK3hzsSLVG3EEi2oYIT3mlwS7YQgWUs0hgkaR3N8JoYwABYUy Hq/OvWAMLYSqO7lgtB5RhL8YJe8urZeC2Tp8yVG09q7QZqbR3nMmldleFRylAcbjCcMGuFK1Rl3J UgojaKwN/gyo7aYzsctF08vOC94/ErcbGpmxfbY2XisHT+64DKuXD1h3Ndp712Qf27HXuy3E0qrm 3Qm6ZRR52rIn1a28HZh5WpUjK++47thjuyNnREShRJXTIsh8mDoppKjScuifV0iCW44CJ9FfsXYG g4VwSCZG9lr7y16L+dSYvdrBrqIb6cFhYs/6nVDtu2L6T+FQN2Ci7sxay2oh36QJfDOmoq7XP96p bhvvJake4Gs6WP149brCuOxEfn9kWl4crxPYbmmc8SQfqCRvzfmdjvnL0h1eZnJu/GT15TqtPU1f jjUtN5Fpqgao7Nt70521qy+bkVH1h3nXhsz9ZIzJpF+b3oyOzLXeM87M2X5deQGXYnC4JtxKSUrw Ajothl0w1B+6adYpAb4X2DUZJnSYPuPLwdYVnVxPJ5NrkypMmFdzED5+kAvC9aeC2ZXRru+h/V7v ke5Ov2a/GlmyxYnDIN/W1PQTEJWmFwyri5x2W34xjoHI6cXWRfGu6zsP8RFEs29f79/YJVuHJ7pZ Sxvuqlxo8sAW40wOoN05r0AnTRuP7204nhoi9JZUr6fJlbjyyXKW1O6yLvD3lVrIjzC4yslW14ih 9h5ZWauIrQ6GWdvMA48sLHIVd3IeaY5G3KHE1CVApU9S4nV/hQKgVPvc6yuyL/JGtluxkpFd+aXD Nrwxdi+4NenkMVmRihGdM+CF0xl9K6J+hY8+3z8StF6AxpOvQppGUVCkjILWXQxrjOkeAVZJgCPB 6CU85oyaOJQY6nnqcPhpqLXr82Gbbh3qVMQciv+ASp+RVRT+axaknxooUVoDZetdvLo69w6UTTLq 8F+MOuDVoWevwuag8PGKzGfrHwazWUX3yxS/HSLhoawyeQkP22zqR/UJtf27cOuTSaDTV+cuQIVk h079gE3fzwetByGoqq9GbYH18dL6g1D+ZxZRIsHjprTpf4ad31eqwdbnsUJpea/O3aLaSq+lB/RI eqGVstMbdNJGNfo16GAwukiFoR1YOZNqT3K2/99wFmUYp/0MVhaOGadxwBEdw8VC0VquT8bYnLsR 2zFOvTEKJLsqLxprlbcw0q7bcVr5JAZr5dO4BbyMMRAds2IPTkWMpfq2JLgMezgn+ldUYhw5qf1B 2U/Nm/QEktgtF/UzbMo6gWAqUdsDbrgwiSiDAflWsG9R6Ev2BPgNynm4ictncPmcXGg0oZgYBJX5 9D7YB2oyE3PWMUybJVnC6o0t8g6ImOVVBQ5XiEaSOIdqakIV38HUhAYMck+EhdyT4Wg4EvZET4an wVvIDYfyVt4dxVvlN0Sl6KQ8Pcc3Q7kT0Qm5eyI8kXgLgJYgaBB/MuTeMB62HAVB3V8NutTUP2ff UNlNZjOnr14P7fwWQkN+9F7eqE9hfPLtottr/pXCoe9CE6tNOJ/ozf9+8BsBjWwiJLNo9LlWbbi+ RBu/NWLmwST3kVCj2dwHmftImCSpc4YXRKflHNyvr+UxK3hZ9ic6dVDC/woV+mXW/TI13DA3KNKj G4EPwnCG3Tj+Z6HurRYcMlusj+FK88MV6SYtxTlnrG9EcDcXttWv4PzCdgaAsZ98/aeZ1G6iW4tH 9tqEGPBfuLDtq3AnPymHPqpWVG+2Gm7+YWTZODivinzhgnSlB6gZ18CR9xU+rFN2xYKN+nRXPGNd ygGLmpTIvX2DaNIwB5TDbFnYxXHJZ8K6YuxMbrwrvXKxJBF2MEWWJrLS7k7kvfESok+Vyl7UclHf nk+9nbMpErbKDixbn4YG4Gwb6qVXW62qGqFvWEQ7bgucKm+27lkC3FT32OgA0k3lwfSFZlKNyhVF KD0mBVBdKZRClV7UPjO0E6eEqLwbWGYypnHysq+ldcbVO5By4jmzTnemzdkIGxvwiE9gBGH+33ob M8HVuStUGo24dbKIBXure6EZ+8rSSp5lajgJeNMTtHpxnVnvDWYTXsFVzPLLa8lCi4GpRJyU/cyy DtuFbSUldhcs7lktK95CVmqU3NXYLadJ8u+dRpubNMuambI353WR6VPCzS9LN9YVZ3ltXl3qqWP1 kQDLF/D9PEo1j2IckmVILWulUFeW194Q8v0xViTUIZCV5YysOH1hZcFSpVINzE4ZhMt6RZfVXOSz JA+JUvsNS07sLBUaYN332GAgqp0kSeYKWkdXcPJu7waHgn4o7LxZGgjpfi0yICw4ng97IxgXPhee IjPsuPwdk9+L0Uiu0MdtCMiEJLgN+TAiQ1fWMHT2yLrGedXwy+4B549YqCzj4/NRsH6aWtXssV6o U14oqGBHAcJeo7J13njCP7WrMFcG1e8B2tZpUrvj9Kupsi4xT70iAbHGf9NsSoidv8Ex3Md8egGf k7h55Ezc/EHnu3zGu5DvFns0I/u2NxhtfZtJ0y53p68jVq/Gymms9W/j/yyC04C3rVXr86uwNReq Wv89s7hrRd4ItSK49ge7A8FWX+jV80f8MGjoudNPL0tfD+WGxdAW+l64/vXQbHwGAvPNp4MkMURF /SG47wfSqUUCpHaHWdIh4p1BwpZiBPV1rarJY1jt8CQwsujFVspQxKrsY083BOM75JR6NaKvhmkF TUpJ2Xvp9icrCQlrG0ICzu4MBK01hj+ebgTuJx3x10L5D+LPjJ9EP/7HI3AdIHsPDyspx4jKmG/N FOnJxuoyDujilzgl2dS4VWfgtOjikBlqhPetjRXLcdcTUHg0TaIr72T3ifQARZks3t5ea9bok9ex ZuuNhY078L+mbK6VpSzQlq1i7fGb+HrTutdh4oa/6ko1Zr386M99mVJYWEa1wix6Zq/bSjtGlMpM 5zkt7g0c1T32qtNhN6lmc6B8f982oe1i4i+4SmYz1UuuX028hCOL7AQlhMJOuKvdrK74rGtTr25k xp8bq23TvohKrh1LkVUE6C7YCXsP73XNRaaj3uFtlh8ddncX/pZyU6t0SgSGqr8a7OEvao+eXVYf G9Kxy65Lx9l9moDQ65eJl79uCWgSXdkAtg5G8du4/01AfEl6JZpsqvgJMqP3P+1pfOK1hCaINVmt 168o6TwHXFW97BfY89Gll/0Ce268anrJCg0h1fjUua5PcaN9pbG0BM8257LL5YWY4n94bigXH5QW V1dL01K6aqu0u1+s8+Viu7XR8IPocQlZ4X9ey5FRCS+EFOKCBLrwwr6hJN9FeOaZeK30qPuFvRhQ HLrba2YGIqspPhtAAaQFhzCP2jvo6uLFGIXku0ReOP5ijO9P6/ekdV+My0X9lc/KHAJCIpeZ4EpT 09B+cnUTJx5xSbILvFiXl22gMjWOBfZCULVW/XiSIojIVOq2BExPN0RkiT21V2Bk+6z7KNlmFewG D9HhASqV5wLLHPs5W7nKJwLD1rKMhUaitFBZwgUbMoXXBNU4qkrTdOJjzAcEpqkVo/I+Al3GZT4w CBu7U3D1qMtzL6bvGyoTkZVPe9/aGt/cU+4adXek2vO1tcPETTMuI9Txx58DgYNLGoz1R0Ph82E5 NxD2y17m2dyoXGE8ejJ8Jjwq9xPybjwalad8+HEeLgVHIHkJfSJ8Tv6+QPcgz6lUEPtYZ2f67yH3 rLv0SbNLb5q7dAQDfH0EjGQBu7vErnDIICBxxgL0UGF8PwAecCyg+bRhpAnJvVCnvFDyx8D4XyGM H6C16WCwdU5Zb+MMO8gTpnqtkSXB6KhAaOvJIVz/msBk+smE8xu6vDwl2BRpDQdbP2TWvQ79/oDo 92iwW2CIkWDru5rbnyA3SWT3GGHqUXLlroRywwyH6MH6Sqgg3Ly1pRlQQHyM9ZXIx8B3AybeCXdG WP6+xFQXbPdj5LkrYNdK/CjYK2Q61KwgXwTL2wqPJF//Q74ese+HlRDH6XNbAPjx4MlTxiz0w9x+ aHbFO2swA9b68PFn+O2nBr/t3eoaII2siuMojblvJr4lWd7G5hIOcplw8OvS3fby0uVLC6v17cuX NIcF1vsTpanSZVf8SxK7WpcQLfm9e7l66axccbfg7mp6dxZBzmpwLzozSKihCdUvT0nQOu9KXyi5 +/N6h6S6owCRJLE2k/uMSPKUylieUUUJpRU+y9o/XuASw//R/mR9Mc4uCKGJR2qGS8gZH+NnxuAn 3sWDfOtCm+e7+nzXPtf1uX6ZwEoBzjIu5wKDNW54DrwSnEDmGRmUd5rqpYuOr7j031ttrmTChNfl Mo4VTGX2a7gAELQRhDWfbzekz8JjxUiQQAf3EtGgh5C8GdI3yQts/kEWGaLECKm4qTdEIJV1ZD3k ZYb5IvUCbUA0xJzJLCQwwauNlQ1qFK8pzxVne2mIV20IRkIShwqqoMVur74pxToijci+GTxtPZHh LD1CFqoV94fPhieifCTwJBqWN88IFClEL0djAlZORDz0k1xEkMwpM/x9GJhjRpWRqII4rPmhEWrt HvFgyS0LOI4oLMlztYwUlrxiYUneD3XKC6VOHBB2jrCkFzwrQRB3AgUKzzIs+XpQmBgVOFAnZxFR vkq53Nbx0HDlDOoIDUtOIAZQx0Cw9W+a2L9adDVIPmAfUcfpEHypvEMdp0PDhtO3Nu+8oo5B6zJj 0HLifiv0gtSHVboZCli5p5LTowhr/Ey40hNBfLcr1GBGqH8JOkJlhJhVoilfLVz/HjGautmYIbiP f31fFIKTj9PAwxyhLKuN+uwjM0C9Ri80atUNYydiHEyUavH9UlFPAAZ7bcwedsu0rOtplWEsbafP coN73JS+18+gz08J9NFA7hziTl8d7gOiorALjfZmo6F0TqnudbG/ku7apSlnGjQTSDmMBCMkWAeN 1Zzt/lR57Atj5fP28UIZ5pBjY48XSRhXS0vNZWjWJOu255nXreAd3qYSI50b444FUX+Ip6iRwCxl tRlS6/pN7nTdA1FAfJ9rCrnmrQ6wwOD6ZXWTzIVMdECVnNdt+DuNtvqlJfrowAsojWt5XXrj+/ML G7C4q3wtMNwFru1cqytfxOVLuGBhPlRLMVrt9uqV+P5VrMQs1ceGwifMCtwfjue48oZ25T0ZvhS9 FD0fHkv02p2aMGLvBOaApx3qDcKDZxTeU3Vf+mDSSd/o/F6XHmEtW6o4yUcFANWFM4a+jfoZ471E Zp+6Qtbt4jszRfTbpfTY8lLALD91UWagdlte4IRMOG8wRwWUDQu5uhDbAeyrqO6pcdsxg19tLDXu UEghY58k7J6nssJkTwepOncUXGojlWHd9psqKjxFBWOsPxmMHFpKjk9fU13038blFVwwGDz99LXA 9PBD1UMH2ENvx/fZ5Ds5M28Ew09pFxwJvAPmL0dqDVQgsDvbwW+yZ4sR2J3ai9/kQu3kLLC7RGDX Qyx2JNhaVyzWBBZrElgSPIX8vWgfI/66xxx/L+72uvA9wWjrb/2nHTpZuwQZ5xHDxSIYuhvMIue+ YOsskV2Pw4kfD53Q1vDCfqBl+yerlU8hKvg7ObomjZiflsUIZVVuCnpdC+UGQtYvG6GsekVtfRjK 1I1geYqdL0Jo22+Ftn30ffq7Ib73yfcCIah73hmmb1bD6NIoehzN9xlkUINItde/H64MByYnzcUw 84aVDD3hLL4OArdf3D0KrNj6PwDQnaOObn2McFQj/Hcw21QV2mFphz6IjS/uFoyMujUdGZRccLEL MjGhP8U/8Ccm5/Ys3mgqFpLR7B+/gue3Zm7eePik4Z/G9QgozQGybJTko7RlJzO1CaTA4fVFz6VO dmod5bBnopkJ5ycGwsb30BVLWyAkfukIw7bt4RryQu8qjXhNZiZfkKP8hnO4FOVCJv8a8Qlv76tS GC6LFJlQUsLnGjkNUrm48osB4Ay1fjKYFB7UqAUpvPGyzZYdrmMC9pgDVkYhNVR7Yzw069aEGO8Z BmwIhFHEATmPoibwHPj+VZeaecUkTDTjmH91BQ+Hbvqf1ya8uXDva5j+oewWDKtYI0+logK9ZD4R HsvlKcgYDl8Kh8J+eX8sLIXwqnlSMAxsH/DtmKCYfnjORqP2BJ49KfGiqh9xFYD6XQDUooDmA866 90JjEWF0797I+yDGGsJ4WhobxtSIeh+JJLrWcWL6HhogmFiyUjUmTKrjuORcFSjpmdxnfXlk8fVb 1/fIHA4DdVtm5gyz+7Ke7u6uxg5vpGScygKWvzyQOJYCqxcCnZNWrVRftxW6e2DmQgvddU9y6Gve porWYwKD7y9Y9StRLjYm75Tt3DA5OYliLW8Lle6YfSlqEeNVugqJQNpkFjfaN1dgnXBFJsSFau39 8XqruskMnczZqVm6T+MTxQduXoNwmDupRxIPzy9vz6N7z1vLqXOTFz3p9vI2g00iq3Gk6r7tHmC5 +RmXIePncHAZ9l7guIJ5ndyzsvPUvVKTitOOcUOu+GOpwhxMYIOTi2M4CmrWp6HmQo8kvKO7TavW kuHNBxEWXIQFG8EozXRFYPiaC1/rzGAuiaD28O89qE2/9+D+9NRuWa6lL5T49/zu3G65WJt+gE8X yovTkN9oiE39C1UXCeSltzbNAqQd0j1e3op3pAV3ZVSRIMfim4GvGuwBhcvBIduuKW8fPfdvsFbj MXgJqgf0V545FX5mo9HapsKIwWg10KHXX5jnAnp2UY7CxXZg1FexodKdm1ugZR91UeC8bFUuylZN NndYzPM8roYbLWwPjnAZzxkf0tCOnaFHch4hPWsXXo+3zDW4ZUqXWoWdA9RqfEbHdrVYW2oSMD9k TU/SWzXJ+NExXP0QOpi1oTJW9nXSUHMzs4TFCa1VHIuYWFOYA4SZHpZH4zrJHCDQho3dkvQe2JJ4 PHYWLb10YkWVGNaS2fM5hWQPshky86MUvEoHTZhLcQiwdqTEhW7W3PyocVuN9Xm4EE5zcB2J4aJY 2loaotVs3E+oJdHg6SdJRcPPq3CgiyPs0jPfMxP1JjWX/F4rgN9RkumfPa/WaJo0ZQnoBmccVpZw OtVr/3DpOT1dod1KvGR2j2xpb5XwoYHpm3C/tNe6YVcH41ECWzLl3TWXmu3tZM14tKlg/IFHrDHp lbEEG5seE4wE91hCvut1PI7RgWC1vRHL0823U571xtiD4cPNLFOC+ebKdoHAwy7UGBkDCEOn63cr nzbDUrFv18Cyys1Va7K00apx6+lBcP1JD9dPVet34PVFCMNTuFM6zjEmfqkcN2emumTSsqa8Y22o mLb6vnqgYr3pOelF1Sf0FhIuGuXArCHJkqIeqjo423nNCPvLEd6mO7vKu+1L6VOHb/nBBju94f8h liHUJng2F/bK9u9EOBBhQaKcgsJjVNsJj3HcUjMwtuStSXOG0hcDsx+sK+dNBZcSaIX25Pfobb/e Y1ag9yXmHDQU6jz4ALw2zzZcg3NN+iCypz3/hX3Ps48+4JEChtenzPQBG4D8L0Qc5koWRTPIAqw5 PU75Hyzfzy6J7nuB3/+H3/MZ3/Ws5AJ5jL3ed1TkWGBCmYrUj8v+9wQI9q2elFxWXey5OSYlKPUm VDuYPE8c61sZa+aadxzB+lZn7HEjHRA0rluKJpztLzZXmCQTIxjucsYBV9C0+UYq6REsaWUtsxM6 pWCttMd/HqC6Orqvt219LJYuyU0p2ahwW7G+VbYe+5nAUuM+Nkk2D6Y0nu7kxk9JCSycUllFDfYd BNt4BX0L+w4qISWtUMJbtx/b8f0zOPd2qaTHvbKJbGFMPROLfn2LJnDk9oqsrQVzvx8DD7j9UiYd vHMMNLl90MEBU5Im6F7YUx2Pq3qyAL95+/at4qeu3Zatone2tLcEMGPTWUtCjqlpypmmXpP783p/ XlaiEk8bUCtNczCysQ7207qvhy/Hq4lPclMsukbiGbx14yrK2ha74eHDP/PT1Ze4i1xZLTa2BBkk vTPec6faAVEs6lFo7JDU3mTXVB+6jbqZHK2RFCo9hTgH8vYAI23TGti2WDOxvsb4BaNWJrq5k5AD yVwHm3ce6fLZcJ3yH2XvVbAw3FArVsos1wTGqIUsLpPnKIFeXTtUpw5Rhn4JPIKttdblszJBxxHX OXKvX6v8IUppkEZ8Tv5+VpFGEejB0pMniGin76KpVnqjXaGwHhJ+26hvKlQ4wG6v8m2Q+Y8C687j O0gSyzImqcpvoqjMxc5KTHpMMh9LOsE0T6jqKucN9aBBdvyfBZYJz1z+FJev4EJ56DfkwgOuOiER Kirdigxy+UtbARbxMLW3EZJaip5Eg0PAEIxCn64UPhXm5N+x6Kmwn1zx4wKERpJ/US68kVTnUS4w Z6mgL1U4RsitoPgDghDCRIDSZk0XcRWAwEyDGhZ0vapeRUFV4/dJ/WNWZnH5ZVxKuMB9ER2FqCRl M+hqNcW13wpsm/5l0FXcn3wD0eXsmyjKObnkr+WjwunCfOHpQqFwORcWfqdwpL+nf2SoMPR0/4Wh ycJs4ReOv1oYKbxSeLk/HHpJRUTsiRSHzFc3hKyt+fnKFj58FReME1W14WBBO1xfxijgySmMx/Mv GoAINEunfMhNrjoqEIx7BG4FdNfIsh86irLrXFJ9vcujKBL0lPNRnmcz419Ouvaw/A7lTh0Z/dj/ A1BLAwQUAAAACAAihXRClHPbgJgQAABgNQAANQAAAEVyaWNzc29uX2gyNjRfdnNfdnA4X2NvbXBh cmlzb24vbWV0cmljc190ZW1wbGF0ZS5odG1s3Rtrb9s48rsB/wfWi5ycDeVnnIedBNhtt+gB7e7i WuzhUBSBLNE2W1lSJcpJzuv/fjN8SJQsu+k9vlzaRhI5M5w3Zyj15sWr315++Mfvv5CVWId37dYN XknoRcvbDos6coR5AV7XTHjEX3lpxsRtJxcL90rOCy5CdvcyXide6gm+YeRvLMtDkd301RTAZOIp ZEQ8Jey2I9ij6PtZJpFfuC75mS15RK4vBiRlQJu4Lsx41JvPU+r5aRw9rakXBDCZUS9JQiaolwru h4x6GQ/gdx7wmM7pnC/pPIz9L1/zWDA6j4Mn6nvRxsvgkggeR9RnkWAp9TnM++1WDNhBQAMWwj/h 8TCjwSKiAffCeAmXDQ1gRlC2hr9zFtAFZ2EATMLN0tCE2zxldBFHMBzHSH8Rp2u6GtLViK7arTFd ndPVhK4uKCoT5lfLNM4TuoI70DfllC9Sb80oXy8pjzL6ZR7Q0JsDWyFbsggeOF176Re6ZlEOv3CN yNvQeP6Z+YLGIQVZcpHkgiY0AWaSNF5KhX2laUJTQdN8/kQzmnnrhGaAg4xnay8MaZZ4cCtS/oXh JY6WNMvn8G8NKwIO8Cm8OShbzON2C1QqAipQTipW8BcEooID7yKlQtCc5iHdeCndgGVi+rhOtvM4 BZmngxnQA0vDTQLm5NES7lBpbsb/yabDweBkJ7UxR7s8bVeML1dCjVftbUzVZAOp/qqWpc5QW1ru bcCzJPTaraep9JbdXMu9ldw8qHXncRjswB5bPw7jdCpSLwJNpeA/FtOD2YYha17oeiFfRtM1D4KQ zdx15nL0tARkCT1c1V2Ds03n3M/h3w4slofbkGdACGNjGsUR24Vc8/Y0lVPgpeudVL5WogvMhF6S sam5mcmJdit1gTtfKnWHdgmMy1eEisAvvbDOtIiTGUalfgzZQuy+bmUQZYqxr9M5W4D1QcVfp94C BAO1gHyRmDrOzNxKUOU7iXKubamqy8mJmQO5I+Zq+4I3xBlHTqcpQ1W1WxtW53DuZQyRkAKoQoh4 PXUHvdEE9IMEQQJ8lo+b5TYG9EUYP0xXYA4W7XSi+SUK6mmmloBQC2oCk4fkfjocJ4/9YW9CnDcs 3DBki/zKcubQn1LIE9R5y+cslTYm78FJHPo6ZQzvINqizM1Yyhc7DEofPEBpZOGtefjUbk2dV+yz 90cuEcm7OIod+o5FYUxfxlEGnpPRNQyiadlulRahRH7wfZ8AAA9m2jNABe4DD8RqOkweZxAsXgo+ LFazdstoercaWgYZTZLH3Wpkj4xxZGyPDHHk3BoZXuPIxB65xJF268IeQ9pxxcED5nNwiV3V7cHd fXR7lRpcdL3peADICWZezI8qieoU2m5hEpXBI9OcSkxmc7CTM2QDQ1T7ywjJ1jyhtHfNEZYpD0h3 EeZwgWzGvUictlsEf4YjAsGXr8G+ZDicjJJHImLhhURqXwOthEim/T6Q6i2zPvnTDCDdrLdiafwl 7/nxuq9W72EIeeDg6f1wtFVmvB6dzGy1nBePqTTn+cmuh+Tuh1RdR/o61tdzfZ2oa7t1f6FHLvX1 Sl+v9XU4MDeGJnBjMhKPMAJnEFeekDmiHrgQtmvIqiXHwxrHQ+DYC5OVVzH3YNeL12xZDKbaWSs6 IZodrRvwtt54PD5pBDIKHJ73Li4um2HGGmY07g2aIc63D+2WhBkPD6810XTG14fXutAw51eNa+Eq 95caZnJErisNc3FErmsNc1mXq90qlTjQQFdHBBsaVV8dkaz0VS0a7HY2EITogj+C1fSGrwx+1biq hh1VYYcXDatDjBnwcRV8NGlQsQY9r4KOx8fYmGxh57bBz4eNatDgF1Xak8FhNi6roO3W5Kg+rqrg F036KICvq8CXhTbarQarDGpmOaqQYc2I1w36aLcAPssXVZureG4WUgOPasCNVjfQkMfGNfhGs2va 5zXYA3bX0BMD3W6ZNNtseA1/UaPeaHkNe1mHvepBb3CYl6sa/AHba+jrGnRpfAGeXIe2jK/tc1Qt w7o5G8yvMkySZysw/rFAR4jR9nB4a5DxtimkYX8pQc63R0MZQSbbo+GLIBfbvaCFnFwBudQgRyS6 2h4NUAS53lbDst3aAwG7HA1GCaPV2xSCEiYMjQVcYBh9rBlIG8E9aAWA0VZwmzMrQigjQC3rHrQD QGk7uAcNATDaEG5z+kSIduvSwBwyBUBpU7gHbQEw2hbu5b5cUI4pHQ6MEo/IZYzhltbA0ntrFeCm gJLN5sz0JqAw1Z3MNjzjcx5y8WRG1KY6mBWFuyIKkWiar5I68iT7MOLUVlrI0DeNarXn+p41axWg q5rmH+WREZFQEJQIZzr2kwZchVQrv2WVLQvgdivgm96aiZT7y9RLVmSLgzv8ha2Y9YiAqsHHQUKs hmpKVEtGysZrto+1GilEfRxBsG0kXi5iGzb1Ah4/cwFDynQaZMjWNq01+ExNAD/kCbZB37sCNrrk Aho8m9bKS4WXMu+ZxApEHgXQzIo4zZ6JqUGkRxHsiw+wBmMwoN2BXAwGenTu+V/wTCYKXHWqQn5Y XOKfA1xJ6ZR/V01WU/ABlNXEkqvGtHXeQdSh4MxeYPAM8nloM6XKIolISKVU0mO2mp5JPuQNKwzR X5+Bn0wXPIVG21/xMKjQMW5qE8JTwN4yjpchcyE55KCaf6pzK9lju1mcClhI0THGGwwKQXRwqbbe Urs+eCJ4nKZ8QB1hkCH0zfIAA3xgsTjkHr7vmxVEUFnjTARWTPXi1IuWkJsKEoqHfZIKsGA7RPZc SDlPz8D9YTHAPwr5pi/5kMfbfsoTYZ9vf/Y2nhrtkCz1bzvY/2fTfv/h4UGruYft/+fMS3jnDmhJ 4G8SAwCNDW140HUqpnIocYa9IVy2TgLMe0uWOdOPjrSg82l3CoxvvFQe4ot79CZCyC3EZ2UcHJSo 8cqwimYYDmI/X4OD9czNLyGTz5DT4PJGwrnDQZWq3F6QagcPdDswt5Bs3ToLHrJM3t97m6WjkLII vPmWfPykiVhAAcwdmko9wQ7MAW0z0271++T3J7GKI8gDa9ifAAsP50jK4MFnGRErBv4bwj4NYUxG BDe+rIeIJyf2ggkwc3LS7+/NwHKN45LFcgblVE9abhYyX7AAWB2oEb5GMwoU2XG0WHMmIGEp/VXU XDwpiOJRbayBJ7za0Iazh5KEPNa6HRrl4WFxQQYMlkfy/ByXghB6KaG7gHRaZAUYAD7hRsYzyPpw L2XvnpqAqxF5J7norjUJ7RPrOnYdOWMiT+7B+btmbZQelo7YA9EBUgmN3ntfivIS4bqIgT+FKy+Z 8eKfn/4adDtWIdI5PZXSE1vrx1b6gADfXsKiVi5xVGP2pJJaGi3LXoZelv3qrRmGzNas7Khs+bf4 wZkSZx7mzMWMTOTBvLrFpGwPqv3BoQUJyZ6mYOEdgI6D4IOF0Jxav03GxIBNaz+9l3Qs1BVW1x+a mbY3DxtFDr9kYYjwlV3smFIMQgVmp82Idonl2xdpEcfDRPIGymXAEGnOdjI8+IJ0lReQFxDupyQA wSETqTFNCmLplm28sKtC48z5qMLsk3Na+uQxd3wFQa9cEiNVES3T34fnpD9MfuSBQ/72iCxa44Wm UqQIzI1KooUOEEhXtaTt6BP0AukY27/m6zlLX0vQIpi2i9STsfCKL7nIpuQcClR5QjHtkGDekTsc ISzM2H+61NG1TtRKSgmQ3gstmFReSRY9DFxtaardQjHayA7bQI7IelBBvgVdM+g2uxYxauKjdMjn /CicnyWdN14UhCxVLHzNWfoks8p+lrXnVF6xNiPFE6a111r84A8PkkzXhC8FlzbBoPLp5yzG7UG6 s9N1yJnc5o1DfzSIn2DCOXUUf+XO9TwnL1eC9XsXpzrSutZ+J6ONFOFWTlgLSrhvLPgHwHRL/oxH yK1I2bykBSWZn6cb9gGquqljNFzaUCL9BD3cVB0nlCUaJdgxFKUZVa+ZplZVVRDRDZddr7nXg105 /9Mjz6Zb+VXGtIM8y3oJmtMv8yTr7CjZVCC+osDiCQHw7d0c4qpTUlNfJky3xVugDo+QhkI2nkJJ EvNIvJdvE6lMJX9Xb2cKQvsCNUoyGZAi6p4bOJKAFTJKz+/l0/eFoKEUR+s4zxjuM4bcOxz4bWMi 6t+lmIsqwVw0Fk3ldJfpqIQcK/Js7qV2dV6rNxwFpKOqwOjJna6nT2mwxsSX+M6xhUHQYmVp21d8 sWApi3zWZb00Bl/H3gZjei+j1OEldFlBQpy+gCHy55/khdqt0D9SKPbSyNpaYQr31TL0UFiVxX9b qLJU1U8KHCgeBoc6QcEaaHCV+zkXupMoIxiRVIKTTEMCmdkoCvAYBgpkrQPVWgYhgh3RT4J0MBkW ZHoifs0fWdAdncJ4p4g+Sm7Y+q6j0pRBN3dnNQmVIt7iV0SqSAdKN33AJzwjN3mIdNQOhqyBQDBs cgKOw67WlZxy6Aj4DSp9dnbGT1XXjYYpM/v9ElKXgHi/FytPZJC4MlS5OvjQVoD5Z4BperKsKgEV Hvr39fV1nehB2MHMcAqOxW9vS5fCuioSPMpZAQJqeI0HHFj6QN0D9DQvqAg5qvsbXMXJiFkGHiPb A2BzLQgi1gqS1x4xUHWVmtSEJIU42gsUHbQDyoqp896H2ldI0eznG+njM3J2Vg6elp0Arld3UOMl ykFLNEr4aQWvEgiHsQYFFgaxtWIx3qBzCWxzd3fMn/7yl5JURaYbS/+W2OS4c1oUZiXKETct1FGA 7w6IcfMNN7YlqYp/XJCDnn5EluM4TeLsrKg5SgLLKEjVh1Umu5pCjKaU1SE3Ib8jL+M8DCJHkAWG oKf2CQIbBr7iIPjRX9a76QNkR7Moa3ybtNJPGCdIv3tUdPcgx6ekb7kY6X5D7+4RBzOpHn+SNP4s K1sTTF07YRylQn60GaqIeXZQDGvpoNhrYdnhYEB+JN0aO/3KlueSoWK9dG3StajcWZF+wKTSonJH K/EqO5otkvnpnKh222RUudE1gx7e5ni5yUlvIR2DX7aEisJRtt3v43vOl8v/Cds6EGVYNrPcV9v4 f1YC8gjK0Tcf3r3FWuQmQf6ri8BQDWWvapSv9w6Ujarcts+sVDnOZTeo2iVg9b0ZtEq3Ump59qkH ebRXZzX2oEDr4+CTKkkHFlHv8fn4xV0vZNFSrNzhPkHoZ59PUDNUGdDVso7bepG8L0wTsnQSpRn4 3SdjOaBEhd8/6oGSyYwJWfxW/fI1DyG1sUBOGTf+uFWLTMmAAnUp0hTXoUhbPcLN7lNxkPlfaYLP B6r5HQ6aut6mJhHT1/D/peMFYSaD3X4T2HCWcyi47FOohhDDYlTWllyVlFyVUhWHh9Gzs2IXxy/S AbZ0QP5pVuQoc4ADAAiHvorDDUdM33iHVX2DRabko+PHKZPKcWjlfZamBM78W/QWyL2EPQRPibvF KwKEst+v9fV/aIFb/LLgTjnsTcA3xMeD9NuO/ZlH585shTaE/vpRnykjjDLszWp098fvV+X/gIFn jd0H9KO05BcHx5fDDwlKiAaYCZHf1xLzeUHJmQbmwW3lzcOd4UvDVLhsXEAaAb82aKStgl29OPle 2iMivwMm5fvsvSUsA8GuZk+j7id3fy1QQfWT2nRafTYsq12tzm3Jb/Vp35rl/U1fOxQsrv471b8A UEsDBBQAAAAIAOdO1UKU8wwpYwcAAMAVAAAqAAAARXJpY3Nzb25faDI2NF92c192cDhfY29tcGFy aXNvbi9SRUFETUUudHh0rVhrbxs3Fv0uQP/hwih27cIeWbaTusZigSJJ2wRwEyTZFvtJoGYoDWsO OSU5ktVf33PJmdHDku1d17BhaYb33PeLb2xVC6fMnH7OLl5f0cLTr5+uh4PhYPx9KMnO6ENj5Cld nI8v+elw8HH6u8yDWsgb/vZml14630QMWqpQ2ibE/yQ8zeSSvG1cLj3jSuesw/PhoLbeq6mWGb03 BLSg8kYLd0qhlOREkJRbE5zVWjoqgTSV0lBonJEFkGZAHQ5CKQIp/Hrq8ChYqqTwjZMRqpZuZl0l TC5ZAH6U20LmIPNSz06HAzArwQNYpqXYJdgRJ0s2uZVQtbDazlfRKr9JyLmQ1HhIyGRB+kBeBpBW tdJ4Ol3RT9bONWw7hZGs0Ss+Hk/PlPMBKkFLL8Gs8C37ipQh6wqW0SYWEhZfUa5VTfKPRmjAaAt3 HOP4cOBL6yLveGAJ243P/QkJU+DUMqoqo0xNEEFZIzSkAb5hhq4xBp5l2yYNMuoUc62BZo3WkPGP Rhp2a3S1V5WC+8hJ3+jgs02DCO3t2ipsfZoK3xqqNwlriffKRdEQXt6aGClMFM/DLYRQaqX6WsLr n9/98Pb2HWzH9D5x4rMIEdPi/tNToYKNEv0IBETpaYxYaE6LcXaRnZ9djC8uz+bT78avri6Kzuu/ yekt1c5y5EcrsrwZdTgx9NdI95wI59n48jK7hzmVDjjPKTLP8xu6yl5ll2sQxvgBsqZoT0nk5Ew6 tmgbnx9ue+wPt2fj6+wq0vfGTJIkWn7BVmF7WniDLZW4M/4RW0QrI484iGdq3rjod46I4eAIz3xw QnFilWpe7pxqo/2tcrCDRdh9Ca7JkYipFnwFA587VYfoBU85omQqqbBLo60oALqWZIb8sUv+BnHu Iv1H1rgxtcjv2gBJMAL5KxxCbo7HyuyQF700fkOabESHf0Yj+rIhZ8bHpwA+fPzdvcyRItPutHf5 I6e/xCqXwpvtzwJ/+vLLZxJ1rVW+tuXXrjQsVCHtttWUKRQep5R+hgk9tC5DqG9Go+60z5ZyWrVx m1k3HykZZhPm6EeF9HfB1pPXV+eTy9f4O89WzSK7//N/g5mr2sMBlWWlJuOL6/PJdxfnk1cvQvOo Ri/GulNOI6yjglfX/7eClcgr4VCI7AKm/rvQfFtv3eqliEbdaeHX1noZzAuFCQKGElDL2eXfBOYr ZEAuKukEXCAracKLgUuhbWM4A6qw16XDwTuRl1Q1yE3kIgqyFmEr+SAaFC2QdPd/0llB/+LkNRDz 3xHgmFMbn1I/Wiq0yYjDKhQkmgDNMOdwcp90leC///mV4ryxVQ9O0b9QTOQ9CnMOGU4JTb3RBePV WuR9TeS6lOjWJfF4WapOjzhVMFXuJCtz0pegh8VUtWW3PUpF4zrFZSyF3DPa5phKvo9FFxOQP1QY N39QJD82AVMHRQpoDXJ+kSBGv1eTrlMdIKezn7nd9aeSZz7c7sJstLQJt7T9MLuNbz/cor7eJ80W HE++GJz86RYljwSPaHRQH6Z7CHRYpyc1WgOyuzBjoEcVE54OH/Mbd8B0FFNXdFtqVZt+28I64MBn +O0BzB5ln9TyENx+B+732zblfgc+y297gB7o9KRGCTCOHugcz8kxQL4VQZzFjYUH/jiBLIRudhwX AZ/IuGc4rod5JOOeVHMX7vGM2++4RPl4xj3LcRtAB3V6UqPOcZ+xJKG4cvvyNw8Lr7ezsOSKy9Ov mMNFRvIQbNMoCFE0b43sx7gZDQdyPZKSWAisXNN+c6I4z47WjSBy/JZms6qW2A3bZpm+xu7IzeDb tLl0b5fLZRb7CaaoeKbArqkttuhklKwMlU509Qr7r6Fjl5SMcsMnVDixnMydqEuf+TKdXdT3yAj6 B3/g5eY4bUgzZ6v2egBmQXMmtMENSXbbeQLDZtSJq+rSVjIrS5UVcuQbWXLLGkHGfigYnaQFhk3P YZMy09FxkintxZCpf4jPJ/0QkOTkI7mtVVQybaRpeehtzftowt9esdqJgWK09T38JmV1d1R28kUL w8c9+5apMrDtQa7P4UgHOMKWqarraJfIPFJHizwty3CwFoYx32OrLLBvQ5K03NbeYBcNSquwiuHt 2/jeiIC4Wo34ZJb38dRu/hiMSugydZia6ehMV0cnm+44aBkWBqs3nYEZsiKKscEFQCksPqf7jv7C ps3TFMrIv/WLU167h4NvYFR+OcHLNFoiyneRYNb4ioK4g3HjdQ3f0GCOs7SyTdz3mEO8AuKCxzrF TIwVZIMNXk54o4klaZPf+1lEWgoTutTbYu1lLbgP6NU+yVGzN8F+sUHedDtsHF9bQ/HVmrNcEvo1 nPfg9bTJu+767uI4lAqeA5W8x+QK5SIFRuR2GdZzDJqhrEhVtY6VMQEjdU7aq4Y3PH92lkyFJF2Y 6Pbb1pTa2qtVb7v4pChXPs3iiWJni47RD5+zmRd+stVBYrHbfrXbE7aPbPTTBy8OUA4Hn6xXfLVK pqmmqLPxEiBPknI5jDc8ii9AQ5COr33+AlBLAwQUAAAACABYntNC9il1ZUoAAAB1AAAAMwAAAEVy aWNzc29uX2gyNjRfdnNfdnA4X2NvbXBhcmlzb24vcnVuX2FsbF9qbV90ZXN0cy5zaCvOUCgqzYtP LkpNLEmNL8tMSc2PNzQo1ivO4CqGSGXlxiclFqfmZOalAkUV9PTBivThSpHUJefnFZcUJQJVpsRn ZKZnYFfPxQUAUEsDBBQAAAAIAAme00KZhkixYAAAAPcAAAAwAAAARXJpY3Nzb25faDI2NF92c192 cDhfY29tcGFyaXNvbi9ydW5fYWxsX3Rlc3RzLnNoK85QKCrNi08uSk0sSY0vy0xJzY83NCjWK87g KoZIVRiZmcQnJRan5mTmpQLFFfT0wcr04YpRVCbn5xWXFCUC1abEZ2SmZ+DVUVZgEV+SWlxSjFdV Vi5x9gPVEWc7FxcAUEsDBBQAAAAIAI6s00LB84U2MQIAAKcEAAA3AAAARXJpY3Nzb25faDI2NF92 c192cDhfY29tcGFyaXNvbi9ydW5fY3JlYXRlX3ZpZGVvXzEwcy5zaHWTTW/bMAyG7/4VrOMBaVY7 Hxt26JICwzBgvRTFdtihLVzZpmuh/oKkZDUy//dRkr8aIDeBfPmIfEXNLpYRL5cRk5njzOBHGVcJ ArI4g6DZHyDlOQIvQWUIssaYpxwTCtR7BQkXGKtKNKAq+BlsvnyGtBIFU1dEYmUCcVWQDk3x/e+7 X4G+4tbU3jPBClQo5DXFwFvvbt8ztfQPApNyX2gCU8BTQzrwBKtwvZKTBlgukCUN4BuXSl4BFWvp egUS44pa0XNIyNgBB22EWEJMZ4W6VaFZeROAQ/c8wAX4ib1qOV749FVjSwegeKXLT/MncZkz+epQ kFwxDZQ0sjbTphfaYMomldYAzEaNtfEatjVT2c1yG+e8DnXmJtz+5QnFwm2G/CVTdEi1k6GgMW46 IoCuo4HlzpvT01qod+z57aURGapUWOy8Y1/wIVi0HUGo3dybY5xV4A1S+AdKgBu64D6W7qUFmZYM RKiH9ZMF2P766KaLjs32mU+UManG5HZzeMa3WlC7BtvC44LOltY+Q9d6FItTua0n/RI2vU5V6pzs I50HzABWWIa0MhN9j+gaGQcwgfXKVtoRjFnud71TvHyZrJ/2j2avChitbodV0LsTBIFrGLLOuQLf 35fRPk1R0HL6ftQopMc8du213QpNYZOdo/jwYNb24nA2z9jpGk+xploU4KdnAQvHLHGJjoO5RKe3 4fTzvP+jAXzTX1vbZP8mE+PXJM8OKOhfkicpdxznP1BLAwQUAAAACABQptRCUhKhDPgDAAAJDAAA MgAAAEVyaWNzc29uX2gyNjRfdnNfdnA4X2NvbXBhcmlzb24vcnVuX2ptX2Jhc2VsaW5lLnNovVZL c9s2EL7rV2xoZkZ2K8p2+kgdUYe0zcSXVrXb6SHxMBQJSnAoggYgx66q/97dBSmRlmhnfCgPGnEf 3377wIIHL4ZTWQynsZn3egfwa5GoVICIkzkE98tbyGQuQBZg5wJMKRKZSZGioFxaSKUWiVX6HqyC 98HpD99BpvQitt8iUlykkKgF2gl2nlz+dhFQiHP2ncQ6XggrtDlDGfgn4Xkbs9eTGXyAFzBIQTCr NEpyWRq4ekOARQ9g8RnN29r90uEdkoswSZHLQjxmk6jCWB2jVRrN5WzeYXtbvu7QXC+eioMWO1Ey 2cw3V7PdNEnYeulIaqvqzIVN9hGtFY97UvJtwsbGdpcxS9tvHZwbus7QzmYf643mCd+aNw4pz3WB E0iz7Z8Mj2jYe6lCD5HMFXgTrRJhjCxm4K9q47XXQ4ODrbMb9zMYlbGdj4cjanBEmnE0+iJTlEWj uUAmFv9kNPGRjq0YczQA8soxSuj3KSmGbEQ7RBNGNFYsQn9Vm78MjtbsrW3Y9/tM2N8Ywr9gNXiR B97HwjskEKbCANp+OLkiZ8eqlp2ybEuwlr9COSpuCJminZ66N1Gk4asfa40ow+/JjOra76MsrB3e 4MsodA70/5uwcgDmxfWmglZrRxa4SIKvLyOC35SumAxUD2QGXjDsPJZDf7Up1vqm9Fc35ZqWl9cY YHoC3ow542y3kN7gBEk2g0HpFto7bFrY6B0pLtVSJ+LvqvicSEP+vu6Ay4w1f0zOL3OZEBKScpLJ juTtA8mFwMFnApr+8d5G8e9LWxN7RjUI4R2V+sLNw7bsLgdqL+vD442p+VO9Fa6XadvlGMZYz4d7 Z29se2e5ASI3ouqEO5JLPo2lFrdSLU1+z9eLxvOAF9ItXiRSFaAy6OouY9HxdyP3i+CRo6uJ7OkK iwF9SqVjvNHqe09pbDkp67uM7jG+3MQdrprEVnBTaSnRwMHrBQ0hoV1Pq7O+madU8Dw15+aZ7Wk0 eBsKC00vWOprLmWd719GuKSM/EdQQjPcJpgaEgdijslijDg9c8Wv+PAy6MMnWqAwSOClgWeQ/QSH jIqxTJQt85xdCVfclRo71gy3ho9H8Lp2+TwtzYZFZd2GWcMQTo7x2XGJcJ+IGZ5Ytym/1r9YYkZk orIuhP0hmHkLSosF3kY4tgz4CIUByrrirms0+0VFmdTGRjhDchHnTcR2qCqp2rPVzgb9dT0dPze+ 1Ga5msZ59cFG6tIUGq8oN7/00rykGlMOmyW3XWo/4XPY2M6ev5uFB4OZQLpwBa0F7I79g+kI/NUu AkUkYmsPxrRodr4VWpO5WTHPDLF/PT0EOf4fiD4Vo7Xz9iylVOFnFP/0/gNQSwMEFAAAAAgAcXvU QuJwSLr4AwAARwwAADoAAABFcmljc3Nvbl9oMjY0X3ZzX3ZwOF9jb21wYXJpc29uL3J1bl9qbV9j b25zdHJhaW5lZF9oaWdoLnNovVZNc9tGDL3rVyA0MyO7lWQ7bZo6og5Jm4kvjWonk0PiYShyKa1D cendlWNX4X8vAGol0hLtTD1THTRcfDw8LECAe08GE5kPJpGZdTp78Gceq0SAiOIZ9G8X15DKTIDM wc4EmELEMpUiQUGxsJBILWKr9C1YBW/7x89/gVTpeWR/RqQoTyBWc7QT7Dw+/+usTyFO2Xcc6Wgu rNDmBGXgHwWnTcxOR6bwCZ5ALwHBrJIwzmRh4OIlAeYdgPlXNG9qd0sHN0guxCRFJnNxn02scmN1 hFZJOJPTWYvtdfGiRXM5fygOWmxFSWU930xNt9MkYePQktRG1ZoLm+wi6hT3e1LyTcLGRnabMUub pxbONV1r6MpmF+u15gFfxxublPs6xw6k3vaPBgfU7J1EoYeIZwq8sVaxMEbmU/CXzrj0Omiwt3Gu 2v0EhkVkZ6PBkAockmYUDr/JBGXhcCaQicWHlDo+1JEVI44GQF4ZRgn8LiXFkLVo+2jCiMaKeeAv nfnT/kHJ3toGXb/LhP21IXwHq8ELPfA+594+gTAVBtD209EFOVesnOyYZRuCTv4M5ai4ImSKdnxc nUSeBM9+cxpRBL+SGd1rt4uywDm8xMMwqBzo+adg5QDMi++bLnQ1dmSOg6T/49eI4FdFdZkM5Boy Ba8/ePClG/jL9aWVV4W/vCpKGmJerZEB6dB8zBhtM4v0Flo/TqfQK6rx9gZLGNQqSYpztdCx+Lgq BadVk7919ajyZM3f49PzTMaEhNQqyXhL8uqO5EwgNSag6YmnOIrfLawj9oi7IaQ3VICzqks2xahy oaKzPjhcm5r36pWoKpw0XQ5hhPfbNnR2crA3lssiMiP4wb2wC35XCy2upVqY7JaXj8a3BdfVNa4Z qXJQKbTVnLFoOFQN+YfghqTFRfa04CJAn0LpCPed24pKYyuQ0m062nK8+sQNphLbFdxEWkq4X8Hr ObUooV3Gq0mw7rNEcJ/V++iR5aoVfhMSL54OePWXfKUu7w9GVMkZ+Y+gxKY4czBFTAAoA0waY0TJ SVWEFS8eGV34QmMWejE8NfAI0l9gn9ExpgnTRZYxBOGLm0JjBethS/h8AC+cy9dJYdZsVtZNmBIG cHSIvy2XEKePmOKbXc3VH/XPF7iRyESlbQi7QzDzBpQWc7wdbGMGvIdCD2VtcUuHZr+pMJXa2BB7 Ss6jrI7YDLVKynk2ylqjX7oueV37rptmahJlq887Uhcm17jQqn6mQ32l1boe1kNwM/R+x99+bZZ7 /nYWHvSmAunCBdTGtBsDd7qj7y+3ESgiESs9GNEAav1+aHToevT8x1C7x9ZdkMP/kfBDsRozccfQ ShR+hPFf519QSwMEFAAAAAgA9p3TQjWohvdXAAAAnwAAADkAAABFcmljc3Nvbl9oMjY0X3ZzX3Zw OF9jb21wYXJpc29uL3J1bl92cDhfYW5kX3gyNjRfdGVzdHMuc2grzlAoKs2LTy5KTSxJjS/LTEnN jzc0KNYrzuAqhkhVGJmZxCclFqfmZOalAsUV9PTByvThilFUJufnFZcUJQLVpsRnZKZn4NVRVmAR X5JaXFKMXRUXFwBQSwMEFAAAAAgAXbbUQsW7u1TTBAAAcQ0AADAAAABFcmljc3Nvbl9oMjY0X3Zz X3ZwOF9jb21wYXJpc29uL3J1bl92cDhfdGVzdHMuc2i1Vk1z2zYQvetXbGjZsd1CH04m4zqmLk0P uXQ86bSXxMNAJEihJgkKgD5cVf+9uyAhUZFkO5lpDo642Pd2F9h9wMmr/liW/TE3k07nBH4rY5UI EDyeQO9xNodU5gJkCXYiwFQilqkUCRqqmYVEahFbpR/BKvjr7hpSpQtuf0YeXiYQqwK9hIPe/fH7 px4F+OiQd1zzQlihzQ3aoDsMP+4ydjoyhc/wClgCwuWURHEuKwP374mw7AAUD+i+u3rY2l9evXsb YYkil6V4yidWpbGao1cSTWQ2OeL7d/EcG3q8kGteXXdS2a43V9l+mWTc+ThS1HbpaHzncqgEv/A0 cj9hY7ndz9hZd7+O5NxaOxq69jmU9WblGazPG5vUdXWJHUid3R32L6nVO4nqIETEEwXBnVaxMEaW GXRX3nsdkMPJFl33+w3cVtxORv1bOtGIVkbR7UImaItuJwJTsfgjpZaPNLdi5MIBECrHKGH3nKpy lK1oF+jiGI0VRdhdeffT3uXaobUNz7vnLuHuxhH+BashiAIIvpTBBZG4VByBtp+H9wSus/K2K2fb Jujtb9COC1NipmjDQf0lyiR8O/AroqIFIsCdPT9HY+gR7/HjNqwR9PunsEGASwx3HIB2tJGduUyE wjNBOSHRSFWeqwWdAe3JTeMLvZdvNEafVn67CfyBW85oCc6cJuHe5DmMBaiZJQHykUn1AlWZUveM tUGDZiyXhbThaQKlsjAzKIWMMcwYa+IJLFAjJ0pbUeul0jKTJc+hgROr6XXcl5+eFIJef08R+t3V 5kDX06q7mlbr3kKMi6A1ZrQTpN3zaokEmAiRxCHC8XemFOVWcWOECYfALOAfxmdWMZ5bpkUaDuCL owEqjGdMlsztncEVxh5SVqAlkcaGbwYDb+LLlmmLt+pBlIy6pkbTzMmY2YkWZuIsRDYNXSktHPHt W7Fd2MzwTITxlAqbslzMRd74YTSuM2HZWFrXrsPBYDebRKuqrsWFxhzkPwLrxnYSiTPZWSlCOl9g Cxw610StDCZoqxuKwqUVzuhq21fr/nBnuz2sPb1bLgXfc8Ib3Nmo1/eCe9DbLq1zFbkRDaYWr5nT rUqLuVQzkz+6mxj3gNp1jneuVCWoFI72mCNDqaT/6m7VBXUqOlZzN0x+moQbW+p1oqLp4c5LaY6v Av92UDoRmhb9i8BNHj0RxBIPMLYNXXOcPfeZzIriMTyHr3WTp2lRiQyY/LHN3KQOV6OzIWokXzzA 634TsQ8r3C7UHei+g/Xrr3DhK/xUq/JGE7AInJwcHynO1mQCCcpKnXqD+9M0AGo8QmUo3rgJGBCc /DSSUYuaL8g1M5ZMwwMshlPzXdVS3kSHQUyUzvLcYYhQLCuN592Ogw16Cdce8jCuzCZ8471Ls4Y+ uDnbg0S4cSITOqpvpJfiyxle5uSi0mMMh0O4zHeotCjw2semd4RPpMDQdizu2rPZhYpSqY2NcL5l wfM2426opiiP3DnHVvpr3xa/tp7EWa7GeDfUL2NaJjXCp0Dd706a2nKy7eCNWm0l6hf8d9G6WILu fhEBsExgtnAPrSvEa8Y3zdHrrvYZKCLltQ5gNMLO3Lyrdjpyo0s/SH1Y074lGfyPCT7H7fXxoDTS qwZfpx2/snlEdGr7f1BLAwQUAAAACAAre9RCuWbQJwYEAADtCwAANAAAAEVyaWNzc29uX2gyNjRf dnNfdnA4X2NvbXBhcmlzb24vcnVuX3gyNjRfYmFzZWxpbmUuc2i9VlFzm0YQftev2GDSyG4lJDlN U0fope1M/NLxtNOnxEMQHOJq4NDdyZai8t+7e3ASRJLtcWeaB0fs7fftt8veLmevvDkvvHmo0l7v DH4rIhEzYGGUwnCzuoeEZwx4ATploEoW8YSzGA3lSkPMJYu0kBvQAj4OJ+/eQiJkHuofkCksYohE jn7MgG/+/P2PIYW4NtibUIY500yqK7SBO/avu5y9Hk/gE7yCQQzMqIqDKOOlgtsPRFj0API7dO+e Hrd6axQXYJIs4wV7zCcShdIyRK84SPkiPeH7d/4UG3o8k+u+fN9LeDvfTCwO0yRj5+FEUvujk/GN y7EU7MHjyEPBSof6ULGxdp9OaG6dnQxd+xxTvTt5Amt1Y5Oavi6wA6m33bF3Qc3eiwUiWJQKcG6k iJhSvFiAu7XOldNDh7M9uG73K5iWoU5n3pReaEAns2D6wGO0BdOUoRKNPxLq+ECGms1MNABCZRjF d/uUlKFsRTtHF8OoNMt9d2vdXw8vKoOW2u+7fSPY3TnCP6AlOIEDzufCOScSI8UQSP1pfEvgWpW1 TYxtL9DaL9GOB0tipmiTSf3Eiti//MmesNL/kdyorv0+2nwL+IAPU78G0O/v/QYARpepNxW0GTu8 wEEyfH4ZkXxZ2mIC2H5MwBl6j9x/z93uqlUtS3e7LCuaXk6rgwF10GAkIAwGpSok/qdTycJYwZhM UpjhaFnRNDfaFIzwt2QJvIXPhgqMO1NMwz2TG5WJByJbIagmvobL0QhRSzBi8JCXmCEXGGlPYaYu Eiv0MmWp1u62rgtBkpIO9uWp2r20p6EKv6A4O4LJDAkO589RnF5rg2KZYg28vl4rc7OwJvdcrFS2 MasCM1O4XLBEiosCRAKnXpThoqtct8+vzLQPrRnyp3UUAmJKIUPcTnaHCRkzSYd2L9FOMouKrXFs RLqhm3NN9RvW9DKnjiK29XzXavEqzzd+H77UXZIkeckWMOD/sbb7KFjm78Z4lcOHO3jjNYo82GLN 8JaA+w6qN1/g3FbgL8XqNBX/yijFBc4KTBaBQEhMH4OG8VX9OhqJ5qpjEjQeYRDBa/Uy/SSEeDGa CpJVlhkwMbN1KfEttgNiK17Aewu5m5dqp6Px7tJU4MEYb8foABJgJdiCyaCehM/FFyvcIeQiklMM x0MY5R0qyXLcNtjKhvARCQO0nYpbWTb9IIKES6WDGD+08jBrM3ZDNUlZZOeFtuRXtj9+aX2JLTIx D7Pmg4yOaQbhCqpb2Qyk9uBo9aQdO7AfOz/jv6YLzfh13MMsHBgsGMqFW2jNVzsKvumOobs9ZKCI JKxyYEbj58i3RKc3d4PnhUGOD61vSUb/i9SnonRm4ZFhFQv8VDJ/ev8CUEsDBBQAAAAIAP161EJ9 f+fYlgQAALgNAAA8AAAARXJpY3Nzb25faDI2NF92c192cDhfY29tcGFyaXNvbi9ydW5feDI2NF9j b25zdHJhaW5lZF9oaWdoLnNovVZNc9tGDL3rVyA008hu9ekkdh1Tl7Sd+tJ62ukpyTAUuZS2JrnU 7tKWq/K/FwBJibIk21N3qoMk7gIPD9i3AI9eDaYyG0wDM+90juDHLFSRABGEc+jfF7cQy0SAzMDO BZhchDKWIsKFvLAQSS1Cq/Q9WAU/98fv30KsdBrY7xApyCIIVYp2gp2vf//ltz6FuGLf60AHqbBC mwtcA3fkXW1jdjoyhk/wCnoRCGYV+WEicwNfPhBg1gFIb9B8e3f/6mCJ5HxMUiQyE4/ZhCozVgdo FflzOZsfsP0zfQoNLZ6JdZufd2LZzjdRs900aXHr4UBSm62D8dlkXwrNxuOeu4SNDewuY17dfjrA ubV3MHRls4/1eucJ34Y3ipR1naECSdvuaHBCYu9ECj1EOFfgXGsVCmNkNgN31RiXTgcNjjbOldwv 4DIP7HwyuKQD9Wln4l/eyQjX/Mu5QCYW/8SkeF8HVkw4GgB5JRjFc7uUFEO2oh2jCSMaK1LPXTXm r/snJXtr63XdLhN214bwN1gNju+A8zlzjgmEqTCAtp9GX8i5YtWsjXltQ7BZP8V13FgQMkUbj6sn kUXe6VmzI3LvHZlRXbtdXPMahw/4cOlVDvT/W692AObF9aaC1m1HZthI+s8vI4Iv8qqYDNQIMgan P3jG5R64q3XZykXurhZ5SW3MaUmZPn3ukQQBvV5uMo0/dq5FEBkY0ZJW3CcJEx+nTNHAEP9rEcNb +FwDARsLIyzcCn1vEnVHUEUmoIK9gtPhEP0WwGRwU+aYqlQYpw3CDRjBDdpxhcqlu6pKRE5xThub SpVtWbWBqNwvKFQLajxBqMO9Zy+CXVr2F4kRNVB1+wq+eFipW6kKk9zzJMFsDc4eLJyRKgMVw6Hj Yyy66fR7BD8IVhdNIbKnaRUA+uRKBzi8mhGndCQ0bTZji0YWzzGxxFRCW8NNpaWa9it4nZLeCG0Z bpQYcUjWsHeAZcMugGkxo/hxnOZiBmlwg8cqLWTKQq6wB02RH9KqMEGhWDB3HshiUeDpCVNDhUrT 9MR69XpQGAEJ+/DFtHNpuGXIsEgCTTCbO+O4LcIOeB44MxQDglHn9Efj86F/Nh7674aL/PSsviKw 547UAXt5NeZ/wtJ6L1MYQv1a2AZrU2eYcNFRcfi8R0hRkab3Xhe+VsTq4vbkfyT4FpHx5JsRNt3g 7gbeDGpxDGCF8sV+Bu57KN98heO1Jptz/wPPh6Vn5F98vjNs7yhARACCQElg9CC6qDKrOXN3xqzo XKAXwmvzsoQaZhjV+HGRJAxCEcQy13jD2oGxdZzAeeNyM83Nmk9tvQ1TwgBG2M+GOy4+lkbMhPar IfZc/6zA8U8mKj6EsD8EM9+C0iLF6mCbYcBHKPRw7VDcskGzd8qPpTbWxwsg0yBpI26HqpNqPLcO tkW/bHTysfUSPUvUNEjqd2napqmBbw+VxnmEtBt9S6TNmIDNmPgeP8etwem4u1k40JsJpPvwtldt +oE6+u5qF4EiErHSgQmNiEde9bY0ur7T/zLY/sHyEGT4v1J+KtrW3NoZLPS+hE2bvzr/AFBLAwQU AAAAAAC5U9VCAAAAAAAAAAAAAAAAJAAAAEVyaWNzc29uX2gyNjRfdnNfdnA4X2NvbXBhcmlzb24v c3JjL1BLAwQUAAAACAAihXRC2EV99RIFAAD3DwAAKgAAAEVyaWNzc29uX2gyNjRfdnNfdnA4X2Nv bXBhcmlzb24vc3JjL3BzbnIuY9VWbU/jRhD+jsR/mEsV5IRcYoejH0iIRDlKUXNwIodUtUWRidfJ qrbX9a4DaY//3tkX22uHl7aiH+oPiXfm2fHMM7OzM+ju7sDxGz5o7tKPCZjnCFKeZP0Fik9Zusno ciWUuFqdM7aMCFwkix4MXW/YR+xHwhcZTQVlicLGaS4IB7EiwNYk86NosIzYnR/B59nlNbAQxD0D miAMNvkaFhFNef/tQ+sOdnd2d76hySLKAwLj2Ber/mpii7gIKNuWRfSuIYwxCrZoIjd8wIUvlBgV AQlpQuDTyU9zFannulIuNilBFZAkj+FPdAxmX06+3MzmVz9C7TkGcHuW/mZ2cn42P7u+vro2+vee rf/+Yno2n138XGBQP9zSX30+u6z0B7b+5Pp8ZpmX+g81/XR6dVr//iHqHwv96dXHs5GMcHdn0IVL JsgR/OAnQYTZ/+Q/0BjjDSmWC6d/EJn34fl371RaaCJgScRcaudS6yxYwgUsVn4GXSlNsC47mi0u snwhQDKNPyMt8oVTwHqwx0VHyTMi8ixBdZ8LZRelj9K/gOV36EjMyVDWuGPW3I9T9LYHZp0S/7dy gWDjQaHFnSpeABqCY4x0EAcTcPtuR2pAwZArDyXQhYgtPdeRhnFh/sxnYaC+oTwnESe17UUVjXRu BgOY0pgKEAzSjKwJMjgAt/JGbZuU2zpPG9N4Q5OJ51GnUOYk9mniyBc/W+IJ1+nA9/Uvt4YKqaSj 4u2eBmLVgxWRzaGUhhlmpaBfi2L/Ya7EvBThabgj2ZyFRoFuuiOLbcGEH83573OSZUwGgXwqfZ5w ukxIUFSL3O2i/vJmOu2ZtWfWaoM8B7qq3HkqMguKIs8Sjazil8VtiJrLcsulg+XBtcpAUgVj+NYQ BBCmGcaHGuwk6HsPWjfcX+LZaHMYY8NTVe9NqvfhBFp6a/m0xopaBGluJ7IFFRROfk1aPVBpcW91 +cBzrlo9xACXDEuIJIFaPuo41MfkAcezJljkKNsHtz1DlOfqr2hfGrAPWzDJirY4Bg++fi324eoF kpSPR1gaaz+igS4i3TnawUM76KugawX3SuhVe3sh8qpWcaN2ulv424UDPGNDBTduy8KVYFlv9Qam uPDKdBRA72ngsALKTqJNjrHGO5IvR+9U65KxkrMnKJNXadVpycOCkIDLdguRbBqSu+J7z9LVuE1K eI21krea4++OdayV8y60LWr/WRAc4hzvgjvVnk1IeKvAyl/jLZJEm63TAq0wjyIwfcQpmeBH7aCH 5dPRxaMc6xlX346OkhPFiN1mQpaSpKgMDDW7ayEVx7rZvH4U8sTXjRCkHTvNbd6veoD3Wg9ozAEv nIYyAm87guF/F8HwrSMoroSFGtucqhJ19lno1C6Rzr+LSRn3BU4KJGbZxj5lz7WkaqL6WzF4/9sY qtuqcV0cNq4LCb5fyZJwnK2RYGzZ6RQncG8Pj3hG/MDkGS31wKanPIKKEasNPWPBe9KC95SFktrG EIJQWW/aodFzEK+AeKOii4Y42jhUzT5AMV5rdoL9fWo1TjMWBTQMEe4oex14r9/cqp815qb9Y72l q/5K1P6+3DXS/57dzKSumYhmdW4laiJvLuNqfbZGX7fQ3eaI2Bj6zNRaTuvlmD48POxjvushFqFb NwvLBRZ7u38QharLVGY7VShYsUdFQDpxHfSLkGIxqik9W+lZyqrYwkXEOLEkNZC3BfIKkISZmbx2 6EZqOP8LUEsDBBQAAAAIALqAzEL3DEA1fQUAAM0RAABAAAAARXJpY3Nzb25faDI2NF92c192cDhf Y29tcGFyaXNvbi9zcmMvcHNucl9vbmx5WV9hdmVyYWdlT3ZlclBTTlIuY91XW2/bNhR+boD8h9MM DiRHtSWn2UPsGMjaLCuWJkXSDLsVgmJRNjFJ9EQql6357zu8SKJkO92G7GV6sMVzPpLnfOdCatjf 3oKjZ3xwufMoI2CeQ1jyvBjMUPyGLR8KOl8IJW5Gp4zNUwLv8pkHIz8YDRD7lvBZQZeCslxhs2Up CAexIMBuSRGl6XCespsohQ9X55fAEhB3DGiOMHgob2GW0iUfPL9r/eH21vbWVzSfpWVMYJJFYjFY TG0RFzFlq7KU3nSEGXrBZl3kAx9yEQklRkVMEpoTeH/8Y6g8DXxfysXDkqAKSF5m8CcaBlcfjz9e X4UX30PrOQLwPUt/fXV8ehKeXF5eXBr9q8DWf/vu7CS8evdzhUH9aEV/8eHkvNHv2/rjy9Mra3mp f93Sn51dvGnvf4D6x0r/5uLtyVh6uL017MM5E+QQvovyOMXov4/uaYb+JhTThdM/iIz76PSblyos NBcwJyKU2lBqnRnLuYDZIiqgL6U55qWr2eKiKGcCJNP4M9aiSDgVzINdLlwlL4goixzVAy7Uuih9 lPbFrLxBQzJORjLHHTPmUbZEaz0w4yWJfqsHCDYWVFqcqfwFoAk4ZhEXcTAFf+C7UgMKhlwFKIE+ pGwe+I5cGAfmz2wLQ7WHspyknLSmV1k01rEZDuGMZlSAYLAsyC1BBofgN9aoadN6mrt+MY03NBl/ HnUIZUyyiOaOfImKOVa4Dge+3/7yyVAhlXRcvd3RWCw8WBDZHGppUmBUFP0/rZFd/1ALs+g+VApe i7BGbkgRssQo0Hh/bMVAMBGlIf89JEXBpGvIstKXOafznMRVDsnZPurPr8/OPDMOzFhNkNWhc80P l6KwoCgKLNHYKgmZ8oa+UCZhKQ2sy9lKDkkgTOBrQxtAsizQP9Rgf0HbPdi55tEcK6bHYYJtUNVC MG3eR1PY0VPrZ2eiCEeQZnwqG1NF4fTXfMcDFSz/k04q2GSq1VkMcM4wsUgeq+Gj9kNtJsseK1Cw 1FFr73/yDFGBr3fRtnRgr1dgkhW94gQC+Py5moejJ0hSNh5iatxGKY11Gul+0ovve/FAOd1Kwy+4 3jS9Jzy3Mhhnaqv7dprb6byCGI4Uxvgks1oCZTK2e54iKqhjVQGD9cBRA5TNRy85wQJwJZmOnqnG NZ01oWv4lKdv05zJ/YyQmMsODansM5LYar+NXHYOoBreorQmtWX4yyPta2O8Dz1wLOL3bI7df+YU h6zE4+RGdXjjIh5MsIhu8SDK04eV0oKdpExTME3HqZnhh73Yw1xzdaYpQz1j+vPRU3OkGLJ7UsKW JK8yBV0tbnaQiiPdmb5cN2Ue6a4Jch077D0+aBpG8KWG0blKPFE6tQfBqgej/86D0XN7UJ0fM3Xz 25iYOhdY4rTOH/ffeai2igRePUjGige7Bjd1s+aK9rc8Cv4nHjXHXufcOeicOxJcXfbKLDT3Id9o 7hYykRxn5dYxsXZwq7rd3ZUNikSxyQ7cw7OPCg/qylVkWapNawTr1wjWruGCXMWQ37nvIF5mqzZs vAkSVJDAQKpb1YJysxNeZht+MMZ4yXKoEgFFWuy7HeztUWnTi7ozm+VimiQ4xVFbuvBKv/lNw+zc 4vaO9JS++mtQLas2gPb25NJj/V+5hVny4olIySRvQjVug7shqcBBBda7dlPGKOokQ3Prr41WfEcH BwM0qOWc263WlYScynPeCn/7AwbJXpnRX7mHdy7RphZqK+uPocrCVpAUTWb+XcHyuZofRvILfy5z pvJ8uIYZ/HqB1rnNSoHtojfYTxPVwxuLKoafAK9ub/GHjeKwYlEH30UiCKkG45YysJWBpWwKOZml jBOnlS8NKFgB1XkiYeZLq9XrxuqT6y9QSwMEFAAAAAgAIoV0QlMGuHkfEQAA0TcAADEAAABFcmlj c3Nvbl9oMjY0X3ZzX3ZwOF9jb21wYXJpc29uL3Zpc3VhbF9tZXRyaWNzLnB57Tv7b9s4mr8X6P/A dVFEahzZkp3Yzk0Wl3Sm3Q46s0Xb6x4uFxiyxdiayqJOlPPoYv73+x6kRPmRTBe5xf2wwe5WJj9+ /N4PkvviT721LnuzNO8V99VS5c+fvYD/iNequC/TxbISUT/si7dKLTIp3uXzAGfPs0x8xFktPkot yxuZwPjzZ51O57XKb2QJEzdpIpWQ+Vwlab4QpdTrrBJJXMXiulQrUcm7SlynmdSiUgCt13GWfour FGkgMK3W5VwGgBRxT6fxGggsp1NxJjq/fZNl/u8LIiuYAzrv53gFqP4Lhv1upwV+iPDpahbnX5X+ mrZXpStxYSZ82iddFaoEyvJVXM2X9e98vSru619K15+lrD91VQKrzc/7BgqQLR3si5v02zQuUhwi aSgdFAAizPws1jIHhnbP6iJLUXy4OpHXYpbovPRWErafT7Wswq5ofkT+6fNnQpAUhbj4+a+/fv7p 7fn5xx8F/F38pvJKLuK4TMwSMY+z+TozemhBHGgLE2eZuiW9gRCLdSVFtZQiBsXHCykWcZoL+E8B VImZrG6lzEV1qxBdGVfyKEl1BXzADmK+BuPR4jK8Cux02MWFoTgSQGOh0hyM6VqVDCpCCxYRWLQH LELZAKCs1mWuiTzLmEx2sX2AMjzgVWCywE0SFwhLCqCR2zKtKmBldi9OhTf3jWukay2LQoovcSbz b6mWiGJZVcVpr3d7exug6m9V+VWjxfXgVxbP5jKvyjjrof3Lu/kyzheyF41Gk/HRrKHtiGnrzXEk r3rOVLBylEpSA6+4vLvsX5EQ7lD+jkFcIRiLlcDCB8BIuA9hi2ps0UPYEAwBM7WYWgpXceFl8WqW xOLulJwigGnvzu8yE767IHp8QeTzHi/EhdQV6H4GqixUdg+RpSKiFmVcLMEOCghAIENQKKjP7nDX BTbKfHpHxlcgheTnAaIADF5Ne5el1xUDIrGI9oJGDBoxKBP3DtVWkk+BjCoImHFGW67SfAoDxOid dwk/my39rvsz8q9oZ4CzK2D2Epe5K5yfvKJNgAQmuyLOE+CAeUZkbb5hwCtYEzQbbc82Yn9tnYpc LLXbJAI4XEuhICTUM8i1uEVHLMG9ZmpdEQlbBACYx3R1Lbs+uPkeAJagbzBFuzFFj2GKXEy7WLPB DUJwCVytwJaI+vhmMU3S62vY16P9j4ghX/SEZ3V11KKSY1K9sAniKLj/P1H8pdDxDWZucOpZWiFx iMmJ5w8H8/+LcL4dk/HrkWD8r0D5TwiUJjo68XJvoDTR0YmX/1igpC05SBLK/QHSQppPNzBepxAL TdjK/hUQnyggyrviu4KiVT6YHwSleyh/E7TJFYiNOgHcD3CqHDYBaeVgrOoWApcSWVwuZMDr52D/ hUiNEK/blPwZAkRfUBDdohFmah65fcGgGItCllioxWYHN9STgwEKz0WFogQmX4nQItwR6znav0mz 7A1w6HHPMAVup3o901VardH6uyJJ5/gRl/dTdT29iUvdSgGflykEyHVOQKJeCuEXJCiod4Fvdc2l r1qtMOnzZqLXe/lSBEEgXr7s9RDZbQrNBQLCNmk8g05vIw4gsAjcSEqMTQ3CM7GHDQTF4JJixCtl gO4G9HkdJMELXvlIQae7b7lv9LW5G2ACMMbSEYeA/lB0DKptuV2mV13Gs+evhd7N0a2JRnl/ifUv FL21l6W53NCLNKFdm+4W3CNZz1mON8UddMQC/V1XcYnSJdnH4oLktJRxIkvtShoMGTe57J9C9vgT tLIXHSrgIL8Z4wmoH2RS/D/3WzITn8u1dDh6E2ecE5mTDyAeybyARUoPKZ5i41nXHnOVrVdGEU4C RJXLyrs0MZcncDVMqAJIczB1yo5vDQGJdLIfQhl6rdCsLblcMUS6R/JmrkWw+IEEZJA2cEJU64Ko vM5UXFkASOCQKNtDLXxXvsUgQYB/DF3fQjlyC+Ik8WiNKzicmWpF9gD804dbCbo2ub2kFVXkhYQm tWzkP4Wc0PyINhRLP5cqadnwaygHwUQ1FXl8YkOWjGaXSMAOkRt+3i7T+VJAGJrRljQNNr5Ut8Ta er4MxHmmlfUAQCCWWC1CRlxhaAJIAjMIurj6w6dfPwaOaIw6U+7hedB1jxfiE5SfknsatGah1iUR zjRDgoEsAbtSMFzn6f9AFiYF6MAG/Y/gdYS+XtYlXBhsICmT0Wp2WBwijzUlsUtqW4t7XWsabjpX G0f0R3Bs6tFnIxACzeAtlnLGDrZp6+7Yq0snTtNU4+A0sv5iZCzEJxmXc0wRpVovOFUYIhkXSY0c 3LoxJCUJcgKz0CnU6eqaETVK5CKe1oWQXD6l+VyKmQLRsrYoRvIet9IUBoxDL9U6S0SuKrGEKgRz td6mD3JXCihKPFoB9kCNMMqHM4KRrzBTkrqDmtFKVXE2NcqlnC1LiNhySkUpqKQfGLeeqzVVmeYn 8m6WWQFv9AxG1HXsaPIikug14cpVDJcUTrzRUU1dv4u/zJo+FrxbyyH17VwaukvDPUshqYbO8hfi b5IFHnODtq1j8j3DPHEVNMvrCA2lmEs2Oq6Z+OHMpeqUDbrZvqk/Y6EzyDKBOw/4XZaOWptA3uyf utCNwyEirOg8Vzy8vBY0FK7txZt/3t6tfd9duZE88G+Djn6ba2jW0hX2D9OGHqTWpQ70ZCxnY2vx 6mGq+c8lwN8v86YYFo1biFiLRXrDh6IYQjZV0gor4mxbDQ+4mudZho92yuFRrbh/ds0j2vhnkbMT QVv4j4Siw7O9xLpYOEwBcOiOziCefrXb/YHOrj72oVMCbbQM+mX0LfeCZgek9Qj1PV5pSWhpghFQ oOWhpotqDjHEdZyWGPopZTBZaIQVShaSNMZ2ZMYcJUGYlTEUJLicIxEUPWiPB4D1wGyNbZrL9Jk4 7kM35+1V6z+SaKFBPPpOhNEOhM0mJsTIrM0X3We4Mt1gbevS6AGqzQZtHW3hQ03/Qar9rfbYQeY2 WnmSSSx9tGdb0x1tsJ6XaVGJORg1NsDLapVRdk1S6CHiezQHEx+pmK0bMqpAcIisAugwl5ZQ6VXc vXUFRjhGTMUtmtTffrr4BZH8JucVFMHgFTJHyqZ4uESooFgFvmCFyk0W+w8NHnVqrjlNhNZBgfa6 KtDzAqK6iFH1OYfNBAwc2lz699J+RdCLm/NCbDUN61T5ajLxugKj0upSS6iqZKZur4D2uKpPBoAR xIGsUlVpd0Y5IJNIATVrsCfwqcp77jqV+soHswhEWyBaRNVghm00FKk8bTzPHkUYNjTfQszrTmMp zRVxnDM2w0VdU2FUQAF3xSKbmS8609DpKhAdFsm7ChWDWsRmo6KjDCCAOxUiAw+OUpy0xOHObUbp sABRx8J0H8gvrQbqAazbHJjMZZbp5rQETQ27GpLBPEsLRNUwqRqxsghRUoQSKmBxbs5gU5tT622J /hYqKlvTb1T8sl5JXoDm3bW4V2vcfP4VKzRbrBlWzRYk429KrSg0qpyREKRpi2Lx6fyXD+9/atmT seYLkwjF+Ze3H/CWV7x9f8Ef51/w3w84Yj6+fPjPT5/e/YJR43O6kt5acxKOjoNJGMLHYBxEw4g/ wv7QjByPzUiEMKPjYDTpI45wGPYHT0bEcBJMxrj3MAyikyF/hNHEjBwf2xGEGQ+CyWRAREzG4ejJ iBgNg8nJCHeKjEjgY2RHxpOJGTk+QSJGwSQaExGjwSB6KiLCPiTckCQBXI4H/DEejM3HOOSPEY2M J8HJBGUDWhyMJ09GBKmjjzsdBwPe+ziI+gP+CMdD/ugPcWQSBseTkIkYDsZPRsRkEoyPSRInQRQd 80cYDcxHaKiZkF4mUXAymhAR40H/ydQRoSQiQ8SYDfMkGI0G9mPEHyc0MhmAtIZExCgaDp+MCJDE ZEJaGAWDkxP+iNgUYCQcmZGoz0SMh4aIcPBk3jEASYxOJrzTaGiIOBmZvUcsJBgZIqGTYRCOyDsG URSdPBkRIAkj/HHQH5gtJ6PQjLBNwAjRB0QMTiIi4iTCYEWZNl7hSeHaFFGPVQKdV7qqOuKmGON/ Z/g/2DlbeIRBNOZxFNbEWA5YHCa7cV7leojTHaQLToa3EpIY1Mj4qEXaauCF+z5rKVuFEN7HYI2A SbvETIl3h6YOsM+ZqLy2NLSOg+vq7TK8ak6ECyiKpjXNZ+2lAVRdiedvoQzmmdLS8xu+gU/DKr2S okKkLqWQRrx2wNTc8AMVwErlC10xDtstKDrNMCeHFfYoGZR9EtKqXJyKVwHoBBe0KqYz0TBnr3Lb VDUlFNUNjJ4SrtUCWAVm8kQJc10DWT7VfH8C1OGLKs33WraAoKrQ3XpARzVgxXiEfnBgydRcBJ2J v//eHrrkDuFqBzRMocfsmcOGyc4wfW9VffLmVKBNcWVIp+t8c5xrT73CLh024jRi+hEqQ5SalViK irquzJ1pXTyZJwt4ilepesp0pVhdtiQzPM1cC/Svmv3e4PWveyZpzoz3lMDNDlPkqjmrN68FA1iP rZvSAc4DnOfqy++2LMevG/7m4BT3ZhF3WT9dq4u69YLalop+vPcDtXYQZedUeB2+N+mAe2HH1PF/ b84TtnXULuvjxKl2+RIKJYvHec529eEO9e54lY1+Y00L//R61R62E9yO2S2BSdRSzVKLqcsaDq3M 6+Tr1UyWdLNnxp1DHJeS9sJ+A9RQtQXSCOhHjHxLlSXGZykQmvjWep3aFXgCb0p0MEOsxiFgNphs NLQhHx+q1KIjvGfi8sqVDKqQkLJgyLgc4WDPAuI8QLCD0/r5p2dfiXp2ve/jS5Tfm5W19ZHd0RZn 7RByKDo9vEK1KNwzKOdmxPEPTg9uT+d6K3YT67Jx+obJh9TfukK0dDYLHiKSXg4QHaXkzs6l1bjy fA0pC5qgpsejtGT6oAYR9aT1YViKl0bGnJ0zT3sWBgkiNuHDirSNrd6teXNFCcyFSq/t694g1Tjr bUrCb8lJiMbB0M3NYdG2ortbIn34Epz/nFtBWOu3V4Adth3IkNJWxz5/O3Tg21vudmE+s3RCBHhO EBegtsQDSnzXec8T1oOVDccMXUvaeJCNlZ2/fvnp4/n7953GV+xZ5jYhjvgfN+MtEe2WRW/fZm6Y 2MdsXbLxAYfGO0p33dSm/Losw9j2GQc9J87622uC9ypOENjDMWdTJ/+zZVBo3jUMrtqMTtFpjeUf PmJ9nUsEhhzmmRtNRHV1hoMOgZ/Vz59U7vmPIIOl/513RJNgG5L4dHmroNmCSwpsEdqQXDFtg5Zc vu6ooJpS41cwQXzrpbIMzw1txVnnGTtgTtgFeHepK1MPokAsIvNGxNbxWD7OJKUvIsOEpHwjzRtX YFSaEmtilnS6rSKFATerjBr41MnIHbsrFRsklQc95Huz/BYply6lGws3mOC1ph6mf8Ao8N+ddoYp udNWltXUVjXAGuJaDs+EnZj+QDJ3vc0UAI1Lv3b2snlrR5mm+akDaBwyL2Yn0w42iEy+i7VW85QO rTEI1Gd47EQWHBDRWSznWhRQW761928q1S502PruDG6XQeDFm/zvSoL4f4hI8/WuYqV5B9KULeYs HKVHD5or2zWQLm7lgZuSXlAzttXZoqW3pec+Wdp8qLGVeoXz1IP/Hnww0E4qbjJwPbFZXwv61CD4 3W9b3BPmBAbYcKyD3XHa4cJEnqkqIXqd0Qsc73JPDLo6ROvyyTUPup09znwFId7poOh0ggDsY44d LywYby3d9rKX2h0K+Muzj5NeJv6/dcRL4TWLuiI9DI2kixJP2d/Yd52to40udqPa44s6vvTCRfi0 D1/x3esgLhc3vvhBDE4bXM7tVzCdJmo+nT5/Vt/CuXdjNYbnz/4XUEsDBBQAAAAIAC5T1ULQt9CC xBcAABlWAAA3AAAARXJpY3Nzb25faDI2NF92c192cDhfY29tcGFyaXNvbi92cDhfdnNfam1fYmFz ZWxpbmUuaHRtbNxcbW/bxrL+LsD/gdVBIPuGorl8pxwXaNMGPUBfDtqiFxdFYFDiSmJDkQpJyfFR 9d/vM7skxTfJbu/9cJC0Dsnl7OzszDyzM+tl3nzxzU9vf/2ff32rrItN/OXV6A1dlThIVvdjnoxF Cw9Cum54ESiLdZDlvLgf74rl1BPvi6iI+Zdv0802yIIi2nPlZ57v4iJ/cytfgSYvnmKuFE9bfj8u +KfidpHnovMX06nyNV9FieI7upJx8FamU7wJ1GA+z9RgkaXJ00YNwhAvczXYbmNeqEFWRIuYq0Ee hfh7F0apOlfn0Uqdx+niw8ddWnB1noZP6iJI9kGOy7aI0kRd8KTgmbqI8H5xNUrROwzVkMf4KYIo ztVwmahhFMTpCpe9GuJNofIN/p/zUF1GPA4hJG5WFU/c7jKuLtMEzWlK/JdptlHXTF0b6vpqZKpr S13b6tpRSZl4v15l6W6rrnEHfauRGi2zYMPVaLNSoyRXP8xDNQ7mECvmK57gIVI3QfZB3fBkh79o jCTYq+n8D74o1DRWMZddsd0V6lbdQphtlq6Ewj6q2VbNCjXbzZ/UXM2DzVbN0YcEzzdBHKv5NsBt kUUfOF3SZKXmuzl+NhgRfSBnEcyh7GKeXo2g0iJUC5qnWqzxPyakFhFkLzK1KNSduovVfZCpe1gm VT9ttod5mmHOM/0O/GBp3GxhzihZ4Y6UNs2jf/MZ0/VXR6GNOdnl6bDm0WpdyPa2vStTDdlAqL+t ZaEz0lY570MY5ds4uBo9zYS3HOflvA9Cmkc57jyNwyPscVikcZrNiixIoKkM/tMQWr/bcxItiKdB HK2S2SYKw5jfTTf5NCJP22IucUCjTjdwttk8Wuzwc4TFdvEhjnIwImzMkjThxzgqZXuaiVfw0s1R KL9U4hTCxME257Pq5k68uBplU0i3EEo9kl3CyuVbk0rgl0HcFbpIt3eEyvIx5svi+PEgQJRLwT7O 5nwJ60PFH2fBEhODWjC/pJhNJnfVrSCVvrOVznU4qcq1X1XvMO+ET0v7whvSPCJJZxknVV2N9rwr 4TzIOXUiDlBFUaSb2VTXDBv6IYaYAT2Lx/3qkKL7Mk4fZ2uYgyfHMtB8m4TdMNMJQKQF+YKCh5B+ xsztp1um2crkOx7vOYml/Mh3fKJ+lSFOqJPvoznPhI2VX+AkE/VdxjndAW1JPs15Fi2PBMoFPEBq ZBlsovjpajSbfMP/CH7biY7KD2mSTtQfeBKn6ts0yeE5ubpBI5mWH9dZDSXlH4vFQgFBFN6VngEV TB+jsFjP2PbTHcASZPDhYn13Nao0fVyzhkEMe/vpuDaaLSa1mM0WRi1Wo4X51GI3W1xquRo5zTbi nbYcPOSLCC5xbLs93H1Bbi9Dw5Rcb2bq6LylyEvxUQbRMoRejSiICvCIMCcDU7U4NIMzokHFtPQX g9h2POFk744jrLIoVK6X8Q4XRLMoSIqbq5FCf5ihAHy7DeyrMGYb209KkRZBrAjtl0TrotjObm/B Slvlt8qfVQPxzbU1z9IPO22Rbm7l6BpBKICDZw/MOEgz+saru6ZarPoxE+a0Xh01YvfAVHk1yqtZ Xq3yasvr1ejBKVvc8uqVV7+8Mr26qXhCmioiRQkh8A64CgoRI7rABWw3iKoniVlHYgaJg3i7Dlrm 1o9auuGrujErnbWlE6UUp9QNvE0zTfPVIFGlQGZpjuMO05gljWFq+jCFdXi8Ggkak50fyy75mP75 sZySxvIGx6JRHtySxr4wL6+kcS7Myy9p3O68rkYnJeolkXdhYqxStXdhZidfLaeG1a5JBIguo0+w WrngS4N7g6OWtEabljkDowNjFbnZJjfsARWXpFab1DQviWEfsHI3yS02qIaS3GnztvXzYrht0quR fVEfXpvcGdJHTey3id1aG1ejAavoHbNcVAjrGNEf0MfVCPT5btm2ucTz8CRLYqNDPGj1ihpxzOzQ D5q95G11aM/YvaS2K+qrURVmhw1f0jsd7oOWL2ndLq2noTY4L4vXoT9j+5La71CfjF/Ak7vUDeOX 9rmoFtY154D5ZYTZ7vI1jH8J6ERhHM7DuyQxD0OQxvpyIrEOF6FMJPbhInyJxDn0QIuY3CJxS5IL M/IOFwFKJP6hDcurUY8EdrkIRkFTqncIgoImjisLTCEw+dgwUWmE6VkrgKa0wnQ4shKFNAJy2elZ O4CqtMP0rCFAUxpiOhw+ieJq5FY050wBqtIU07O2AE1pi6nbnxfSMalDvVLihXlVxpierEGp96GR gFcJlCg276raBAqT1cndPsqjeRRHxVPVIhdV/a5O3CVTILEqvk7cSSZRhymTzkhLAf2qUG3XXH9l zE4GOJVF83+JLSNFUAGURFdV7K8G+spOnfRbZNkiAb4ahdFe2/AiixarLNiulQM1HukvKsUaj0Qo C3xqVJRGQTVTZEmmnAqvu36vtSE7ltsRCpWNSrAr0iZtFoRR+sIBKlZVpaEwvmny2sBnOhNYxNGW yqC/OgIVuoqDAq/Jax1kRZDx4IXM6o5REqKYLdIsf2HPkkR4lEJ18RnR0IaG0h0UR9fL1nmw+EB7 Mkk4lbsqyj+WLv13RioxO+nfbZN1FHymy9puzKsjdGO/Q5GbgnfNAfQXsN/FTaFkWiQ6KkorVSrb mmp6Ifs4GhiBkb++oP92towyFNqLdRSHLT6VmzYZ0S6gtkrTVcynCA47qObfct9K1NjTPM0KDCT5 VMbT9XoiJbhkWd9Qe7nxpNB2mvQBuYWhMNTNYgMDPrBcnnOPxWJRjVCErTFeF2EDU1qaBckKsalm IWXos5SEtdgxiTdFyHl6Qd9/LHX6T3Z+cyvkENvbiyzaFs397T+CfSBbx0qeLe7HVP/ns9vbx8fH Us0alf9/5ME2Gn8JXoL4WWYgKHujDA+vJy1TTVRlwjSGy2GyhfDBiueT2e8TYcHJ++MNBN8HmdjE Lx7ImxRFuQc+W+1wUEW2t5olmtEcpovdBg6mVTffxlw8I6bh8p2gmzK9zVUsL8R1TBu6Y7xbCrHu J8so5rm4fwj2q4nslCfw5nvl9/clkwZRiHfnXmVBwc+8A+/qzdXo9lb511OxThPEgQ3WJ/SizTkl 43hY8Fwp1hz+G2OdBowVQ6GFL0e63pHjd/b+/jDO0sd8PPv9MF6Iv/fj2Tjk+Qco8sGx9AfTwY8+ Pqri1VTXmGEwzzdM5jquyXydHd/Ty1PvVbTNM77YpGRV5Bqe/uAa+oPdZsIszzR8z9Qtk9idYQJp iyEWumY4nu0azNFN03KYZ1pdDh+iLA6SUEzC8pqT0DXTNgzH9hzXtV3mG57b7bwJFgg38PF0DxUO 8MAcdMMwdY9ZBpIBz/YM+xwTmgRUEWRPw8Lohuu6nuNbjOmGbntdPkn0IQ7ykxra5rAs2/KYDh3Y hgtVnOk9OAXDNT3DMTyo0rUYzNntXATQQQDRyUsGpfcdxzQZMx1MwPRdp2cHyUJsqC+CDc8C6FRA blgkZjlQggWjMGjE8P0ev3UQU1iDj26KIdPommPongORYBYfinF7Mv3027c/f/X996ceDLpzHMdg 8EmdWbaDHu/VMSKnxAbFM/SjXzQlq7E6jkI8EZxwL37Vhcd39EgcS+Jkt5nzrCImJ8hv/9g8VL8N aPTsv8PwoxZeEQD+DlxNzdUtz7YMw9LhY8Y5nF0Aq61ZcE9mmzZAg5ueQZ6BqqvZugel+qbnmL5v mS8HKjM03fd19AJELd3v2fF5mEJ6nRm+a8KVdAc/fw+ljIGPoYMDpqI7A1q4AFJPQ6yyHM9zPdtE wHNeDlFHs23XQazTTYc558B1Hp+mBYzT7BEZAArWiy1/CZ22xnTPMhizfcf3bNbzpmexyRDuXF33 aDaug9vnoEkOjAXHcRiiowd4/qcBU6zafw+aOhYvQ4RN04WL9tzieWyamidWME93bd0AzHvgegac cE0LSw5MCptY/fBwAZvI5F3b85nPbBjU6QfZ58Gpa1h5bJM5JkK9q7teD1UvA6enAVi6bdm+79vO wBp0AZy2ZhrM0F0LkQnotnrx4Tw4bc31kIJ4pgu/NLEQ/2V0GppBQQWJDK1Ybs96fwmdlsbgSabv Aem+y/Q+t2fRCXlsRCkHivI9xvqRqoNORFcfi4rr+MzzEBXM/wh0UvoNRFLCPBlCpUG/NzOOarKL 49oQMEJnsjbtwNktMlvznG4IRbbgwxFadL7WRZKJRVBjrEllQdu9xNemNc861uPBsWSfNhkWU802 KzJXA36GyBhApSGhrMXynSEy07Ysza3YQS7HYhXdgDnbFgqDgo5ONQ3zTdX0jFn3W69nTmr7//OG iTroAZ6O+botk1ma7fdMixVKazsKVN1L9BE3YMq2bXW4RDebRoTxNctp0ZnkYp1RyQeYfTKuZdtD VjNs24bQJ+M61ZTadKgO4CwVP4tp3rBPIWK4+slbIBqw/Vm7gQnkWm03sBEBu4EAaZtAR4MMWO6G V4aVvO0sUDWq3C7ATXT2Oz7g94K1h1arBriHeDXoA1RFa1ZtMlR0bJAOhSoW2yquUOTx/CE6x3fJ wys6q0n3ebqAp5lOx7R6NyjTQmB2LKu7XXhj9dW8tmWxJFtdZpZudoMA2Fvd1AfO1MQsY4PYZkjD HPeEWGQRg6HCgMAVla3pw8yQOiHWHGuhfN39rG3PLBfrawf+dm9JNly5JLd8BBlj12AG0Ncis2gn oot/ZEuI+R38I2HrksF3alxTuBnGtYXMxW0sAZ49nC5gCqxe35G5V+lPZ1DHs0i2Sizb+6zt71hd uyL6Wz1YG0gNukmA1avWTFrb22Qwh9l1JuY7dq3XUtHIt9xe6oFBGvmdbQwbDNGakspqPFQRQ2Se jgDSWCS84UTBoIzXr93E1JjhfNYOYNvGQABwezbTLQTjdp6AwtnprtmG4SPgt1cAhOferqprkw+0 Q4UFo3RjgOehsKhrASxUbNC6zPJtEXkq8yLFGM4BfPCr4W1otjMYU5DuIEJUXkXLxecdBgzgq12+ UebbLeYt29HaxSBKA7tL5fcKC1oEehkl83Vb89sVg6l5ejcKmJ5coeSDOBAyZDEHy7vRqPIQPAYd Rcdq4dcOACPbw1FFR4Fs11kFksDTcvGZekC3DKCw2oU3EGO1TEb1dC8L9LAgt6sAQ/NY1wEM5G3t PQPgzOxvQZgiO61Gs4bLd7cJa1aXKh3j2zLtrJ3NGgwmlu4LvMsHB6mi/Vmb3qctrJZRLQCzV9th nTXb6EeZ0AvYqLQB0U78t3spIGoCrw6qNcg8s5tSMNfS6tzOha8NotWE955ArWvmmcrOdTSvNiyc 1B7eMaKtIK9mR+Xw550DIChqeru4R7pv97JA3+hvBjpWF7AmymzWDiW+ZvYyAMaQKbRDDoWJXu5p 6PSZ0LEeULcGA4BJm4Z1GghPGS4WHNqCbHiKPciM0WrC6i0A2l74bLYA3o/o/IQ4osFjvih4qNwr umyJNnTipKDTGZNJeQJjzouCZ/KoR+tESP0kKepHeQaQtNBp2kf88cRCfIFzz6pzHvRdW83marTc JeJTPxoqWfG3gvoanW7qA0xogJy4EUePwix4fBC/k7q+qc4GdZj8IKS43pQsyuMrm27vbuecF7vt wz7Cq3Jsmj2GTvijUp7laZ3i0X5ZiKm8Jbpr6kF/6lM3K14duPn66Z/h9bhxZnJ8cyNmrzS1fmmk X4ng+SEa3E5DXNRY86WctTBanr+Ngzz/MdhwOt1zqEaeyINdP6ePk5kymcc7PqXDY4r4tY28pfNj zUZ5lG2i1iyEeCWHRr8z1GkY/troMHwK7Hk2FQaavPon0U58Gl3XdBD412Ghm+fcml1E81sex0Tf OnB3SSlVhxbNsTQj2SUVH4oKi0wCOvP0XbGhHkW240cBj2ipXEsvUL4A3G+UEBMveOlnJStg6Z7v g/haQuP15HcJs/eTm5NPXnJHinPSJQmpkunppNavLzmpRYFKeYyKtRIo4nxtuiy51CGCjnHJGS1L gCBcdc51TcqP/epOl8T+UcTUd4K0BtNhmQUCC99Eq6jIZ4qlKvJjitlYCedjcRhPUXic8//rUBfH eiVHKmnrQTR5VxpVVdhA5NAIxRVF6SNS6kHZ+B4BI9eCMPweiucJz64bzNQKLCfvfMkf2edrwee7 IAljnkkRPu549iRCTD/kNt/JINNYmaRMFOPelcoIfwsQca4rLKvw7woZMrj+kae0VgjfnlxPlNfi eGLl3b9XHd/jxeRmIuU7LWMv8/jTSBhfc25K2F03Fj8BPaXG3ulFY0BB98yAv4Hm+iRfZXmxLkmb n3ipymGxy/b8V6QPs0ml4ZMNRaevMh7M5GcQp6OlqkInnesjpar8PHbWOA1aMykPijfPmU59/Xh6 /9WnKJ8dxL8mcUqQlChRPsy3OdIbZd+i+EgTLp6IgL46Rj5DRBU3+S8qzA7116vjKCEesnPlKaqy TaOk+EV8Ba2KuPLf8qvSmlF/QoMzsXWlhuBLgSMYNCAj9fyLePprEKw4pckm3eWcFp2K3Q/U8NO+ QtTf5bgr2gx3xWAGdXp9zUtUUoq5y+dB1jxV3Ek+JpKoRFXdQxPLnlZ+XUIJJ/3jA5NLA2Oi9cjC tt9EyyXPeLLg11xDWaMqdCabMN2LKF16QX1KJ4HTL9Ck/Pmn8oVcusg/MmR+WdJYZynxh6gn6NFk ZUj/aSlzVJlMSXKqtM6SI2mQtBU1XOVhHhXlCegTgqmTDHBCaASQu2YXSXipB02oMQ5StxwQoZPc XxXKmIJhzUYr0nfRJx5eGzdoH9foU5U3fPPlWIapqnt197ozQ6mI76kMkRk7OL25RX8lypU3u5j4 ECes6XiNCaG5ignUjpXtWkgaoTyI3pDS716/jm7k1wJkmFNkf1ghdBXA+0OxRrmDwJWTyuUHG6UV 8P4FZCU/kWOdCGU/8m/f97tMz9Lq9YINx4ru708uRUlWUkTJjtckUMM7+jCD8iAkQeBXykKKEK1l sUOjTHKlGgaPSdMDsLjWDKnXGsGrxwyqbnMTmhCsqE/pBZIP2YHmSqHzYYFEuBBTaz6/ET5+p7x+ fWq8OZUFNF7XQSsvkQ566qYq0U2rXwsI53vpdS8CcWPEun1A54K4Kd3/dnN0rW3EsPf9ChFYc8tH 79ItMNLrvRTGBi0bbOwl5KFrstQjJCHtxmDkv08f9lnO+ZyWbS/LQzj7JFmyJUvyYVUpfTo58aQC mUo1/0psSCunonDuURJqWk9HDb5vEaM8osZaklD8tCCtmp6QJY0TE2evrCZJgsIo3Krbp4xTnFqM 2JbVgXJlKrjcfF/N190H+EomeCN+AtBh0NVMoGJF96dljpAdyyIH/Jq0zM9qsyX6WVL0YSvHLyBX KgbZkXkfJhRMJQuw3W2+cWTrjCnTG0aSCvQ0Q4GY/VYx1NDz2tfisKOigB5kB+zkgcsbuhTGqzZk ikqlLL1lSXlF2aN5vMCjaZHcr/Nccm+3o7Kji4O2uznjnRxrC3Qcvs8PhUKS7eHT+P5ilst/wrY1 RDbLOMu5uPE/CwHNGsPRt5+urygWKbfEfzgIdh2gNKJGvpbcEjZKuK0PsCQcN5wNSrqErH50nSp0 81LzQajtNOtGnBXNQZHWtJhJSFooojc/H49fP52uFuvlw91w1CSI+ezjCVqGgg4bLVu7PQySm8LE kFlJZGbwP4eX3CGi4n/Pdngm7xcPHPyGevnGrHBrW8z5lVPj6S8ZZALFAKmzSBMaZ0C0pYkP+1l9 qvlXkuBXhSS/oyKW9caSRNq+Rv9LxovCjIt9MwmMnOW0GZc+hYqYGAWjHFsaCSmNhFKBwmNvv197 caqkh7BeAc3svN6j3AEOAhAc6Sp1R46Yjty9DW/ewgSm3dvNbsGT0x0E93AtJVTm9+srJHeJPoSO jLP6ewFB6XvBuS3EiY9UEaEShS3n5gfc0qn6RUeXp+hUzhVqCFu1yR4wE4wsbHl3Vn3+8NpX7sS2 xc4RPUmLKyWkh6MCCB4iAjMGrgsGriyC58wCm/lF8BmicnxZmIDL6AC8CFQlIUpbjF2+ojyV9hlw /TLw9/AbQ6gFQq+mX9Pcj6t3NSpO/fjg9S5sO5bFqx1y6/kNW83V9M9lbhUKB5cysM9+A1BLAwQU AAAACAAvU9VCf5j4b9IXAADnVgAAPwAAAEVyaWNzc29uX2gyNjRfdnNfdnA4X2NvbXBhcmlzb24v dnA4X3ZzX2ptX2NvbnN0cmFpbmVkX2hpZ2guaHRtbORc/W/bRpP+XYD/B1YvAtlXiubym3JcoE1b 9IB+vGiLHg5BYFDiSmJCkQpJyfGr6n+/Z3ZJil+S3R4OeHFJYotczs7OzswzM7ta5vUX3/7y5vf/ /ud3yrrYxF9djV7TpxIHyep+zJOxaOFBSJ8bXgTKYh1kOS/ux7tiOfXE8yIqYv7Vm3SzDbKgiPZc +ZXnu7jIX9/KR6DJi6eYK8XTlt+PC/6puF3kuej8xXSqfMNXUaL4jq5kHLyV6RRPAjWYzzM1WGRp 8rRRgzDEw1wNttuYF2qQFdEi5mqQRyF+78IoVefqPFqp8zhdfPi4SwuuztPwSV0EyT7I8bEtojRR FzwpeKYuIjxfXI1S9A5DNeQxfooginM1XCZqGAVxusLHXg3xpFD5Bv/mPFSXEY9DCImLVcUTl7uM q8s0QXOaEv9lmm3UNVPXhrq+Gpnq2lLXtrp2VFImnq9XWbrbqmtcQd9qpEbLLNhwNdqs1CjJ1Q/z UI2DOcSK+YonuInUTZB9UDc82eEXjZEEezWdv+eLQk1jFXPZFdtdoW7VLYTZZulKKOyjmm3VrFCz 3fxJzdU82GzVHH1I8HwTxLGabwNcFln0gdNHmqzUfDfHzwYjog/kLII5lF3M06sRVFqEakHzVIs1 /mFCahFB9iJTi0LdqbtY3QeZuodlUvXTZnuYpxnmPNPvwA+WxsUW5oySFa5IadM8+hefMV1/dRTa mJNdng5rHq3WhWxv27sy1ZANhPrbWhY6I22V8z6EUb6Ng6vR00x4y3FezvsgpHmU487TODzCHodF GqfZrMiCBJrK4D8NofW7PSfRgngaxNEqmW2iMIz53XSTTyPytC3mEgc06nQDZ5vNo8UOP0dYbBcf 4igHI8LGLEkTfoyjUranmXgEL90chfJLJU4hTBxscz6rLu7Eg6tRNoV0C6HUI9klrFy+NakEfhnE XaGLdHtHqCxvY74sjh8PAkS5FOzjbM6XsD5U/HEWLDExqAXzS4rZZHJXXQpS6Ttb6VyHk6pc+1X1 DPNO+LS0L7whzSOSdJZxUtXVaM+7Es6DnFMn4gBVFEW6mU11zbChH2KIGdC9uN2vDim6L+P0cbaG OXhyLAPNd0nYDTOdAERakA8oeAjpZ8zcfrplmq1MfuDxnpNYys98xyfq1xnihDr5MZrzTNhY+Q1O MlG/zzinK6Atyac5z6LlkUC5gAdIjSyDTRQ/XY1mk2/5++CPneio/JQm6UT9iSdxqr5Jkxyek6sb NJJp+XGd1VBS/rFYLBQQROFd6RlQwfQxCov1jG0/3QEsQQYfLtZ3V6NK08c1axjEsLefjmuj2WJS i9lsYdRiNVqYTy12s8WllquR02wj3mnLwUO+iOASx7bbw90X5PYyNEzJ9Wamjs5birwUH2UQLUPo 1YiCqACPCHMyMFXJoRmcEQ0qpqW/GMS24wkne3ccYZVFoXK9jHf4QDSLgqS4uRop9IcZCsC328C+ CmO2sf2kFGkRxIrQfkm0Lort7PYWrLRVfqv8WTUQ31xb8yz9sNMW6eZWjq4RhAI4ePbAjIM0o2+8 umuqxapvM2FO69VRI3YPTJWfRvlplp9W+WnLz6vRg1O2uOWnV3765SfTq4uKJ6SpIlKUEALvgKug EDGiC1zAdoOoepKYdSRmkDiIt+ugZW79qKUbvqobs9JZWzpRSnFK3cDbNNM0Xw0SVQpkluY47jCN WdIYpqYPU1iHx6uRoDHZ+bHsko/pnx/LKWksb3AsGuXBLWnsC/PyShrnwrz8ksbtzutqdFKiXhJ5 FybGKlV7F2Z28tVyash2TSJAdBl9gtXKhC8N7g2OWtIabVrmDIwOjFXkZpvcsAdUXJJabVLTvCSG fUDmbpJbbFANJbnT5m3r58Vw26RXI/uiPrw2uTOkj5rYbxO7tTauRgNW0TtmuagQ1jGiP6CPqxHo 892ybXOJ5+FJlsRGh3jQ6hU14pjZoR80e8nb6tCesXtJbVfUV6MqzA4bvqR3OtwHLV/Sul1aT8Pa 4LwsXof+jO1Lar9DfTJ+AU/uUjeMX9rnolpY15wD5pcRZrvL1zD+JaAThXE4D++SxDwMQRr55URi HS5CmUjsw0X4Eolz6IEWMblF4pYkF2bkHS4ClEj8QxuWV6MeCexyEYyCplTvEAQFTRxXFphCYPKx YaLSCNOzVgBNaYXpcGQlCmkE1LLTs3YAVWmH6VlDgKY0xHQ4fBLF1citaM6ZAlSlKaZnbQGa0hZT tz8vlGNSh3qlxAvzqowxPVmDSu9DowCvCiix2Lyr1iZQmFyd3O2jPJpHcVQ8VS0yqep3deEumQKJ 1eLrxJ1kEuswZdIZaSmgXy1U22uuvzJmpwKcykXzf4gtI0VQAZREV63YXw30lZ065beoskUBfDUK o7224UUWLVZZsF0rB2o80i9aijVuiVAu8KlRURoLqpkil2TKaeF11++1NmTHcjtCoWWjEuyKtEmb BWGUvnCAilW10lAY3zR5beAznQks4mhLy6C/OgItdBUHC7wmr3WQFUHGgxcyqztGSYjFbJFm+Qt7 liTCoxRaF58RDW1oKN1BcXS9bJ0Hiw+0J5OEU7mrovxj6dLfM1KJ2Un/bpuso+AzXdZ2Y14doRv7 HYrcFLxrDqC/gP0ubgolyyLRUVFapVLZ1lTTC9nH0cAIjPz1Bf23s2WUYaG9WEdx2OJTuWmTEe0C aqs0XcV8iuCwg2r+JfetxBp7mqdZgYEkn8p4ul5PpASXXNY31F5uPCm0nSZ9QG5hKAzrZrGBAR9Y Ls+5x2KxqEYowtYYXxZhA1NamgXJCrGpZiFl6LOUhLXYMYk3Rch5ekHffyx1+is7v74Vcojt7UUW bYvm/vb7YB/I1rGSZ4v7Ma3/89nt7ePjY6lmjZb/7/NgG42/Ai9B/CwzEJS9sQwPryctU01UZcI0 ho/DZAvhgxXPJ7O3E2HBybvjDQTfB5nYxC8eyJsURbkHPlvtcFBFtreaJZrRHKaL3QYOplUX38Vc 3COm4eMHQTdlepurSC/EdUwbumM8Wwqx7ifLKOa5uH4I9quJ7JQn8OZ75e27kkmDKMSzc4+yoOBn noF39eRqdHur/POpWKcJ4sAG+Qm9aHNOyThuFjxXijWH/8bI04CxYiiU+HKU6x053rJ394dxlj7m 49nbw3ghfu/Hs3HI8w9Q5INj6Q+mgx99fFTFI12zPV+3LN00DRt/XeYf39GzU+dVtM0zvtikZFSU Gp7+4Br6g93kYRoMHHSd2a6nG555hgdkLYY5eC7zDIuZjmWZru/aPQ4foiwOklBMwfKaU2Ca7uvM 85jump5tmU5vBptggVgDB0/30N8AC12zLM/2HE83XWYyw7G8czxoCtBDkD0N8rE93XU9ZlmOaTnM s40unyT6EAf5SQltISzP9xxTBxfL9yzrTOfBgQ3P9WBK3XUM3fE8p9u3CKCAAIKTfwyq0XANHz7g WvAD2KKnAslB7KQvgg3PAuhTYO2MRnXP1g3DZ5aPH5312K2DmMIZfHNTDFlF7Acxz/Vt04Zl4aBd Fr/88d2vX//442lQ1/RNz4Aj+J5noDO5wjt1jIApIUFhDP3o+6VkNVbHUYg7QhGuxTdcuP2ebolj SZzsNnOeVcRk//z2/eYBiQ1sqP4OH9YIMg0O52kgzqgFW8SBv4Fa5mqe6fumrbu+4Xp2TzHPYpaZ GrNt2/V13wH2jJ6xn0Gs4WlQsOcz23JN3WR/Aa+WpzmubloArOE5tv7X4cpsuLvuMGCFmZbrWmdZ XESr4Wuu49mOzxzmOj6Q83KwQn865NcdaN+3EK967n0Wq0zXHMvQfRtAtXzT6Mer56Bq2Zrv645u mbYLuPtnGLwMqczQmA8hfCAfcUPvh75ngWoyzUXYgCqAPd1D/HwGqIalmboD1/FtnbzH/XeHqUjl fw+ors885BPkFc/xzyXGC0B1NCjIcQ3XYbrt2OfS8zmgmoamW45umMjKyGz91HwBqL7mu2iyEWsM 23b6+ehZpBpIznAKFAXobXhef/gXIdVEyEAusS0D2Zkx3zmXGYeQakOByIzwNMuwbF3viXAeqYaG /KMDE2jXfd/vDfssUh0NhZHtQWyYzxmI1H8JqpZmU2XBDBehk7msn+SfhaqtmT5KLM+0TNPS/R7Y u0h1NUYBFqJToDOZ9W8JVSrQAU8qqSdDEDUwD58d1WQXx6UiTM3Qu9awEZh0o0XmaIbVLeKY4UMt fovO12zWZWcargX1NeksQ3N7HmgzAmnDQoYp+7TJUNqg0q7IXM2BPw6QMVd3UYcea8F8Z4jMhCuh XjrWcjkWq+gGDNy2WRgUdLyqaeRvq6ZnDL3fej3DUtv/nX9M1EGfQPIBFlpGREMX4szRTaxOWmSe ZtjdfI/gYiJatGyNktrp2tpzXPiO06IztV5kYeQTcKja2BZCx4AVEZdRDPknY4P9EB2qLThPxQ+S ecM+hmjl6ifvIdE847NyCxTVmtfxCq+LbNdF+GAdp3B6TsFQFmme03EKu1cGWFiCa20yS+utxD1Y w6rx7yFSDboEszzQ1RbUIeggnYnEpnlV2EEAMDx/iM7x4bGOcawFa9B9Fh6BdUIb2ICZ4XRtDRxa HUP7PfQjc2t2x85Ob7MDS9iu1zia3wtNjt9CNGODyEe9hKBwwrPuDaYDg0q1igol0zAz26FIdDwJ pbuflSswlNNGO2egwutVtYZtam7LGyg8uL1yA2WE3nYaHSu7blVnoHJEsu+kDBRxXTo4U417DMiG cW9hDm4jY3j2cLXhIgHV5QGilm4MkRmOJ0JXJZbtfVYO4egaaxeMNm1C9WAPt2kBGhnd720OmlC5 ZXf8wbB6QcTDIH7bbww0dP2GYZBGuWgbwwakeoSd3MHQvSEyT0eEaSQVb7jOMGyHQtXJH5jhfFYO gVQuQNiOEF2H8BEg2hGeNN/bcjUM1KhGdwHBemnFtT1ove05SEdOlx+WwSIuVRHCZIO2ZhYNW1cG tL8/GCJMrIk1twa/odnOYMRxPRvxo/Ixyi6fV5AwmNuJ3yZW8qybzy2U6E47mLiaa3TJPNQQXosM 0VnvlxquT2clW3RUVHZ9wvQQJarqzhRnVIZs6KA+MBqLSgSXQdfRkV382iVgdns46uhYLtl1WYKi 8pRePg+fMDWzY2q7t8EGSOmtWAIsmr3dVVSLbndB2d/RNwyrm1yQqnqlCwKTWZkPZraGNw/cJu6Z 2EYY8AXwshqlgWcNRhtL98Us5Y2D0tP+rDwBoVvvVBB27zsBRtVYb8HZXYNYjtnZv6JVSO97DVSx lqZ3fYHZXZdhrqXVhSIKFncQyiZc+YR4OOiZZaTraF5tZrisPbx7RdtSXs0Oecj+vAoIrAk6q00E VLNnGg+htV1AOJrZKxVNWq+144yv9bYfsHKEdduBBtDVeyFEp5ecKoew6YuFQYeg7cy6oqSN18Gq wNE9sRFW+Y09yIxR4mH17gPtbPy/3X14N6LTIOLACY/5ouChcq/osiXa0PmZgs6aTCbleZI5Lwqe yYMrrfMt9Z2kqG/liUbSSqdpH/HHEwvxPtE9q06t0Ft6NZur0XKXiBcXaahkxd8I6mt0uqmPY6EB cuJCHKQKs+DxQXyZdn1TnXTqMPlJSHG9KVmUh3E23d7dzjkvdtuHfYRH5dg0ewyd8EelPJnUOpOk /bYQU3lDdNfUg/7UZ4hWvDo+9M3Tf4bX48YJ0PHNjZi90tT6pZF+J4Lnh2hwOw1xUWPNh3LWwmh5 /iYO8vznYMPprNKhGnkij6n9mj5OZspkHu/4lI7CKeIrJ3lJp+GajfJg3kStWQjxSg6Nfmeo0zD8 vdFh+Ezb82wqDDR59c/Vnfg0uq7pWPPvw0I3T+01u4jmNzyOib51fPCSUqoOLZpjaUaySypeexUW mQR0guuHYkM9imzHjwIe0VK5ll6gfAG43yghJl7w0s9KVsDSPd8H8bWExpeTtxJm7yY3J5+85I4U 96RLElIl09O5s99fcu6MTp0pj1GxVgJFnBZOlyWXOkTQoTQ5o2UJEISrzim1SfnqYt3pktg/ixj7 vSCtwXRYZoHAwrfRKirymWKpinw1ZDZWwvlYHC1UFB7n/H871MWxXsmRStp6EE1elUZVFTYQOTRC cUVR+oiUelA2vkfAyLUgDH+E4nnCs+sGM7UCy8k7X/JH9vlG8PkhSMKYZ1KEjzuePYkQ0w+5zWcy yDQyk5SJYtz3pTLCPwJEnOsKyyr8u0KGDK7v85RyhfDtyfVE+VIctqy8+23V8R0eTG4mUr5TGnuZ x59Gwviac1PC7rqR/AT0lBp7pweNAQXdMwP+AZrrk3yV5UVekjY/8VKVw2KX7fnvKCdmk0rDJxuK Tl9nPJjJlzpOB2VVhc5t1wdkVfmy76xxtrVmUh57b56anfpYb9TPv/4U5bOD+L8xTgWTEiXKh/k2 R7mj7FsUH2nCxRMR0DvUqGuIqOIm/3+I2aF+F3ccJcRDdq48RVW2aZQUv4l3ulURV/5LviNbM+pP aHAmtq7UEHwpcASDBmSknn8Td38NghWnNNmku5xT0qnY/UQNv+wrRP1djruizXBXDFZQp8fXvEQl lZq7fB5kzTPSneJjIolKVNU9NJH2tPJdGSo46b9SmFwaGBOtRxa2/TZaLnnGkwW/5hoWOapCJ8wJ 072I0qUX1KdyEjj9Ak3Kn38qX8jURf6RofLLkkaepYUARD1BjyYrQ/ovS1mjymJKktO66yw5igZJ W1HDVR7mUVGe5z4hmDrJACeERgC5a3aRhJd60IQa46B0ywEROpf+daGMKRjWbLQi/T76xMNr4wbt 4xp9qvKab74ayzBVda+uvuzMUCriR1qOyIodnF7for8S5crrXUx8iBNyOh5jQmiuYgK1I7NdC0kj LA+i16T0uy+/jG7kuw9kmFNkf1ghdBXA+0OxxrIHgSsnlcvXT0or4PkLyEp+osY6Ecp+5N++73eZ nqXV64QNx4ru708uRUVWUkTJjtckUMP39JoJ1UEogsCvlIUUIVrLxQ6NMsmVahjcJk0PQHKtGVIv WvL1mEHVbW5CE4IV9Sm9QPIhO9BcKXT+TzdH19pGDHvfrxCBNZev3qVbYCTXeymMDVo22NhLyEOX ZKlHuIQ2HYOR/z5Jts/ync9p2fayPISzT5IlW7IkHxYmk4/lgUWT7Zx1fAaDgevsubSAxqsrqNUS raAObQiq5+F5htCOlVVYZMRixKo/MOcMLLkrYvp0duZIeTLlYv6F2BBXTkFh5lAialpNRwV+bBEj P6HGUhJf/LggrZoekSWOExLnKKwmSoLCKNyq26eMU5xKjNCW1YF8qwq42j1uV2X3AN/IBG+1nwB0 GHTRFKj00sN5niJkx7DIAb8krednu9sT/SQq+qiV4x6kQsUgOTHvo4iCiWQB9ve77xzZWmNK5IYR pQJ9yZAn5qBVDDH0qvK1OOw4y6APSY2d1HN5I5vCONWGRFAphKW3LCmvKHs0h+d5NCmS/XVe6tzb 7qjs6MKg7W5OOSfH2gIdi+/yQ00hyvboeXx/VZvNP2HbGCKbZZjlVLvxPwsBVYnh6LvPN9cUi+R7 4t8fBLtqKI2okS9Zt4SNOtyWB1g6HFecDep0CVn9ZDtF6Oak5oNQ06nKRpwVzEGR1jxb6JA0E0Rv fz4dv3o6367LzeFuNG4SxHz26QQNQ16HiZaN3daD5KYwIWRWEj0z+J/CK+7QouJ/33Q4Jh/WBw5+ fb18q7a4ta1X/Mqq8fyXHmQK2RCps0hTGmdItHUTH46L6lTzryTBrzOd/I6zUNYbShJp+xr/Lxkv CjPJjs0kMHCW02Zc8hQqYGIUjHJsqXRIqXQo5Sk89g4GlRenuoAI6xRQLWbVHmUPcBCA4EhXqTtw xHTiJrF/jximMO8ud/drnpzu0LtVbCihMn8or5HcFfoQOjJOqu8FBCVvOaemrCg+Un2HQitsvlI/ YEmn6pedpSi20SmsK5QQpgaVOWAmGL2w+d1F8eXjG1eHFNsGO0X0KC2u+xAfjso5OIgAzAS4yhnY Ig+OMwOsVpfeZ4jC8mVgPC6DA/AiUM2HIG1t7PorynNpXwBXYwNXVaAxhFgg9GryNc39pHhfoeLU T2qv7/22ZVl7tTq3jl+/1VxN95ynRqFwcF3U9sVvUEsDBBQAAAAIAC5T1UKHuX60xxcAAFZWAAA5 AAAARXJpY3Nzb25faDI2NF92c192cDhfY29tcGFyaXNvbi92cDhfdnNfeDI2NF9iYXNlbGluZS5o dG1s3Fxrj9vGkv0uQP+B0YWhmTXFab5JjSdA4sTIAnlcJEYWC8MYUGJLYkyRMklpPFfRf99T3aTE lzRj3/1wYb9INqurq6vqVFX3NP3qmx9+e/32f//5o7Iq1vG3w8EruipxkCzvRjwZiRYehHRd8yJQ 5qsgy3lxN9oWi4kn3hdREfNvX6frTZAFRbTjyu8838ZF/upGvgJNXjzGXCkeN/xuVPBPxc08z0Xn byYT5Xu+jBLFd5iScfBWJhO8CdRgNsvUYJ6lyeNaDcIQL3M12GxiXqhBVkTzmKtBHoX4dxtGqTpT Z9FSncXp/MPHbVpwdZaGj+o8SHZBjsumiNJEnfOk4Jk6j/B+Phyk6B2Gashj/C2CKM7VcJGoYRTE 6RKXnRriTaHyNf7MeKguIh6HEBI3y4onbrcZVxdpguY0Jf6LNFurK11dGepqODDVlaWubHXlqKRM vF8ts3S7UVe4g77VSI0WWbDmarReqlGSqx9moRoHM4gV8yVP8BCp6yD7oK55ssU/NEYS7NR09hef F2oaq5jLtthsC3WjbiDMJkuXQmEf1WyjZoWabWePaq7mwXqj5uhDgufrII7VfBPgtsiiD5wuabJU 8+0Mf9cYEX0gZxHMoOxilg4HUGkRqgXNUy1W+IMJqUUE2YtMLQp1q25jdRdk6g6WSdVP681+lmaY 85Tdgh8sjZsNzBklS9yR0iZ59C8+1Rl7cRDamJFdHvcrHi1XhWxv2rsyVZ8NhPqbWhY6I22V896H Ub6Jg+HgcSq85TAr570X0jzIcWdpHB5gj/08jdNsWmRBAk1l8J+a0Ox2x0m0IJ4EcbRMpusoDGN+ O1nnk4g8bYO5xAGNOlnD2aazaL7F3wMsto33cZSDEWFjmqQJP8RRKdvjVLyCl64PQvmlEicQJg42 OZ9WN7fixXCQTSDdXCj1QHYJK5dvTCqBXwZxW+gi3dwSKsvHmC+Kw8e9AFEuBfs4nfEFrA8Vf5wG C0wMasH8kmI6Ht9Wt4JU+s5GOtf+pCrXflG9w7wTPintC29I84gknWacVDUc7HhbwlmQc+pEHKCK okjX0wnTDBv6IYaYAT2Lx91yn6L7Ik4fpiuYgyeHMtD8mITtMNMKQKQF+YKCh5B+qpubTze6Zivj n3i84ySW8ivf8rH6XYY4oY5/jmY8EzZW/oCTjNU3Ged0B7Ql+STnWbQ4ECjn8ACpkUWwjuLH4WA6 /oH/Ffy5FR2VX9IkHau/8CRO1ddpksNzcnWNRjItP6yyI5SUf8zncwUEUXhbegZUMHmIwmI11Tef bgGWIIMPF6vb4aDS9GGl1wxi2JtPh5VRbzGpxay36NRi1Vp0n1rseotLLcOBU28j3mnDwUM+j+AS h6bbw93n5PYyNEzI9aYmQ+cNRV6KjzKIliF0OKAgKsAjwpwMTFVyqAdnRIOKaekvBrFtecLJ3i1H WGZRqFwt4i0uiGZRkBTXw4FCv3RDAfi2a9hX0XXb2HxSirQIYkVovyRaFcVmenMDVtoyv1H+rhqI b66teJZ+2GrzdH0jR9cIQgEcPLvXjb00o2+8uK2rxTo+ZsKc1ouDRuzudVVejfJqllervNryOhzc O2WLW1698uqXV51VNxVPSFNFpCghBN4CV0EhYkQbuIDtGlH1JLHekliHxEG8WQUNc7ODlq758tiY lc7a0IlSilPqBt6mmab5opeoUqBuaY7j9tOYJY1haqyfwto/DAeCxtTPj2WXfEz//FhOSWN5vWPR KPduSWNfmJdX0jgX5uWXNG57XsPBSYmsJPIuTEyvVO1dmNnJV8upIdvViQDRRfQJVisTvjS41ztq SWs0aXWnZ3RgrCI3m+SG3aPiktRqkprmJTHsPTJ3ndzSe9VQkjtN3jY7L4bbJB0O7Iv68JrkTp8+ jsR+k9g9amM46LEKa5nlokL0lhH9Hn0MB6DPt4umzSWe+ydZEhst4l6rV9SIY2aLvtfsJW+rRXvG 7iW1XVEPB1WY7Td8Se+0uPdavqR127SehrXBeVm8Fv0Z25fUfov6ZPwCntymrhm/tM9Ftehtc/aY X0aYzTZfwfiXgE4Uxv48vEsSc98HaeSXE4m1vwhlIrH3F+FLJM6+A1rE5AaJW5JcmJG3vwhQIvH3 TVgOBx0S2OUiGAVNqd4+CAqaOK4sMIHA5GP9RKURJmetAJrSCpP+yEoU0gioZSdn7QCq0g6Ts4YA TWmISX/4JIrhwK1ozpkCVKUpJmdtAZrSFhO3Oy+UY1KHrFLihXlVxpicrEGl975WgFcFlFhs3lZr EyhMrk5ud1EezaI4Kh6rFplU2e2xcJdMgcRq8XXiTjKJdZgybo20ENCvFqrNNdfnjNmqACdy0fxf YstIEVQAJdFVK/YXPX1lp1b5LapsUQAPB2G009a8yKL5Mgs2K2VPjQf6h5ZitUcilAt8alSU2oJq qsglmXJaeN12e60M2bHcjlBo2agE2yKt02ZBGKXPHKBiVa00FJ2v67zW8JnWBOZxtKFl0OeOQAtd xcECr85rFWRFkPHgmcyOHaMkxGK2SLP8mT1LEuFRCq2Lz4iGNjSU7qA4jJWts2D+gfZkknAid1WU fyxc+n1GKjE76d9Nk7UUfKbLyq7NqyV0bb9DkZuCt/UB2DPYb+O6ULIsEh0VpVEqlW11NT2TfRz1 jKCTvz6j/2a6iDIstOerKA4bfCo3rTOiXUBtmabLmE8QHLZQzb/kvpVYY0/yNCswkORTGY+x40RK cMllfU3t5caTQttp0gfkFoaiY90sNjDgA4vFOfeYz+fVCEXYGONlEdYwpaVZkCwRm44spAxdlpLw KHZM4k0Qch6f0fcfC0a/ZedXN0IOsb09z6JNUd/f/ivYBbJ1pOTZ/G5E6/98enPz8PBQqlmj5f9f ebCJRt+ClyB+khkIyt5YhodX44apxqoy1jUdl/14A+GDJc/H03djYcHx+8M1BN8FmdjEL+7JmxRF uQM+G+1wUEW2N5olmtEcpvPtGg6mVTc/xlw8I6bh8pOgm+isyVWkF+I6og3dEd4thFh340UU81zc 3we75Vh2yhN4853y7n3JpEYU4t25V1lQ8DPvwLt6Mxzc3Cj/fCxWaYI4sEZ+Qi/anFMyjoc5z5Vi xeG/MfI0YKwYCiW+HOV6S453+vu7/ShLH/LR9N1+NBf/7kbTUcjzD1DkvWOxe9PBXzY6qOIV03Tm MUv3EBaZ4RrMdw/v6d2p8zLa5Bmfr1MyKkoNj92D7t4+8piAicNsw2Am80zL9z3POcMEwhZ9LJhm mI6v+67JmO/blq/rbQ4foiwOklDMwfKaczB107c9Bxw8zzYtt9N5HcwRbeDi6Q4a7OFB27eM2SZz fduGCI7hG+eY0CSgiiB77GfETNNmruWZvmFaHqbT0UYSfYiD/KSIRnfdci0dwnjMMUzPcDoGKXv3 jm366OrqtmtYDOowzXbnIoAWAghPbtKrTMdyXZ85jmOZtuMYnt3PQuyoz4M1zwJoVWDujDpgGgOG YQxmAmfmdxiugpgCG7x0XfRZh2kWpmQyHd1NZlmm47V5/Pbnj79/9/PPpx7MMZnp+66rY3zdc12a x3t1hOAp4UEhDR3pZ03JcqSOohBPhCjci5924fENPRLLkjjZrmc8q4jJEfKbT4Zj3Vc/Eqj17XsL EQYN2CIOfAFqDc2GX7iG7lqGDVcxvwC0lmb5jgesAvu6Y3vWZ0LW13zLNFzTAuBN3/oMvLqIOQYz IL0BCWCcz0erp9mmwTydmQ7iF3h8EVaZ5go5DFt3HBta7Lj6BaC6GsPwvmnbluXYiBfPh6mnGa6n W4g2PmzIWEcBT4FU9wAIw3Z9B5FKpxDzb2HU1CysKJECEK0s+KvbUeeTCHU0w7egS9e1HAuxszOl Fj51hFvA2IALGb6JUPmfCE6RwL8Inr7nwzxAFXKBA3R8CTxtF0HTc5nPEMGsjoWfgCcQ4rg6khAS CVzU7ohwHp86o/Ci2wa6OR4zuknkaYC6muX6nuPaCE6Ob1hfnEwdz7Bcx0KCZ4hT53JhH0AtzSdY I50iFZie35nFeYC6mqfrLrMMy3OQgju6exKfPuKTrTMkY9RVDjvH4Zn4NJCTES08pHYd82FuN6s/ hU8XijQR5wyY1cGrp/KnrvnIMCjnfA/RDQD9j8En1eLAJFXP4z5cGrqjmc5BTbZxLOdiGoiWbQug XNUQpepkNtTc9lNEWUszG2Se5rW1h4BHCq6TWYYG5LQH1dFqHY7jmUbJukmGgAj/qcjAGQGkhwwe 6mpIfSUdErLTR2YiQWluxc4iZ9Iruh6TNq0UBgWdo6qb5oeq6QnT7jZex6DU9v/rEWO11ws8W9fc hkFMKEFvV+K6g2YYvU4HfZttbzFtNLt+w8CITW37eoh1mtdgZyG5dhYzOjmCbp8sbNl2n+kM27Y1 2z9ZGEVfH52FIk6zK36WDhl6HQsFi8tOLgPZ/Erar9gXTI9plX5P0GuZxLUdoZgG0HWnXdXpCIca cxsW1oHpdtxAJYWVnN7yBLftfx65xxHpHkJGrx9QHteso9mwVtV76bD+ZppXBRhA3fD8PjoHyyLN MSo6q0731boBVO20DWybbQO7iNBmy7wWa1dfKCqA2QYZlOi3zWsZHiDbIHMQzdvOgqBRBy9Kj14n 0HXBrJoM6qHemGHAHysqG4uUXmYoDsUEKqF85n71DqAD4obVigO23Y4EhmdrejMlIBLYbRdwHDhG gxtwaTsdT/GRicwmHa0P2oPCf44Ap/H6AY7lkkhDkgy5xu4vIODF+jHj65rNjD4yw/EszTl5VBX/ vmIfQPpj7VRgGG1r6JSSG9meGpwOvE1HsxvBQpik4wJUpzl+ywWsThVPo9aqPlSovUZD6KbEUo1n MK+PzGMIJLWM4fVXDobtAPxHVzHh+c5X7wS2j4Dbqf31jhcw1yOkNiOB06kJDMM2tWbxj0itdwKG 6aF0aKxMAPruyt7zfM09LhI8zdR7Daxbvi3CWWVh2+yNBSbDbN0jyg0Ro3roXCqZ7cqxKHN8/dEA C2LNajoCLNmxiIVQ77fDQXcV7sG+VrN2YEiyneLfY0Z3keB0fmZieggHVY1misMjfXZzkO+N2iIQ UaTXXRhSh390A5ja7g8vWLVq9rHMQFVzyh1frx+4CNst+2Ll33YDVzOaVFhyd/bNfRi3Hev9zn6L 4bZDkEUhqO0DCCxmZTOMZvWv8N06wHWx1u9xAPCyasnes3rDisV8gfzS8VE/2l+9+XXGNL9ZGFqw WXftZ7aqeVqxeZ2lH8pMr50OrM7WpW5Y7S0KoM3pLjVcyFK5gKuhtOuN8kDtCd1MM88s/FwpW+WY rt2/s0RbRt6RHfKM/fVXBTp5ftO8MFCn6DOYpVUhsSQDcs12lCcc2e1oYXU2gnWD2ZreoKN4YXVH ZSL4VAMyq3+vjzYYj8UhvKV/GeEw2ts4eYvdy0yn1KIfdwloB+Kr2iV4P6DDF+J8B4/5vOChcqcw 2RKt6bhKQUc7xuPy+MaMFwXP5DmRxnGS45OkOD7KA4SkiVbTLuIPJxbi8507vTokQh/FHdkMB4tt Ir4TpKGSJX8tqK/Q6fp4+gkNkBM34txSmAUP9+KnWFfX1cGiFpNfhBRX65JFefZl3e7d7pzzYru5 30V4VY5Ns8fQCX9QyoNAjSNA2h9zMZXXRHdFPejX8cjOklendb5//O/walQ7cDm6vhazV+pavzTS WyJ4eogat9MQFzVWfylnLYyW56/jIM9/Ddacjgbtq5HH8lTY7+nDeKqMZ/GWT+jkmSJ+1CNv6fBZ vVGegxurRxZCvJJDrd8Z6jQM39Y69B8he5pNhYE6r+4xthOfWtcVnSJ+2y90/ZBcvYtofs3jmOgb p/UuKaXq0KA5lGYku6TiK1NhkXFAB6Z+KtbUo8i2/CDgES2UK+kFyjeA+7USYuIFL/2sZAUs3fFd EF9JaLwcv5Mwez++PvnkJXekWCddkpAqmZ6Oeb19zjEvClTKQ1SslEARh3PTRcnlGCLoDJic0aIE CMJV61DYuPxS8Njpkti/irj6RpAewbRfZIHAwg/RMiryqWKpivwSYzpSwtlInORTFB7n/N8d6uJY L+RIJe1xEE3elUZVFb0ncmiE4oqi9BEpda9sfIeAkWtBGP4MxfOEZ1c1ZmoFlpN3PueX7PO94PNT kIQxz6QIH7c8exQhphty6+9kkKllJikTxbg3pTLCPwNEnKsKyyr8u0KGDK5/5SnlCuHb46ux8lKc bay8+13V8T1ejK/HUr5TGnuex59Gwviac13C7qqW/AT0lCP2Ti9qAwq6Jwb8EzRXJ/kqy4u8JG1+ 4qUq+/k22/G3KCGm40rDJxuKTt9lPJjKbyhO51JVhY5JH8+jqvLb2mntKOmRSXnKvH5IdeKzw+n9 d5+ifLoX/xXFqUhSokT5MNvkKHGUXYPiI024eCQC+mQZFQ0RVdzkf8cw3R8/fR1FCfGQnStPUZVN GiXFH+ITalXElf+Rn6QeGXUn1DsTmylHCD4XOIJBDTJSz3+Ip8+DYMUpTdbpNueUdCp2v1DDb7sK UV/KcVs0GW6L3grq9PqKl6ikInObz4KsfiS5VXyMJVGJqmMPTaQ9rfw0hQpO+p8LxpcGxkSPIwvb /hAtFjzjyZxfcQ1LG1WhA92E6U5EadML6lM5CZx+gybl77+Vb2TqIv/IUPllSS3PUvEPUU/Qo8nK kP7bQtaospiS5LTaOkuOokHSVtRwlftZVJTHp08Ipk4ywAmhEUBu610k4aUeNKHaOCjdckCEjoF/ VygjCoZHNlqRvok+8fDKuEb76Ig+VXnF19+OZJiquld3L1szlIr4mRYismIHp1c36K9EufJqGxMf 4oScjteYEJqrmEDtyGxXQtIIy4PoFSn99uXL6Fp+akCGOUX2+yVCVwG83xcrLHgQuHJSufzao7QC 3j+DrOQnaqwToexH/u37fpvpWVp2TNhwrOju7uRSVGQlRZRs+ZEEanhDX3VQHYQiCPxKWUgRorVc 7NAo41yphsFjUvcAJNcjQ+q1QvDqMIOqm9yEJgQr6lN6geRDdqC5Uui8n6MQLsTU6s+vhI/fKi9f nhqv/6+bo+ttGoi98yusSKxZP5Z0UAl1WV4mIZCGQALxUvVhrKU7VLVVNxAS6n/H9n35kst1E/BC H6rk4s+LfbYvOvuygPg1DdRaiTZQjzYEdRrgBY7QjVU6LHJiwdGNR+acgaV0dcqeTk48qUCnSsy/ UBvSxikoXHiUhJm66XDghw41qiNmLDUJ1U8r0mnpCV3SODF1DsJrkiQojcKlunvKuMRxasSWrAyq tarhavt9vdj0HuArueCNjhOAAYPOdQJ1Oro/qwqEzIyInPBL0np+1tsd0c+Tqo86JT6FQpgY5Efm fZQwMFEswG6//caZrXWmXC4YSSrQlwIFag461RCsFy7WIttxWUIf8oY4RRDyRraE8aYNuaBSC0/v eKX8RjmiebwgokmV7C97rmtvu6JyoIuDdoc55YMcWwtkFt/Xh5pCUuzR0+T+olarfyK2cUR2y7jI hQ7jf5YCqg2mo28+vbumXKTakfwhExxqoLSyRj7T3JE26nRbbmDpdFxxNajLJRT1ox0UqZvXmjdC zaDatPKsaA2KtGblXKekpSB68/Px+O7qbL3crB7uRuM2QaxnH0/QCBQMmGzZ+G0zSW4rE0NmI9Ez g/8FvOABrSr+982AF/J++cDJb2iXr9Ual7blgh9ZM5790kymUA6ROqs0JT5Doq1v8eIwd7uaf6UI flnq4ndcxqreWJFIy9f4f6l4UZlJeWgXgZG9nC7nkrtQERejZJRzS6VTSqVTqcDgcXQwcFGc2vAh rDdANb9wa5TdwEEAgiNbpeHIFtORg7vhsV2Ywqx3u90veXJ6w+AQr6GExvx+c43krjCG0JZx7r4X EJQ8VFyYLp54Se0Uam2w1UL9gFvaVb/MZG+LrLahUEKYlk9mg5lg9Iut7s7rzx9e+bafeG+wC0RP 0uI2C2l21D3BQ0RgJsBNxcD2VPCSGWC1uAw+Q9RWLgMTSBllwC+BWixEaWtn119Rnkr7HLj5GfhD /C0W4gVhVJOPae4n9VuHilM/aTzeh/dWZB3VmtJ6ecO79tv011VhDAqZ6x6yz34DUEsDBBQAAAAI AC5T1UJZwQX5vhcAABtXAABBAAAARXJpY3Nzb25faDI2NF92c192cDhfY29tcGFyaXNvbi92cDhf dnNfeDI2NF9jb25zdHJhaW5lZF9oaWdoLmh0bWzkXGuP28aS/S5A/4FRYGhmTXHYfFPjCZA4MXKB PC4SI4uFYQwosSUxpkiZpDSeq+i/76lukiIpSjPOxQK7a9szIpvV1dVVpx7davrVV9//+vrtf/3z B2VVrONvhoNX9KnEQbK8G/FkJFp4ENLnmheBMl8FWc6Lu9G2WEw88byIiph/8zpdb4IsKKIdV37j +TYu8lc38hFo8uIx5krxuOF3o4J/Km7meS46fzWZKN/xZZQovqMrGQdvZTLBk0ANZrNMDeZZmjyu 1SAM8TBXg80m5oUaZEU0j7ka5FGI39swStWZOouW6ixO5x8+btOCq7M0fFTnQbILcnxsiihN1DlP Cp6p8wjP58NBit5hqIY8xk8RRHGuhotEDaMgTpf42KkhnhQqX+PfjIfqIuJxCCFxsax44nKbcXWR JmhOU+K/SLO1umLqylBXw4Gprix1ZasrRyVl4vlqmaXbjbrCFfStRmq0yII1V6P1Uo2SXP0wC9U4 mEGsmC95gptIXQfZB3XNky1+0RhJsFPT2Z98XqhprGIu22KzLdSNuoEwmyxdCoV9VLONmhVqtp09 qrmaB+uNmqMPCZ6vgzhW802AyyKLPnD6SJOlmm9n+FljRPSBnEUwg7KLWTocQKVFqBY0T7VY4R8m pBYRZC8ytSjUrbqN1V2QqTtYJlU/rTf7WZphzlP9FvxgaVxsYM4oWeKKlDbJo3/xKdP1FwehjRnZ 5XG/4tFyVcj2tr0rU/XZQKi/rWWhM9JWOe99GOWbOBgOHqcCLYdZOe+9kOZBjjtL4/AAe+znaZxm 0yILEmgqA34aQuu3O06iBfEkiKNlMl1HYRjz28k6n0SEtA3mEgc06mQNsE1n0XyLnwMsto33cZSD EfnGNEkTfoijUrbHqXgElK4PQvmlEicQJg42OZ9WF7fiwXCQTSDdXCj1QHYJK8i3JpUAl0HcFbpI N7fkleVtzBfF4eNeOFEuBfs4nfEFrA8Vf5wGC0wMasH8kmI6Ht9Wl4JUYmcjwbU/qsq1X1TPMO+E T0r7Ag1pHpGk04yTqoaDHe9KOAtyTp2IA1RRFOl6OtE1w4Z+iCFmQPfidrfcp+i+iNOH6Qrm4Mmh DDQ/JGE3zHQCEGlBPqDgIaSfMnPz6YZptjL+kcc7TmIpv/AtH6vfZogT6vinaMYzYWPld4BkrL7J OKcreFuST3KeRYsDOeUcCJAaWQTrKH4cDqbj7/mfwR9b0VH5OU3SsfozT+JUfZ0mOZCTq2s0kmn5 YZXVrqR8PZ/PFRBE4W2JDKhg8hCFxWrKNp9u4SxBBgwXq9vhoNL0YcUaBjHszafDymi2mNRiNlsY tViNFuZTi91scallOHCabcQ7bQE85PMIkDi0YQ+4zwn2MjRMCHpTU0fnDUVeio8yiJYhdDigICqc R4Q5GZiq5NAMzogGFdMSLwax7SDhaO8OEJZZFCpXi3iLD0SzKEiK6+FAoT/MUOB82zXsqzBmG5tP SpEWQawI7ZdEq6LYTG9uwEpb5jfKX1UD8c21Fc/SD1ttnq5v5OgauVAAgGf3zNhLM/rGi9umWqz6 NhPmtF4cNGJ3z1T5aZSfZvlplZ+2/BwO7p2yxS0/vfLTLz+ZXl1UPCFNFZGihDzwFn4VFCJGdB0X brtGVD1KzDoSM0gcxJtV0DK3ftDSNV/WjVkJ1pZOlFKcUjdAm2aa5oteokqBzNIcx+2nMUsaw9T0 fgpr/zAcCBqTnR/LLvmY/vmxnJLG8nrHolHu3ZLGvjAvr6RxLszLL2nc7ryGg6MS9ZLIuzAxVqna uzCzI1bLqSHbNYngoovoE6xWJnxpcK931JLWaNMyp2d0+FhFbrbJDbtHxSWp1SY1zUti2Htk7ia5 xXrVUJI7bd62fl4Mt006HNgX9eG1yZ0+fdTEfpvYrbUxHPRYRe+Y5aJCWMeIfo8+hgPQ59tF2+bS n/snWRIbHeJeq1fUiGNmh77X7CVvq0N7xu4ltV1RDwdVmO03fEnvdLj3Wr6kdbu0noa1wXlZvA79 GduX1H6H+mj8AkjuUjeMX9rnolpY15w95pcRZrPNVzD+JUcnCmN/3r1LEnPf59LIL0cSa3/RlYnE 3l90XyJx9idOi5jcInFLkgsz8vYXHZRI/H3bLYeDExLY5aIzCppSvX0uKGjiuLLABAITxvqJSiNM zloBNKUVJv2RlSikEVDLTs7aAVSlHSZnDQGa0hCT/vBJFMOBW9GcMwWoSlNMztoCNKUtJu7pvFCO SR3qlRIvzKsyxuRoDSq9940CvCqgxGLztlqbQGFydXK7i/JoFsVR8Vi1yKSq39aFu2QKT6wWX0fu JJNYhynjzkgL4frVQrW95vqcMTsV4EQumv9DbBkpggpOSXTViv1FT1/ZqVN+iypbFMDDQRjttDUv smi+zILNStlT44F+0VKscUuEcoFPjYrSWFBNFbkkU44Lr9vTXitDdiy3IxRaNirBtkibtFkQRukz B6hYVSsNhfF1k9camOlMYB5HG1oGfe4ItNBVHCzwmrxWQVYEGQ+eyazuGCUhFrNFmuXP7FmSCEQp tC4+Ixra0FDCQXF0vWydBfMPtCeThBO5q6J8vXDp7xmpxOwkvtsm6yj4TJeV3ZhXR+jGfociNwVv mwPoz2C/jZtCybJIdFSUVqlUtjXV9Ez2cdQzAiO8PqP/ZrqIMiy056soDlt8Kpg2GdEuoLZM02XM JwgOW6jmX3LfSqyxJ3maFRhI8qmMp+v1RErnksv6htrLjSeFttMkBuQWhsKwbhYbGMDAYnEOHvP5 vBqhCFtjvCzChk9paRYkS8SmmoWU4ZSlJKzFjkm8CULO4zP6fr3Q6a/s/OpGyCG2t+dZtCma+9t/ BrtAto6UPJvfjWj9n09vbh4eHko1a7T8/zMPNtHoG/ASxE8yA0HZG8vw8GrcMtVYVcZMY/jYjzcQ PljyfDx9NxYWHL8/XEPwXZCJTfzintCkKMod/LPVDoAqsr3VLL0ZzWE6364BMK26+CHm4h4xDR8/ CroJ09tcRXohriPa0B3h2UKIdTdeRDHPxfV9sFuOZac8AZrvlHfvSyYNohDPzj3KgoKfeQbe1ZPh 4OZG+edjsUoTxIE18hN60eacknHczHmuFCsO/MbI03BjxVAo8eUo1ztyvGPv7/ajLH3IR9N3+9Fc /N6NpqOQ5x+gyHvH0u9NBz/66KCKR7rmeIy5juvrnu9ZtudZh/f07Nh5GW3yjM/XKRkVpYan37uG fm83eei6b/iubZm+p+veGQ6QtOjv7/mGoVumyUxm+7prnXD4EGVxkIRiApbXnAAQphu2wRwMbDKa RbfvOpgj0gDe6Q7a62Gha5Zu6Kbp+qbuOxbTmXmOB00BWgiyx34+BoMCXZ/5jukz5p/IkkQf4iA/ KqHV2Xddw3IMzzFd5tvuiSHKzn0D2zYzfMexDdfwPSiEdfsWARQQQHBCR78aTduzmW86lmXZhm73 cxD76PNgzbMA+hSe1q8J27AxHR0aZbpluacCrYKYghmQuS76rMI0w7AMKNO3dN2xHGZ0Wfz6xw+/ ffvTT8dBXcP0gB9bd3RmmL5LMHqvjhAupUNQEEM/+nYpWY7UURTijnwI1+L7Ldy+oVviWBIn2/WM ZxUx2T+/+WQ41j0SGxhR/R3erxBkGjwuUUGkQctxEQn+ht8yH3hxgDEDyjE846zTnXdb5mmGC7dB dxM2Nz33M/3WdDXo2meeZXkO/n2G11q+ZgOmEN53gFnrxLZPOi2zNdeBuV3bMSA78/6ezxqG5hvM NWxmeh4zjXNO1+OxjGm+jZhl2Y5vWLZtOM92WGZAcwaD0EC47qD/5/qr6QPtDgSHe9gMnvvvuCt0 ySxHd3XTdV3GHPcECU96qwGDOog9FnMM07Xx84S3GpbmuJ7hMZfiPuz3f8JZRUr/G+5qICKaDoDO kCGd0xz1tLP6GrIC8gISFNLLaTx9hq9aHrNhHrg6pernO6ttajYStIkEa3qG7Zxg7Wln9TXdMygh +q5lW+wsh8u+6moWEpTu2KZl6wh6n+Grjma5luHaLjr7zD0JFpdc1XINFCgM2dXC81PfeNpVfd/E wAgRDJnwTG5+tqti4oh4to5Kw+6ZyZOuajLNIR8nj6dEfxq3uq7qaCLSMMMxmW475v9aT6U6Hd5J lfW4z0OBHljzoCbbOC6VYWhOV4WW7Woea1Eh2XR9luEP8NgiA8xZNwsaCO+a1ySzDI3Z3UFtygnW oR7PNEzZp03mm56GvrVTO77VR8Zc3dVsr4FAp4/MtC1Lcyt2kMupJtRr4bbRwqCgI1ZNK39fNT1h 6d3GO7Ertf3PAmSs9oLCtVA/Gx1z62Y3ujCsD+DILTpX80/oDB/Fjdc2OFY4etftXdO3tRY7C3HW 7JIxAgYCZj0iKo0+UxoILwjTR4tTFu+hQxIAgip+FtO8fqAxFAP6EUKQzfeMLw4bKE00y+tgw/a6 EdMxrbaLw0utkyUUTImq3WqZHOuukzxmGYhKutmBBqJ9h85Dq1XHAk/DOrjXkpZniklUWDRYL52p e8BpFYIQDJD1+ugcrFM1x6jorCbdlwMMJFG7E/tNq1sboHIyzI69/ZMdFsasrrktwkk3ViM8tNKN 5Wgu65Ih2TS9m7HeKEC5y3GPvq17vfnBMJimV1QIiv3MbIei0qEWytfdLw4PqDk11k0iqJm6yQFk fhs3WIU7XTIbiGBtROiowU5KEMfxkLI7tQWWCN1RCU91MQBB+wOAhbDjNjKIZ/eXIK4hhKsghlK8 FzuOhyXeEWK298WBwtFFnGxhwjrZ12NU07eMjSxv+90C0bQ8YZ1WyPFPtkqZ5fsaczuYsM0uJlDO aI060jb6jYhQjwVLPR7tM/WQobpBHqtsjSzSX3tg7YjoUEPHhMc4XxwoAABNtzuocN2T5O6YXfDA /ifLduY5tuZ1c4xjnVQolu5pptNJMj7r0nmer7n1MgRdWK/BgTKAtq4VUCiavbHC1IFGt44CAKLT G3pcz2Yiu0k6pJovL1pgKd4FBopuq7sgMF1HM9prWPio0Y0DLmrNFjOLvuboFiiiNjS7q5AuKEwP saIq+ExxjKXPiA6qBaOx5kSI6cUO1lZiPVqh1bb7Y49uIGvURQrqzGOi+XJAATfr2Pp044s83u/Y Wve6iEB1b53UCqfLVzpa1Y4ntubo3biDYtSsTGiK7yJ63brp/EzsNPTgAbysRqHgWb0hx9J9ERXk jYNi1P7i0AB9Ot3UwYxupcBsvUuGmu/kKwLTNzW7HSKw2LVPQgRDcu+uTpyTPISsVpeOroYasTcd wKOPnq9r5pkVJkKcV5vaEGmvFziQxKvZwVPsL6+cQB7ubF5h4X6yx8xQs5vtGhNlw8m3CKZ1st3h i9KwG8ER6a02Jiikn6x2dHop6lAPqFv9u5C09VkXmQBP//LEQQXDGuCxe5kxykKs3p2gnY//17sT 7wd0gkQcUuExnxc8VO4UXbZEazpzU9D5lPG4PIMy40XBM3nYpXUmpr6TFPWtPAVJmuk07SL+cGQh 3kG6Y9VJF3qzr2YzHCy2iXjZkYZKlvy1oL5Cp+v6CBcaICcuxOGrMAse7sUXb1fX1emoDpOfhRRX 65JFeYBn3e3d7ZzzYru530V4VI5Ns8fQCX9QytNMrXNM2u9zMZXXRHdFPehPfe5oyasjR989/iO8 GjVOjY6ur8XslabWL430lgieHqLB7TjERY01H8pZC6Pl+es4yPNfgjWn8037auSxPNr2W/ownirj WbzlEzo+p4jvqOQlnaBrNsrDfGO1ZiHEKzk0+p2hTsPwbaND/zm4p9lUPtDkdXoW78in0XVFR6Hf 9gvdPOnX7CKaX/M4JvrWkcNLSqk6tGgOpRnJLql4VVZYZBzQqa8fizX1KLItPwj3iBbKlUSB8hXc /VoJMfGClzgrWcGX7vguiK+ka7wcv5Nu9n58fcTkJThS7JOQJE+VTI9n1d4+56wanVRTHqJipQSK OGGcLkoudYigg2xyRovSQRCuOifbxuXrjnWnS2L/IuLsG0FaO9N+kQXCF76PllGRTxVLVeTrJNOR Es5G4jiiovA45//uUBfHeiFHKmnrQTR5VRpVVVhP5NDIiyuKEiNS6l7Z+A4BI9eCMPwJiucJz64a zNTKWY7ofM4f2ec7wefHIAljnkkRPm559ihCzGnIbT6TQaaRmaRMFOPelMoI/wgQca4qX1aB78oz ZHD9M08pVwhsj6/GyktxQLNC97uq43s8GF+PpXzHNPY8xB9Hwviac1263VUj+QnXU2rfOz5oDCjo nhjwD9BcHeWrLC/ykrT5kZeq7OfbbMffoqSYjisNH20oOn2b8WAqXwQ5Hq5VFTrrXR+qVeULwtPG ediaSXlUvnnSduLrh+Pzbz9F+XQv/j+NY9GkRInyYbbJUfIouxbFR5pw8UgE9N41KhsiqrjJ/1Ni uq/f3x1FCfGQnSukqMomjZLid/EeuCriyn/K92prRqcT6p2JrSu1Cz7XcQSDhstIPf8u7j7PBStO abJOtzmnpFOx+5kaft1VHvV3OW6LNsNt0VtBHR9f8dIrqdjc5rMga56r7hQfY0lUelXdQxNpTyvf r6GCk/77hfGlgTHRemRh2++jxYJnPJnzK65hpaMqdCqdfPokonTpBfWxnISffoUm5a+/lK9k6iJ8 ZKj8sqSRZ2kxAFGPrkeTlSH914WsUWUxJclp8XWWHEWDpK2oAZX7WVSUZ8CPHkydZIATQiOA3Da7 SMJLPWhCjXFQuuVwETrL/m2hjCgY1my0In0TfeLhlXGN9lHtfaryiq+/GckwVXWvrl52ZigV8RMt SGTFDk6vbtBfiXLl1TYmPsQJOR2PMSE0VzGB2pHZroSkEZYH0StS+u3Ll9G1fF+CDHOM7PdLhK4C /n5frLDwQeDKSeXylZXSCnj+DLKSn6ixjoSyH+Hb9/0u07O0ep2wAazo7u4IKSqykiJKtrwmgRre 0KspVAehCAK/UhZShGgtFzs0yjhXqmFwmzQRgORaM6RetOQ7YQZVt7kJTQhW1KdEgeRDdqC5UujE YnKbFGJqzftXAuO3ysuXx8br47KAxusC9L+7ObrWNmLY+36FOFhzzUfv0i0w0uu9FMYGHRts7CXk oUuy1CMkIc3GYOS/T5K/5JzPadn2sjyEs0+SJVuyJB+W1RKtoB6tD+o8wAsMoR2rdFhkxGJE1x+Z cwaW3NUpfTo786QCmSox/0JsSCunoHDlURJq6qbDgR9axKhOqLGUJBQ/LUirpidkSePExDkIq0mS oDAKt+r2KeMUx4kR27IyqFaqhpvN99V83dnDVzLBO+0nAB0GXU4FKtf0cFEVCJkZFjngl6T1/Kw2 W6KfJ0UftHJ8DoVQMchPzPsgoWAiWYDtbvONI1trTLncMJJUoCsZCsTstYohhp47X4vDDssSupAf sVMELm9gUxiv2pALKrWw9JYl5RVlj+bxAo8mRbK/7LnOve2Oyo4uDtru5pR3cqwtkFl8nx9qCkm2 B0/j+4taLv8J28YQ2SzjLBfajf9ZCKjWGI6++fTulmKRakv8h4Ng1xFKI2rki9ktYaMOt+UBlg7H FWeDOl1CVj/aThG6ean5INR0qnUjzormoEhrUk51SFoKonc/H4/vni5Wi/Vyfz8YNgliPvt4goah oMNEy8Zuj4PkpjAxZFYSPTP4X8AL7tCi4n/XdHgmHxZ7Dn5DvXytVri1Leb8yqrx5JceZAxlH6mz SGMap0+0dRMfDlN3qvlXkuCXpU5+h2Us640libR9Df+XjBeFGZWHZhIYOctpMy55ChUxMQpGObZU OqRUOpQKFB57ez3nxamWIMJ6BVTTK7dH2QMcBCA40lXqjhwxnbh9HN49hjFMOrPNbsGT0+kHN5EN JVTm9+tbJHeDPoSOjHP3vYCg5M3owpQixUeqCVFrha3m6gfM6FT9OpuJAh1ZbV2hhDB1q8wBM8Ho ha3uL+vPH1752qXYNtgFoidpca2I9HBUAsJDRGBGwJXRwBaG8JwZYDW/Dj5D1JYvAxNwGR2AF4Hq RERpa2PXX1GeSvsSuIIb+EoEjSHEAqFXk69p7kf1W4eKUz86er0L25Zl7dWOufX8hq3mavrnqjAK hYPrQrjPfgNQSwECFAAUAAAAAABAVNVCAAAAAAAAAAAAAAAAJAAAAAAAAAAAABAAAAAAAAAARXJp Y3Nzb25faDI2NF92c192cDhfY29tcGFyaXNvbi9iaW4vUEsBAhQAFAAAAAgAAp/TQrSOjzGAAAAA zQEAAC4AAAAAAAAAAQAgAAAAQgAAAEVyaWNzc29uX2gyNjRfdnNfdnA4X2NvbXBhcmlzb24vZHJh d19ncmFwaHMuc2hQSwECFAAUAAAACABlSrhCLiaEsVMgAADxeQAANAAAAAAAAAABACAAAAAOAQAA RXJpY3Nzb25faDI2NF92c192cDhfY29tcGFyaXNvbi9lbmNvZGVyX2Jhc2VsaW5lLmNmZ1BLAQIU ABQAAAAIAO1Yt0JVE7OQ6S4AANLEAAA8AAAAAAAAAAEAIAAAALMhAABFcmljc3Nvbl9oMjY0X3Zz X3ZwOF9jb21wYXJpc29uL2VuY29kZXJfY29uc3RyYWluZWRfaGlnaC5jZmdQSwECFAAUAAAACAAi hXRCMaRPr/4sAAC9tgAAKwAAAAAAAAABACAAAAD2UAAARXJpY3Nzb25faDI2NF92c192cDhfY29t cGFyaXNvbi9ndml6X2FwaS5weVBLAQIUABQAAAAIAOlexkIESLp/RTQAAASjAAAsAAAAAAAAAAEA IAAAAD1+AABFcmljc3Nvbl9oMjY0X3ZzX3ZwOF9jb21wYXJpc29uL2d2aXpfYXBpLnB5Y1BLAQIU ABQAAAAIACKFdEKUc9uAmBAAAGA1AAA1AAAAAAAAAAEAIAAAAMyyAABFcmljc3Nvbl9oMjY0X3Zz X3ZwOF9jb21wYXJpc29uL21ldHJpY3NfdGVtcGxhdGUuaHRtbFBLAQIUABQAAAAIAOdO1UKU8wwp YwcAAMAVAAAqAAAAAAAAAAEAIAAAALfDAABFcmljc3Nvbl9oMjY0X3ZzX3ZwOF9jb21wYXJpc29u L1JFQURNRS50eHRQSwECFAAUAAAACABYntNC9il1ZUoAAAB1AAAAMwAAAAAAAAABACAAAABiywAA RXJpY3Nzb25faDI2NF92c192cDhfY29tcGFyaXNvbi9ydW5fYWxsX2ptX3Rlc3RzLnNoUEsBAhQA FAAAAAgACZ7TQpmGSLFgAAAA9wAAADAAAAAAAAAAAQAgAAAA/csAAEVyaWNzc29uX2gyNjRfdnNf dnA4X2NvbXBhcmlzb24vcnVuX2FsbF90ZXN0cy5zaFBLAQIUABQAAAAIAI6s00LB84U2MQIAAKcE AAA3AAAAAAAAAAEAIAAAAKvMAABFcmljc3Nvbl9oMjY0X3ZzX3ZwOF9jb21wYXJpc29uL3J1bl9j cmVhdGVfdmlkZW9fMTBzLnNoUEsBAhQAFAAAAAgAUKbUQlISoQz4AwAACQwAADIAAAAAAAAAAQAg AAAAMc8AAEVyaWNzc29uX2gyNjRfdnNfdnA4X2NvbXBhcmlzb24vcnVuX2ptX2Jhc2VsaW5lLnNo UEsBAhQAFAAAAAgAcXvUQuJwSLr4AwAARwwAADoAAAAAAAAAAQAgAAAAedMAAEVyaWNzc29uX2gy NjRfdnNfdnA4X2NvbXBhcmlzb24vcnVuX2ptX2NvbnN0cmFpbmVkX2hpZ2guc2hQSwECFAAUAAAA CAD2ndNCNaiG91cAAACfAAAAOQAAAAAAAAABACAAAADJ1wAARXJpY3Nzb25faDI2NF92c192cDhf Y29tcGFyaXNvbi9ydW5fdnA4X2FuZF94MjY0X3Rlc3RzLnNoUEsBAhQAFAAAAAgAXbbUQsW7u1TT BAAAcQ0AADAAAAAAAAAAAQAgAAAAd9gAAEVyaWNzc29uX2gyNjRfdnNfdnA4X2NvbXBhcmlzb24v cnVuX3ZwOF90ZXN0cy5zaFBLAQIUABQAAAAIACt71EK5ZtAnBgQAAO0LAAA0AAAAAAAAAAEAIAAA AJjdAABFcmljc3Nvbl9oMjY0X3ZzX3ZwOF9jb21wYXJpc29uL3J1bl94MjY0X2Jhc2VsaW5lLnNo UEsBAhQAFAAAAAgA/XrUQn1/59iWBAAAuA0AADwAAAAAAAAAAQAgAAAA8OEAAEVyaWNzc29uX2gy NjRfdnNfdnA4X2NvbXBhcmlzb24vcnVuX3gyNjRfY29uc3RyYWluZWRfaGlnaC5zaFBLAQIUABQA AAAAALlT1UIAAAAAAAAAAAAAAAAkAAAAAAAAAAAAEAAAAODmAABFcmljc3Nvbl9oMjY0X3ZzX3Zw OF9jb21wYXJpc29uL3NyYy9QSwECFAAUAAAACAAihXRC2EV99RIFAAD3DwAAKgAAAAAAAAABACAA AAAi5wAARXJpY3Nzb25faDI2NF92c192cDhfY29tcGFyaXNvbi9zcmMvcHNuci5jUEsBAhQAFAAA AAgAuoDMQvcMQDV9BQAAzREAAEAAAAAAAAAAAQAgAAAAfOwAAEVyaWNzc29uX2gyNjRfdnNfdnA4 X2NvbXBhcmlzb24vc3JjL3BzbnJfb25seVlfYXZlcmFnZU92ZXJQU05SLmNQSwECFAAUAAAACAAi hXRCUwa4eR8RAADRNwAAMQAAAAAAAAABACAAAABX8gAARXJpY3Nzb25faDI2NF92c192cDhfY29t cGFyaXNvbi92aXN1YWxfbWV0cmljcy5weVBLAQIUABQAAAAIAC5T1ULQt9CCxBcAABlWAAA3AAAA AAAAAAEAIAAAAMUDAQBFcmljc3Nvbl9oMjY0X3ZzX3ZwOF9jb21wYXJpc29uL3ZwOF92c19qbV9i YXNlbGluZS5odG1sUEsBAhQAFAAAAAgAL1PVQn+Y+G/SFwAA51YAAD8AAAAAAAAAAQAgAAAA3hsB AEVyaWNzc29uX2gyNjRfdnNfdnA4X2NvbXBhcmlzb24vdnA4X3ZzX2ptX2NvbnN0cmFpbmVkX2hp Z2guaHRtbFBLAQIUABQAAAAIAC5T1UKHuX60xxcAAFZWAAA5AAAAAAAAAAEAIAAAAA00AQBFcmlj c3Nvbl9oMjY0X3ZzX3ZwOF9jb21wYXJpc29uL3ZwOF92c194MjY0X2Jhc2VsaW5lLmh0bWxQSwEC FAAUAAAACAAuU9VCWcEF+b4XAAAbVwAAQQAAAAAAAAABACAAAAArTAEARXJpY3Nzb25faDI2NF92 c192cDhfY29tcGFyaXNvbi92cDhfdnNfeDI2NF9jb25zdHJhaW5lZF9oaWdoLmh0bWxQSwUGAAAA ABkAGQCECQAASGQBAAAA --_006_BBE9739C2C302046BD34B42713A1E2A22DECC12FESESSMB105erics_ Content-Type: text/html; name="vp8_vs_jm_baseline.html" Content-Description: vp8_vs_jm_baseline.html Content-Disposition: attachment; filename="vp8_vs_jm_baseline.html"; size=22041; creation-date="Sat, 22 Jun 2013 13:41:08 GMT"; modification-date="Sat, 22 Jun 2013 13:41:08 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWw+DQo8aHRtbCBsYW5nPSJlbiI+DQo8aGVhZD4NCjxtZXRhIGNoYXJzZXQ9 InV0Zi04Ij4NCjx0aXRsZT5Db21wYXJhdGl2ZSBSZXN1bHRzPC90aXRsZT4NCjxzdHlsZSB0eXBl PSJ0ZXh0L2NzcyI+DQo8IS0tIEJlZ2luIDk2MCByZXNldCAtLT4NCmEsYWJicixhY3JvbnltLGFk ZHJlc3MsYXBwbGV0LGFydGljbGUsYXNpZGUsYXVkaW8sYixiaWcsYmxvY2txdW90ZSxib2R5LGNh bnZhcyxjYXB0aW9uLGNlbnRlcixjaXRlLGMNCm9kZSxkZCxkZWwsZGV0YWlscyxkZm4sZGlhbG9n LGRpdixkbCxkdCxlbSxlbWJlZCxmaWVsZHNldCxmaWdjYXB0aW9uLGZpZ3VyZSxmb250LGZvb3Rl cixmb3JtLGgxLGgyLGgNCjMsaDQsaDUsaDYsaGVhZGVyLGhncm91cCxocixodG1sLGksaWZyYW1l LGltZyxpbnMsa2JkLGxhYmVsLGxlZ2VuZCxsaSxtYXJrLG1lbnUsbWV0ZXIsbmF2LG9iamVjdCxv bCwNCm91dHB1dCxwLHByZSxwcm9ncmVzcyxxLHJwLHJ0LHJ1YnkscyxzYW1wLHNlY3Rpb24sc21h bGwsc3BhbixzdHJpa2Usc3Ryb25nLHN1YixzdW1tYXJ5LHN1cCx0YWJsZSx0Ym8NCmR5LHRkLHRm b290LHRoLHRoZWFkLHRpbWUsdHIsdHQsdSx1bCx2YXIsdmlkZW8seG1we2JvcmRlcjowO21hcmdp bjowO3BhZGRpbmc6MDtmb250LXNpemU6MTAwJX1odG1sLGINCm9keXtoZWlnaHQ6MTAwJX1hcnRp Y2xlLGFzaWRlLGRldGFpbHMsZmlnY2FwdGlvbixmaWd1cmUsZm9vdGVyLGhlYWRlcixoZ3JvdXAs bWVudSxuYXYsc2VjdGlvbntkaXNwbGENCnk6YmxvY2t9YixzdHJvbmd7Zm9udC13ZWlnaHQ6Ym9s ZH1pbWd7Y29sb3I6dHJhbnNwYXJlbnQ7Zm9udC1zaXplOjA7dmVydGljYWwtYWxpZ246bWlkZGxl Oy1tcy1pbnRlcnANCm9sYXRpb24tbW9kZTpiaWN1YmljfW9sLHVse2xpc3Qtc3R5bGU6bm9uZX1s aXtkaXNwbGF5Omxpc3QtaXRlbX10YWJsZXtib3JkZXItY29sbGFwc2U6Y29sbGFwc2U7Ym9yZGUN CnItc3BhY2luZzowfXRoLHRkLGNhcHRpb257Zm9udC13ZWlnaHQ6bm9ybWFsO3ZlcnRpY2FsLWFs aWduOnRvcDt0ZXh0LWFsaWduOmxlZnR9cXtxdW90ZXM6bm9uZX1xOmJlZm8NCnJlLHE6YWZ0ZXJ7 Y29udGVudDonJztjb250ZW50Om5vbmV9c3ViLHN1cCxzbWFsbHtmb250LXNpemU6NzUlfXN1Yixz dXB7bGluZS1oZWlnaHQ6MDtwb3NpdGlvbjpyZWxhdGkNCnZlO3ZlcnRpY2FsLWFsaWduOmJhc2Vs aW5lfXN1Yntib3R0b206LTAuMjVlbX1zdXB7dG9wOi0wLjVlbX1zdmd7b3ZlcmZsb3c6aGlkZGVu fQ0KPCEtLSBFbmQgOTYwIHJlc2V0IC0tPg0KPCEtLSBCZWdpbiA5NjAgdGV4dCAtLT4NCmJvZHl7 Zm9udDoxM3B4LzEuNSAnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLCdMaWJlcmF0aW9uIFNhbnMnLEZy ZWVTYW5zLHNhbnMtc2VyaWZ9cHJlLGNvZGV7Zm9udC1mYW1pbHkNCjonRGVqYVZ1IFNhbnMgTW9u bycsTWVubG8sQ29uc29sYXMsbW9ub3NwYWNlfWhye2JvcmRlcjowICNjY2Mgc29saWQ7Ym9yZGVy LXRvcC13aWR0aDoxcHg7Y2xlYXI6Ym90aDsNCmhlaWdodDowfWgxe2ZvbnQtc2l6ZToyNXB4fWgy e2ZvbnQtc2l6ZToyM3B4fWgze2ZvbnQtc2l6ZToyMXB4fWg0e2ZvbnQtc2l6ZToxOXB4fWg1e2Zv bnQtc2l6ZToxN3B4fWgNCjZ7Zm9udC1zaXplOjE1cHh9b2x7bGlzdC1zdHlsZTpkZWNpbWFsfXVs e2xpc3Qtc3R5bGU6ZGlzY31saXttYXJnaW4tbGVmdDozMHB4fXAsZGwsaHIsaDEsaDIsaDMsaDQs aDUNCixoNixvbCx1bCxwcmUsdGFibGUsYWRkcmVzcyxmaWVsZHNldCxmaWd1cmV7bWFyZ2luLWJv dHRvbToyMHB4fQ0KPCEtLSBFbmQgOTYwIHRleHQgLS0+DQo8IS0tIEJlZ2luIDk2MCBncmlkIChm bHVpZCB2YXJpYW50KQ0KICAgICAxMiBjb2x1bW5zLCAxMTUycHggdG90YWwgd2lkdGgNCiAgICAg aHR0cDovLzk2MC5ncy8gfCBodHRwOi8vZ3JpZHMuaGVyb2t1LmNvbS8gLS0+DQouY29udGFpbmVy XzEye3dpZHRoOjkyJTttYXJnaW4tbGVmdDo0JTttYXJnaW4tcmlnaHQ6NCV9LmdyaWRfMSwuZ3Jp ZF8yLC5ncmlkXzMsLmdyaWRfNCwuZ3JpZF81LC5ncmlkDQpfNiwuZ3JpZF83LC5ncmlkXzgsLmdy aWRfOSwuZ3JpZF8xMCwuZ3JpZF8xMSwuZ3JpZF8xMntkaXNwbGF5OmlubGluZTtmbG9hdDpsZWZ0 O3Bvc2l0aW9uOnJlbGF0aXZlO21hDQpyZ2luLWxlZnQ6MSU7bWFyZ2luLXJpZ2h0OjElfS5hbHBo YXttYXJnaW4tbGVmdDowfS5vbWVnYXttYXJnaW4tcmlnaHQ6MH0uY29udGFpbmVyXzEyIC5ncmlk XzF7d2lkdGg6DQo2LjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF8ye3dpZHRoOjE0LjY2NyV9LmNv bnRhaW5lcl8xMiAuZ3JpZF8ze3dpZHRoOjIzLjAlfS5jb250YWluZXJfMTIgLmdyaWRfNHt3DQpp ZHRoOjMxLjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF81e3dpZHRoOjM5LjY2NyV9LmNvbnRhaW5l cl8xMiAuZ3JpZF82e3dpZHRoOjQ4LjAlfS5jb250YWluZXJfMTIgLmdyDQppZF83e3dpZHRoOjU2 LjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF84e3dpZHRoOjY0LjY2NyV9LmNvbnRhaW5lcl8xMiAu Z3JpZF85e3dpZHRoOjczLjAlfS5jb250YWluZXJfDQoxMiAuZ3JpZF8xMHt3aWR0aDo4MS4zMzMl fS5jb250YWluZXJfMTIgLmdyaWRfMTF7d2lkdGg6ODkuNjY3JX0uY29udGFpbmVyXzEyIC5ncmlk XzEye3dpZHRoOjk4LjAlfS5jDQpvbnRhaW5lcl8xMiAucHJlZml4XzF7cGFkZGluZy1sZWZ0Ojgu MzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfMntwYWRkaW5nLWxlZnQ6MTYuNjY3JX0uY29udGFp bmVyXzEyDQogLnByZWZpeF8ze3BhZGRpbmctbGVmdDoyNS4wJX0uY29udGFpbmVyXzEyIC5wcmVm aXhfNHtwYWRkaW5nLWxlZnQ6MzMuMzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfNXtwDQphZGRp bmctbGVmdDo0MS42NjclfS5jb250YWluZXJfMTIgLnByZWZpeF82e3BhZGRpbmctbGVmdDo1MC4w JX0uY29udGFpbmVyXzEyIC5wcmVmaXhfN3twYWRkaW5nLWxlZnQ6DQo1OC4zMzMlfS5jb250YWlu ZXJfMTIgLnByZWZpeF84e3BhZGRpbmctbGVmdDo2Ni42NjclfS5jb250YWluZXJfMTIgLnByZWZp eF85e3BhZGRpbmctbGVmdDo3NS4wJX0uY29uDQp0YWluZXJfMTIgLnByZWZpeF8xMHtwYWRkaW5n LWxlZnQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfMTF7cGFkZGluZy1sZWZ0OjkxLjY2 NyV9LmNvbnRhaW5lcl8xDQoyIC5zdWZmaXhfMXtwYWRkaW5nLXJpZ2h0OjguMzMzJX0uY29udGFp bmVyXzEyIC5zdWZmaXhfMntwYWRkaW5nLXJpZ2h0OjE2LjY2NyV9LmNvbnRhaW5lcl8xMiAuc3Vm Zml4DQpfM3twYWRkaW5nLXJpZ2h0OjI1LjAlfS5jb250YWluZXJfMTIgLnN1ZmZpeF80e3BhZGRp bmctcmlnaHQ6MzMuMzMzJX0uY29udGFpbmVyXzEyIC5zdWZmaXhfNXtwYWRkaW5nDQotcmlnaHQ6 NDEuNjY3JX0uY29udGFpbmVyXzEyIC5zdWZmaXhfNntwYWRkaW5nLXJpZ2h0OjUwLjAlfS5jb250 YWluZXJfMTIgLnN1ZmZpeF83e3BhZGRpbmctcmlnaHQ6NTguDQozMzMlfS5jb250YWluZXJfMTIg LnN1ZmZpeF84e3BhZGRpbmctcmlnaHQ6NjYuNjY3JX0uY29udGFpbmVyXzEyIC5zdWZmaXhfOXtw YWRkaW5nLXJpZ2h0Ojc1LjAlfS5jb250DQphaW5lcl8xMiAuc3VmZml4XzEwe3BhZGRpbmctcmln aHQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5zdWZmaXhfMTF7cGFkZGluZy1yaWdodDo5MS42Njcl fS5jb250YWluZXJfDQoxMiAucHVzaF8xe2xlZnQ6OC4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hf MntsZWZ0OjE2LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVzaF8ze2xlZnQ6MjUuMCV9LmNvbnRhaW5l DQpyXzEyIC5wdXNoXzR7bGVmdDozMy4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hfNXtsZWZ0OjQx LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVzaF82e2xlZnQ6NTAuMCV9LmNvbnRhDQppbmVyXzEyIC5w dXNoXzd7bGVmdDo1OC4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hfOHtsZWZ0OjY2LjY2NyV9LmNv bnRhaW5lcl8xMiAucHVzaF85e2xlZnQ6NzUuMCV9LmNvDQpudGFpbmVyXzEyIC5wdXNoXzEwe2xl ZnQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5wdXNoXzExe2xlZnQ6OTEuNjY3JX0uY29udGFpbmVy XzEyIC5wdWxsXzF7bGVmdDotOC4zDQozMyV9LmNvbnRhaW5lcl8xMiAucHVsbF8ye2xlZnQ6LTE2 LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVsbF8ze2xlZnQ6LTI1LjAlfS5jb250YWluZXJfMTIgLnB1 bGxfNHtsZWZ0DQo6LTMzLjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF81e2xlZnQ6LTQxLjY2NyV9 LmNvbnRhaW5lcl8xMiAucHVsbF82e2xlZnQ6LTUwLjAlfS5jb250YWluZXJfMTIgLnB1bGxfDQo3 e2xlZnQ6LTU4LjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF84e2xlZnQ6LTY2LjY2NyV9LmNvbnRh aW5lcl8xMiAucHVsbF85e2xlZnQ6LTc1LjAlfS5jb250YWluZXJfMTINCi5wdWxsXzEwe2xlZnQ6 LTgzLjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF8xMXtsZWZ0Oi05MS42NjclfS5jbGVhcntjbGVh cjpib3RoO2Rpc3BsYXk6YmxvY2s7b3ZlcmZsb3cNCjpoaWRkZW47dmlzaWJpbGl0eTpoaWRkZW47 d2lkdGg6MDtoZWlnaHQ6MH0uY2xlYXJmaXg6YWZ0ZXJ7Y2xlYXI6Ym90aDtjb250ZW50OicgJztk aXNwbGF5OmJsb2NrO2ZvbnQNCi1zaXplOjA7bGluZS1oZWlnaHQ6MDt2aXNpYmlsaXR5OmhpZGRl bjt3aWR0aDowO2hlaWdodDowfS5jbGVhcmZpeHtkaXNwbGF5OmlubGluZS1ibG9ja30qIGh0bWwg LmNsZWENCnJmaXh7aGVpZ2h0OjElfS5jbGVhcmZpeHtkaXNwbGF5OmJsb2NrfQ0KPCEtLSBFbmQg OTYwIGdyaWQgLS0+DQoNCmRpdi5tZXRyaWNncmFwaCB7DQoNCn0NCg0KYm9keSB7DQoNCn0NCg0K ZGl2LmhlYWRlciB7DQogIGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsNCn0NCg0KZGl2 LmhlYWRlciBoMiB7DQogIG1hcmdpbjogLjVlbSBhdXRvOw0KfQ0KDQpkaXYucmFkaW8gew0KICBm b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7DQogIG1hcmdpbi1ib3R0b206IDFlbTsNCn0N Cg0KZGl2Lm1haW4gew0KDQp9DQoNCmRpdi5jbGlwbGlzdCB7DQogIGZvbnQtZmFtaWx5OiBBcmlh bCwgc2Fucy1zZXJpZjsNCiAgbWFyZ2luLXRvcDogNnB4Ow0KfQ0KDQpkaXYuY2hhcnRhcmVhIHsN CiAgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOw0KfQ0KDQpkaXYuaW5kaWNhdG9ycyB7 DQogIGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsNCiAgZm9udC1zaXplOiAxM3B4Ow0K ICBtYXJnaW4tdG9wOiA2cHg7DQogIG1pbi1oZWlnaHQ6IDYwMHB4Ow0KICBiYWNrZ3JvdW5kLWNv bG9yOiAjZjdmN2Y3Ow0KfQ0KDQpkaXYuaW5kaWNhdG9ycyBkaXYuY29udGVudCB7DQogIG1hcmdp bjogMWVtOw0KfQ0KDQpkaXYuaW5kaWNhdG9ycyBkaXYuY29udGVudCBoNSB7DQogIGZvbnQtc2l6 ZTogMTNweDsNCiAgdGV4dC1hbGlnbjogY2VudGVyOw0KICBtYXJnaW46IDA7DQp9DQoNCmRpdi5p bmRpY2F0b3JzIGRpdi5jb250ZW50IHVsIHsNCiAgbWFyZ2luLWxlZnQ6IDA7DQogIHBhZGRpbmct bGVmdDogMDsNCiAgbWFyZ2luLXRvcDogMDsNCn0NCg0KZGl2LmluZGljYXRvcnMgZGl2LmNvbnRl bnQgdWwgbGkgew0KICBtYXJnaW4tbGVmdDogMS41ZW07DQp9DQoNCmRpdi5pbmRpY2F0b3JzIGRp di5jb250ZW50IHA6Zmlyc3QtY2hpbGQgew0KICBtYXJnaW4tYm90dG9tOiAuNWVtOw0KfQ0KDQpz cGFuLmdvb2dsZS12aXN1YWxpemF0aW9uLXRhYmxlLXNvcnRpbmQgew0KICBjb2xvcjogIzAwMDsN Cn0NCg0KLmhlYWRlci1zdHlsZSB7DQogIGZvbnQtd2VpZ2h0OiBib2xkOw0KICBib3JkZXI6IDFw eCBzb2xpZCAjZmZmOw0KICBiYWNrZ3JvdW5kLWNvbG9yOiAjY2NjOw0KfQ0KDQp0ZC5oZWFkZXIt c3R5bGUrdGQgew0KDQp9DQoNCi5vcmFuZ2UtYmFja2dyb3VuZCB7DQogIGJhY2tncm91bmQtY29s b3I6IG9yYW5nZTsNCn0NCg0KLmxpZ2h0LWdyYXktYmFja2dyb3VuZCB7DQogIGJhY2tncm91bmQt Y29sb3I6ICNmMGYwZjA7DQp9DQo8L3N0eWxlPg0KPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3Jp cHQiIHNyYz0iaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9qc2FwaSI+PC9zY3JpcHQ+DQo8c2NyaXB0 IHR5cGU9InRleHQvamF2YXNjcmlwdCI+DQpnb29nbGUubG9hZCgndmlzdWFsaXphdGlvbicsICcx LjEnLCB7J3BhY2thZ2VzJzpbJ3RhYmxlJ119KTsNCnZhciBjaGFydF9sZWZ0ICAgPSA2MDsNCnZh ciBjaGFydF90b3AgICAgPSA2Ow0KdmFyIGNoYXJ0X2hlaWdodCA9IGRvY3VtZW50LmRvY3VtZW50 RWxlbWVudC5jbGllbnRIZWlnaHQtMTAwOw0KdmFyIGNoYXJ0X3dpZHRoICA9ICIxMDAlIjsNCmZ0 YWJsZT0nZmlsZXN0YWJsZV9hdmcnDQp2YXIgc25ycyA9IFtdOw0KdmFyIGZpbGVzdGFibGVfZHNu ciA9IFtdOw0KdmFyIGZpbGVzdGFibGVfZHJhdGUgPSBbXTsNCnZhciBmaWxlc3RhYmxlX2F2ZyA9 IFtdOw0KDQovLyBQeXRob24gdGVtcGxhdGUgY29kZSByZXBsYWNlcyB0aGUgZm9sbG93aW5nIDIg bGluZXMuDQpmaWxlc3RhYmxlX2RzbnJbMV09eyJyb3dzIjpbeyJjIjpbeyJ2IjoiZGVza3RvcF82 NDBfMzYwXzMwIn0seyJ2IjotMC4xMjIxODkyMzE3NjczMTkwMX1dfSx7ImMiOlt7InYiOiJnaXBz cmVjbW90aW9uXzEyODBfNzIwXzUwIn0seyJ2IjotMC4xMjE0ODMyOTgzMDQzMTg5Mn1dfSx7ImMi Olt7InYiOiJnaXBzcmVjc3RhdF8xMjgwXzcyMF81MCJ9LHsidiI6MC4yNjg1NzIxNjAzMzQ2MTgz NH1dfSx7ImMiOlt7InYiOiJraXJsYW5kXzY0MF80ODBfMzAifSx7InYiOjAuMzUyMjY1ODY3NzU3 MTkyODd9XX0seyJjIjpbeyJ2IjoibWFjbWFyY29tb3ZpbmdfNjQwXzQ4MF8zMCJ9LHsidiI6LTAu MDIyMzA4MTQyOTYwODU4MjV9XX0seyJjIjpbeyJ2IjoibWFjbWFyY29zdGF0aW9uYXJ5XzY0MF80 ODBfMzAifSx7InYiOjAuMzAyNzc3ODY5NDExMDIwNTh9XX0seyJjIjpbeyJ2IjoibmlrbGFzXzEy ODBfNzIwXzMwIn0seyJ2IjotMC4xNDQ1NDgxMDYxODUyNzQ2MX1dfSx7ImMiOlt7InYiOiJuaWts YXNfNjQwXzQ4MF8zMCJ9LHsidiI6LTAuMjczODI2Mjg4NTc3NDE3MzF9XX0seyJjIjpbeyJ2Ijoi dGFjb21hbmFycm93c182NDBfNDgwXzMwIn0seyJ2IjowLjk2NjMzMTEzNjg2OTM5NzY0fV19LHsi YyI6W3sidiI6InRhY29tYXNtYWxsY2FtZXJhbW92ZW1lbnRfNjQwXzQ4MF8zMCJ9LHsidiI6LTAu MTQ2MDIwNDkyODE2OTQyOTl9XX0seyJjIjpbeyJ2IjoidGhhbG91bmRlc2ttdGdfNjQwXzQ4MF8z MCJ9LHsidiI6MC42MjA4NjEzNjA4NTkwNjE3NH1dfSx7ImMiOlt7InYiOiJPVkVSQUxMIn0seyJ2 IjowLjE1Mjc2NjYyMTMyOTAxNDU2fV19XSwiY29scyI6W3sidHlwZSI6InN0cmluZyIsImlkIjoi ZmlsZSIsImxhYmVsIjoiRmlsZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvam1fYmFz ZWxpbmUiLCJsYWJlbCI6InN0YXRzL2ptX2Jhc2VsaW5lIn1dfQoNCmZpbGVzdGFibGVfYXZnWzFd PXsicm93cyI6W3siYyI6W3sidiI6ImRlc2t0b3BfNjQwXzM2MF8zMCJ9LHsidiI6LTMuNzA0ODU0 MjI0MDc3ODIyfV19LHsiYyI6W3sidiI6ImdpcHNyZWNtb3Rpb25fMTI4MF83MjBfNTAifSx7InYi Oi01LjQ3NzcxNTM1NTIyNzcxOX1dfSx7ImMiOlt7InYiOiJnaXBzcmVjc3RhdF8xMjgwXzcyMF81 MCJ9LHsidiI6Ny41MDg5MDE5Mzg2Mzk5NDN9XX0seyJjIjpbeyJ2Ijoia2lybGFuZF82NDBfNDgw XzMwIn0seyJ2IjoxMi4wOTkwMzk5Mjg3NDA5NH1dfSx7ImMiOlt7InYiOiJtYWNtYXJjb21vdmlu Z182NDBfNDgwXzMwIn0seyJ2IjotNS40MDEyOTczNDI5MDYyOTA1fV19LHsiYyI6W3sidiI6Im1h Y21hcmNvc3RhdGlvbmFyeV82NDBfNDgwXzMwIn0seyJ2IjoxMS40MDIwMDYyODkwMDY3MTl9XX0s eyJjIjpbeyJ2IjoibmlrbGFzXzEyODBfNzIwXzMwIn0seyJ2IjotOC42ODU0Njg4Nzg1MzMwNDZ9 XX0seyJjIjpbeyJ2IjoibmlrbGFzXzY0MF80ODBfMzAifSx7InYiOi02LjU1NzYyNjgwMzYxNjY0 fV19LHsiYyI6W3sidiI6InRhY29tYW5hcnJvd3NfNjQwXzQ4MF8zMCJ9LHsidiI6MzQuMjc5NzM0 NzQ2MjA4MTh9XX0seyJjIjpbeyJ2IjoidGFjb21hc21hbGxjYW1lcmFtb3ZlbWVudF82NDBfNDgw XzMwIn0seyJ2IjotNS4xMDg0MjExNTk2OTg1MTJ9XX0seyJjIjpbeyJ2IjoidGhhbG91bmRlc2tt dGdfNjQwXzQ4MF8zMCJ9LHsidiI6MTAuMzcwMDgzNjE2NzYzNzA0fV19LHsiYyI6W3sidiI6Ik9W RVJBTEwifSx7InYiOjMuNzAyMjE2NjE0MTE4MTMyfV19XSwiY29scyI6W3sidHlwZSI6InN0cmlu ZyIsImlkIjoiZmlsZSIsImxhYmVsIjoiRmlsZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3Rh dHMvam1fYmFzZWxpbmUiLCJsYWJlbCI6InN0YXRzL2ptX2Jhc2VsaW5lIn1dfQoNCmZpbGVzdGFi bGVfZHJhdGVbMV09eyJyb3dzIjpbeyJjIjpbeyJ2IjoiZGVza3RvcF82NDBfMzYwXzMwIn0seyJ2 IjotMy4wNjAzMjg2OTM5MzcyOTc2fV19LHsiYyI6W3sidiI6ImdpcHNyZWNtb3Rpb25fMTI4MF83 MjBfNTAifSx7InYiOi0zLjg3NTcxOTgwNzUwMjU0MjN9XX0seyJjIjpbeyJ2IjoiZ2lwc3JlY3N0 YXRfMTI4MF83MjBfNTAifSx7InYiOjguNjQyMDUyMTEwODM0MjJ9XX0seyJjIjpbeyJ2Ijoia2ly bGFuZF82NDBfNDgwXzMwIn0seyJ2IjoxMS41NzU4OTE5MTUwMDg2NzR9XX0seyJjIjpbeyJ2Ijoi bWFjbWFyY29tb3ZpbmdfNjQwXzQ4MF8zMCJ9LHsidiI6LTAuODg1NTMxNjM2OTQ3MDc4OX1dfSx7 ImMiOlt7InYiOiJtYWNtYXJjb3N0YXRpb25hcnlfNjQwXzQ4MF8zMCJ9LHsidiI6MTguODUzMDU0 NTk5OTU2NzY0fV19LHsiYyI6W3sidiI6Im5pa2xhc18xMjgwXzcyMF8zMCJ9LHsidiI6LTUuMzIx MjA3NDk0MzYyODQ1fV19LHsiYyI6W3sidiI6Im5pa2xhc182NDBfNDgwXzMwIn0seyJ2IjotNS43 ODcyMTgzNzEzMjMxNDR9XX0seyJjIjpbeyJ2IjoidGFjb21hbmFycm93c182NDBfNDgwXzMwIn0s eyJ2IjozMi4yMjAwNjU3MjIwODY3M31dfSx7ImMiOlt7InYiOiJ0YWNvbWFzbWFsbGNhbWVyYW1v dmVtZW50XzY0MF80ODBfMzAifSx7InYiOi00LjEzOTMzOTg2MjA5NzEwM31dfSx7ImMiOlt7InYi OiJ0aGFsb3VuZGVza210Z182NDBfNDgwXzMwIn0seyJ2IjoxMi4yNTg3ODYxMjg5ODExNDZ9XX0s eyJjIjpbeyJ2IjoiT1ZFUkFMTCJ9LHsidiI6NS40OTgyMjc2OTE4ODE1OTN9XX1dLCJjb2xzIjpb eyJ0eXBlIjoic3RyaW5nIiwiaWQiOiJmaWxlIiwibGFiZWwiOiJGaWxlIn0seyJ0eXBlIjoibnVt YmVyIiwiaWQiOiJzdGF0cy9qbV9iYXNlbGluZSIsImxhYmVsIjoic3RhdHMvam1fYmFzZWxpbmUi fV19Cg0Kc25yc1sxXSA9IFsneyJyb3dzIjpbeyJjIjpbeyJ2IjoyMjMuMDJ9LG51bGwseyJ2Ijoz Mi42NTd9XX0seyJjIjpbeyJ2Ijo1NjYuNjV9LG51bGwseyJ2IjozNS44Njh9XX0seyJjIjpbeyJ2 IjoxNDU5Ljc4fSxudWxsLHsidiI6MzkuMn1dfSx7ImMiOlt7InYiOjM1MDguMTF9LG51bGwseyJ2 Ijo0Mi4yOTJ9XX0seyJjIjpbeyJ2Ijo1MTIuMDR9LHsidiI6MzUuMzIzfSxudWxsXX0seyJjIjpb eyJ2Ijo5MzguNTN9LHsidiI6MzcuNjk0fSxudWxsXX0seyJjIjpbeyJ2IjoxNzA3LjU4fSx7InYi OjM5Ljk2fSxudWxsXX0seyJjIjpbeyJ2IjozNTQ0LjczfSx7InYiOjQyLjY0MX0sbnVsbF19XSwi Y29scyI6W3sidHlwZSI6Im51bWJlciIsImlkIjoiZGF0YXJhdGUiLCJsYWJlbCI6IkRhdGFyYXRl In0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJsYWJlbCI6InN0YXRzL3ZwOCJ9 LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvam1fYmFzZWxpbmUiLCJsYWJlbCI6InN0YXRz L2ptX2Jhc2VsaW5lIn1dfScsJ3sicm93cyI6W3siYyI6W3sidiI6ODA0Ljc3fSxudWxsLHsidiI6 MzQuNTk4fV19LHsiYyI6W3sidiI6MTYzNy4yfSxudWxsLHsidiI6MzcuNjI1fV19LHsiYyI6W3si diI6MzYyMi4yMX0sbnVsbCx7InYiOjQwLjc4MX1dfSx7ImMiOlt7InYiOjk0MzkuNDZ9LG51bGws eyJ2Ijo0My42NX1dfSx7ImMiOlt7InYiOjE1MTIuMTV9LHsidiI6MzcuNDU1fSxudWxsXX0seyJj IjpbeyJ2IjoyNTU1LjU5fSx7InYiOjM5LjY3N30sbnVsbF19LHsiYyI6W3sidiI6NDgxOC41NX0s eyJ2Ijo0MS44MjN9LG51bGxdfSx7ImMiOlt7InYiOjEwMzcwLjU4fSx7InYiOjQzLjk4Mn0sbnVs bF19XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIsImlkIjoiZGF0YXJhdGUiLCJsYWJlbCI6IkRh dGFyYXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJsYWJlbCI6InN0YXRz L3ZwOCJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvam1fYmFzZWxpbmUiLCJsYWJlbCI6 InN0YXRzL2ptX2Jhc2VsaW5lIn1dfScsJ3sicm93cyI6W3siYyI6W3sidiI6MzU5LjQ3fSxudWxs LHsidiI6MzUuMjU3fV19LHsiYyI6W3sidiI6Nzg1LjczfSxudWxsLHsidiI6MzguMTN9XX0seyJj IjpbeyJ2IjoxODY5LjJ9LG51bGwseyJ2Ijo0MS4xNDh9XX0seyJjIjpbeyJ2Ijo1MzM4Ljl9LG51 bGwseyJ2Ijo0My45MDN9XX0seyJjIjpbeyJ2Ijo4NDMuNDN9LHsidiI6MzguMDI1fSxudWxsXX0s eyJjIjpbeyJ2IjoxNDgzLjQ4fSx7InYiOjQwLjIxNX0sbnVsbF19LHsiYyI6W3sidiI6MzA4MC44 NH0seyJ2Ijo0Mi4yODl9LG51bGxdfSx7ImMiOlt7InYiOjY5NzcuNjJ9LHsidiI6NDQuMjg5fSxu dWxsXX1dLCJjb2xzIjpbeyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoi RGF0YXJhdGUifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3Rh dHMvdnA4In0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy9qbV9iYXNlbGluZSIsImxhYmVs Ijoic3RhdHMvam1fYmFzZWxpbmUifV19JywneyJyb3dzIjpbeyJjIjpbeyJ2IjozOC4zNn0sbnVs bCx7InYiOjM4LjAyfV19LHsiYyI6W3sidiI6NjYuNjN9LG51bGwseyJ2Ijo0MS4wNzF9XX0seyJj IjpbeyJ2IjoxMzkuODl9LG51bGwseyJ2Ijo0NC4xNDJ9XX0seyJjIjpbeyJ2Ijo0MDMuNDZ9LG51 bGwseyJ2Ijo0Ni42NDl9XX0seyJjIjpbeyJ2Ijo2OS41NX0seyJ2Ijo0MS4xMTd9LG51bGxdfSx7 ImMiOlt7InYiOjExMS42N30seyJ2Ijo0My4wODZ9LG51bGxdfSx7ImMiOlt7InYiOjIyMS4wfSx7 InYiOjQ1LjAxN30sbnVsbF19LHsiYyI6W3sidiI6NTY3LjQ1fSx7InYiOjQ2LjkwN30sbnVsbF19 XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIsImlkIjoiZGF0YXJhdGUiLCJsYWJlbCI6IkRhdGFy YXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJsYWJlbCI6InN0YXRzL3Zw OCJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvam1fYmFzZWxpbmUiLCJsYWJlbCI6InN0 YXRzL2ptX2Jhc2VsaW5lIn1dfScsJ3sicm93cyI6W3siYyI6W3sidiI6MTQ3LjMyfSxudWxsLHsi diI6MzUuNTkyfV19LHsiYyI6W3sidiI6MjcyLjA0fSxudWxsLHsidiI6MzguMjA3fV19LHsiYyI6 W3sidiI6NjIwLjI0fSxudWxsLHsidiI6NDAuNjI4fV19LHsiYyI6W3sidiI6MjI3My42fSxudWxs LHsidiI6NDMuMjA5fV19LHsiYyI6W3sidiI6MjQ0LjQ4fSx7InYiOjM4LjExNX0sbnVsbF19LHsi YyI6W3sidiI6NDMyLjc5fSx7InYiOjM5Ljg1M30sbnVsbF19LHsiYyI6W3sidiI6OTcyLjEzfSx7 InYiOjQxLjUwMn0sbnVsbF19LHsiYyI6W3sidiI6MjY4NC42fSx7InYiOjQzLjU4fSxudWxsXX1d LCJjb2xzIjpbeyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0YXJh dGUifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4 In0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy9qbV9iYXNlbGluZSIsImxhYmVsIjoic3Rh dHMvam1fYmFzZWxpbmUifV19JywneyJyb3dzIjpbeyJjIjpbeyJ2Ijo2NC4wNH0sbnVsbCx7InYi OjM1LjI0MX1dfSx7ImMiOlt7InYiOjEyNC41Mn0sbnVsbCx7InYiOjM3LjQ3Nn1dfSx7ImMiOlt7 InYiOjMzOS40Mn0sbnVsbCx7InYiOjM5LjgzMn1dfSx7ImMiOlt7InYiOjE5NjUuNTh9LG51bGws eyJ2Ijo0Mi42Nzh9XX0seyJjIjpbeyJ2IjoxMzcuM30seyJ2IjozNy41MjJ9LG51bGxdfSx7ImMi Olt7InYiOjI3Ny4xMX0seyJ2IjozOS4yMDh9LG51bGxdfSx7ImMiOlt7InYiOjgwMS4xOH0seyJ2 Ijo0MC44Nzd9LG51bGxdfSx7ImMiOlt7InYiOjI1NjYuOTN9LHsidiI6NDMuMTI2fSxudWxsXX1d LCJjb2xzIjpbeyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0YXJh dGUifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4 In0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy9qbV9iYXNlbGluZSIsImxhYmVsIjoic3Rh dHMvam1fYmFzZWxpbmUifV19JywneyJyb3dzIjpbeyJjIjpbeyJ2Ijo1NTIuMzJ9LG51bGwseyJ2 IjozNS41NzJ9XX0seyJjIjpbeyJ2IjoxMDQ5LjU3fSxudWxsLHsidiI6MzguNjYzfV19LHsiYyI6 W3sidiI6MjI5NC4xOX0sbnVsbCx7InYiOjQxLjYzMX1dfSx7ImMiOlt7InYiOjc1NjUuNTR9LG51 bGwseyJ2Ijo0NC44Nzl9XX0seyJjIjpbeyJ2Ijo4ODkuNzR9LHsidiI6MzguMzE4fSxudWxsXX0s eyJjIjpbeyJ2IjoxNDk1LjI0fSx7InYiOjQwLjUzM30sbnVsbF19LHsiYyI6W3sidiI6MzA5OS43 Nn0seyJ2Ijo0Mi41NjV9LG51bGxdfSx7ImMiOlt7InYiOjc4NTEuNTF9LHsidiI6NDUuMDh9LG51 bGxdfV0sImNvbHMiOlt7InR5cGUiOiJudW1iZXIiLCJpZCI6ImRhdGFyYXRlIiwibGFiZWwiOiJE YXRhcmF0ZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvdnA4IiwibGFiZWwiOiJzdGF0 cy92cDgifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL2ptX2Jhc2VsaW5lIiwibGFiZWwi OiJzdGF0cy9qbV9iYXNlbGluZSJ9XX0nLCd7InJvd3MiOlt7ImMiOlt7InYiOjIzNy44fSxudWxs LHsidiI6MzMuOTg0fV19LHsiYyI6W3sidiI6NDU2LjV9LG51bGwseyJ2IjozNy4yNTR9XX0seyJj IjpbeyJ2Ijo5MDQuNzd9LG51bGwseyJ2Ijo0MC42NTd9XX0seyJjIjpbeyJ2IjoxOTA1LjkxfSxu dWxsLHsidiI6NDMuODA4fV19LHsiYyI6W3sidiI6Mzg3LjMyfSx7InYiOjM2LjY2N30sbnVsbF19 LHsiYyI6W3sidiI6NjIxLjI4fSx7InYiOjM5LjEzN30sbnVsbF19LHsiYyI6W3sidiI6MTAzMi45 Nn0seyJ2Ijo0MS41NTJ9LG51bGxdfSx7ImMiOlt7InYiOjIwMjMuNTd9LHsidiI6NDQuMjAyfSxu dWxsXX1dLCJjb2xzIjpbeyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoi RGF0YXJhdGUifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3Rh dHMvdnA4In0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy9qbV9iYXNlbGluZSIsImxhYmVs Ijoic3RhdHMvam1fYmFzZWxpbmUifV19JywneyJyb3dzIjpbeyJjIjpbeyJ2IjoyMy40N30sbnVs bCx7InYiOjM3LjExM31dfSx7ImMiOlt7InYiOjQyLjQxfSxudWxsLHsidiI6MzkuOTcxfV19LHsi YyI6W3sidiI6ODIuNzJ9LG51bGwseyJ2Ijo0Mi44MTd9XX0seyJjIjpbeyJ2IjoyMTEuNzh9LG51 bGwseyJ2Ijo0NS4zNTd9XX0seyJjIjpbeyJ2Ijo1My4zNn0seyJ2IjozOS40OTZ9LG51bGxdfSx7 ImMiOlt7InYiOjc5Ljc2fSx7InYiOjQxLjczfSxudWxsXX0seyJjIjpbeyJ2IjoxNTMuNDZ9LHsi diI6NDMuODQ4fSxudWxsXX0seyJjIjpbeyJ2Ijo0MDkuMDh9LHsidiI6NDYuMDE1fSxudWxsXX1d LCJjb2xzIjpbeyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0YXJh dGUifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4 In0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy9qbV9iYXNlbGluZSIsImxhYmVsIjoic3Rh dHMvam1fYmFzZWxpbmUifV19JywneyJyb3dzIjpbeyJjIjpbeyJ2Ijo5NS40OX0sbnVsbCx7InYi OjM0LjkxM31dfSx7ImMiOlt7InYiOjE3Ny4zNX0sbnVsbCx7InYiOjM4LjA3OX1dfSx7ImMiOlt7 InYiOjQ4MS42Nn0sbnVsbCx7InYiOjQxLjUyOH1dfSx7ImMiOlt7InYiOjE0MjguMDh9LG51bGws eyJ2Ijo0NC44MzZ9XX0seyJjIjpbeyJ2IjoxNzQuOX0seyJ2IjozNy45NzJ9LG51bGxdfSx7ImMi Olt7InYiOjMyMy45Nn0seyJ2Ijo0MC4zODl9LG51bGxdfSx7ImMiOlt7InYiOjY3Ni44OH0seyJ2 Ijo0Mi43NTR9LG51bGxdfSx7ImMiOlt7InYiOjE1NDQuODZ9LHsidiI6NDUuMjU2fSxudWxsXX1d LCJjb2xzIjpbeyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0YXJh dGUifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4 In0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy9qbV9iYXNlbGluZSIsImxhYmVsIjoic3Rh dHMvam1fYmFzZWxpbmUifV19JywneyJyb3dzIjpbeyJjIjpbeyJ2IjoxMDMuMDN9LG51bGwseyJ2 IjozMi4wNTF9XX0seyJjIjpbeyJ2IjoxOTIuNjV9LG51bGwseyJ2IjozNS42NDd9XX0seyJjIjpb eyJ2IjozODAuMTd9LG51bGwseyJ2IjozOS4zMzF9XX0seyJjIjpbeyJ2IjoxMTk0LjQ3fSxudWxs LHsidiI6NDIuODQxfV19LHsiYyI6W3sidiI6MjAwLjI1fSx7InYiOjM1LjA0Nn0sbnVsbF19LHsi YyI6W3sidiI6MzEyLjAxfSx7InYiOjM3LjkxNX0sbnVsbF19LHsiYyI6W3sidiI6NjA4LjE2fSx7 InYiOjQwLjU2fSxudWxsXX0seyJjIjpbeyJ2IjoxNjIxLjEyfSx7InYiOjQzLjQ4OX0sbnVsbF19 XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIsImlkIjoiZGF0YXJhdGUiLCJsYWJlbCI6IkRhdGFy YXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJsYWJlbCI6InN0YXRzL3Zw OCJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvam1fYmFzZWxpbmUiLCJsYWJlbCI6InN0 YXRzL2ptX2Jhc2VsaW5lIn1dfScsXQoNCg0KdmFyIHNlbGVjdGVkID0gMA0KdmFyIGltYWdlc3Ry ID0gJyc7DQp2YXIgYmV0dGVydGFibGU9MDsNCnZhciBjaGFydD0wOw0KdmFyIGJldHRlcj0wOw0K dmFyIG1ldHJpY2RhdGE9MDsNCnZhciBtZXRyaWN2aWV3PTA7DQp2YXIgY29sdW1uPTE7DQp2YXIg Zm9ybWF0dGVyPTA7DQoNCmZ1bmN0aW9uIGNoYW5nZUNvbHVtbihjb2wpIHsNCiAgY29sdW1uID0g Y29sOw0KICBkcmF3X2ZpbGVzKCk7DQp9DQoNCmZ1bmN0aW9uIGNoYW5nZU1ldHJpYyhtKSB7DQog IGZ0YWJsZT1tDQogIGRyYXdfZmlsZXMoKQ0KfQ0KDQpmdW5jdGlvbiBzZXR1cF92aXMoKSB7DQog IGNoYXJ0ID0gbmV3IGdvb2dsZS52aXN1YWxpemF0aW9uLlNjYXR0ZXJDaGFydCgNCiAgICAgIGRv Y3VtZW50LmdldEVsZW1lbnRCeUlkKCJtZXRyaWNncmFwaCIpKTsNCg0KICBiZXR0ZXJ0YWJsZSA9 IG5ldyBnb29nbGUudmlzdWFsaXphdGlvbi5UYWJsZSgNCiAgICAgIGRvY3VtZW50LmdldEVsZW1l bnRCeUlkKCJiZXR0ZXJ0YWJsZSIpKTsNCg0KICBkcmF3X2ZpbGVzKCk7DQp9DQoNCmZ1bmN0aW9u IGRyYXdfZmlsZXMoKSB7DQogIHZhciBjc3NDbGFzc05hbWVzID0gew0KICAgICAgJ2hlYWRlclJv dyc6ICdibHVlLWZvbnQgc21hbGwtZm9udCBib2xkLWZvbnQgc21hbGwtbWFyZ2luJywNCiAgICAg ICd0YWJsZVJvdyc6ICdzbWFsbC1mb250IHNtYWxsLW1hcmdpbicsDQogICAgICAnb2RkVGFibGVS b3cnOiAnbGlnaHQtZ3JheS1iYWNrZ3JvdW5kIHNtYWxsLWZvbnQgc21hbGwtbWFyZ2luJywNCiAg ICAgICdzZWxlY3RlZFRhYmxlUm93JzogJ29yYW5nZS1iYWNrZ3JvdW5kIHNtYWxsLWZvbnQnLA0K ICAgICAgJ2hvdmVyVGFibGVSb3cnOiAnc21hbGwtZm9udCBoZWFkZXItc3R5bGUnLA0KICAgICAg J2hlYWRlckNlbGwnOiAnaGVhZGVyLXN0eWxlIHNtYWxsLW1hcmdpbicsDQogICAgICAndGFibGVD ZWxsJzogJ3NtYWxsLW1hcmdpbid9Ow0KDQogIHZhciBvcHRpb25zID0geydhbGxvd0h0bWwnOiB0 cnVlfTsNCiAgaWYgKGJldHRlciAhPSAwKSBkZWxldGUgYmV0dGVyOw0KDQogIGNvbD1ldmFsKGZ0 YWJsZSsnW2NvbHVtbl0nKQ0KICBiZXR0ZXIgPSBuZXcgZ29vZ2xlLnZpc3VhbGl6YXRpb24uRGF0 YVRhYmxlKGNvbCkNCg0KICAvLyBQeXRob24gVGVtcGxhdGUgY29kZSByZXBsYWNlcyB0aGUgZm9s bG93aW5nIGxpbmUgd2l0aCBhIGxpc3Qgb2YNCiAgLy8gZm9ybWF0dGVycy4NCiAgaWYgKGZ0YWJs ZSA9PSAnZmlsZXN0YWJsZV9kc25yJykNCiAgICBmb3JtYXR0ZXIgPSBuZXcgZ29vZ2xlLnZpc3Vh bGl6YXRpb24uTnVtYmVyRm9ybWF0KA0KICAgICAge2ZyYWN0aW9uRGlnaXRzOiA0LCBzdWZmaXg6 IiBkYiJ9KTsNCiAgZWxzZQ0KICAgIGZvcm1hdHRlciA9IG5ldyBnb29nbGUudmlzdWFsaXphdGlv bi5OdW1iZXJGb3JtYXQoDQogICAgICAge2ZyYWN0aW9uRGlnaXRzOiA0LCBzdWZmaXg6IiUifSk7 DQoNCiAgICAgZm9ybWF0dGVyLmZvcm1hdChiZXR0ZXIsIDEpOw0KDQogIGJldHRlcnRhYmxlLmRy YXcoYmV0dGVyLG9wdGlvbnMpOw0KICBnb29nbGUudmlzdWFsaXphdGlvbi5ldmVudHMuYWRkTGlz dGVuZXIoYmV0dGVydGFibGUsICdzZWxlY3QnLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc2VsZWN0QmV0dGVySGFuZGxlcik7DQogIHF1ZXJ5X2ZpbGUoKQ0KfQ0K DQpmdW5jdGlvbiBxdWVyeV9maWxlKCkgew0KICBpbWFnZXN0ciA9IGJldHRlci5nZXRGb3JtYXR0 ZWRWYWx1ZShzZWxlY3RlZCwgMCkNCiAgdmFyIG1ldHJpY2pzb24gPSBldmFsKCcoJyArIHNucnNb Y29sdW1uXVtzZWxlY3RlZF0gKyAnKScpOw0KICBtZXRyaWNkYXRhID0gbmV3IGdvb2dsZS52aXN1 YWxpemF0aW9uLkRhdGFUYWJsZShtZXRyaWNqc29uLCAwLjYpOw0KICBpZiggbWV0cmljdmlldyAh PSAwICkgZGVsZXRlIG1ldHJpY3ZpZXc7DQogIG1ldHJpY3ZpZXcgPSBuZXcgZ29vZ2xlLnZpc3Vh bGl6YXRpb24uRGF0YVZpZXcobWV0cmljZGF0YSk7DQoNCiAgY2hhcnQuZHJhdyhtZXRyaWN2aWV3 LCB7Y3VydmVUeXBlOidmdW5jdGlvbicsDQogICAgICBjaGFydEFyZWE6e2xlZnQ6Y2hhcnRfbGVm dCwgdG9wOmNoYXJ0X3RvcCwgd2lkdGg6Y2hhcnRfd2lkdGgsDQogICAgICBoZWlnaHQ6Y2hhcnRf aGVpZ2h0LTkwfSwNCiAgICAgIGhBeGlzOnt0aXRsZToiZGF0YXJhdGUgaW4ga2JwcyJ9LCB2QXhp czp7dGl0bGU6InF1YWxpdHkgaW4gZGVjaWJlbHMifSwNCiAgICAgIGxlZ2VuZDp7cG9zaXRpb246 ImluIn0sIHRpdGxlOmltYWdlc3RyLCBwb2ludFNpemU6MiwgbGluZVdpZHRoOjEsDQogICAgICB3 aWR0aDpjaGFydF93aWR0aCwgaGVpZ2h0OmNoYXJ0X2hlaWdodC01MCB9KTsNCg0KICBnb29nbGUu dmlzdWFsaXphdGlvbi5ldmVudHMuYWRkTGlzdGVuZXIoY2hhcnQsICdzZWxlY3QnLCBjaGFydFNl bGVjdCk7DQogIGdvb2dsZS52aXN1YWxpemF0aW9uLmV2ZW50cy5hZGRMaXN0ZW5lcihjaGFydCwg J29ubW91c2VvdmVyJywgY2hhcnRNb3VzZU92ZXIpOw0KICBnb29nbGUudmlzdWFsaXphdGlvbi5l dmVudHMuYWRkTGlzdGVuZXIoY2hhcnQsICdvbm1vdXNlb3V0JywgY2hhcnRNb3VzZU91dCk7DQp9 DQoNCmZ1bmN0aW9uIGNoYXJ0TW91c2VPdXQoZSkgew0KICBzdGF0dXNiYXIgPSBkb2N1bWVudC5n ZXRFbGVtZW50QnlJZCgnc3RhdHVzJyk7DQogIHN0YXR1c2Jhci5zdHlsZS5kaXNwbGF5ID0gJ25v bmUnOw0KfQ0KDQpmdW5jdGlvbiBjaGFydE1vdXNlT3ZlcihlKSB7DQogIHBvaW50RGlmZmVyZW5j ZShlLnJvdywgZS5jb2x1bW4pDQp9DQoNCmZ1bmN0aW9uIHBvaW50RGlmZmVyZW5jZShyb3csIGNv bCkgew0KICBpZighcm93IHx8ICFjb2wpDQogICAgcmV0dXJuOw0KDQogIHZhciBjb2xzID0gbWV0 cmljZGF0YS5nZXROdW1iZXJPZkNvbHVtbnMoKTsNCiAgdmFyIHJvd3MgPSBtZXRyaWNkYXRhLmdl dE51bWJlck9mUm93cygpOw0KDQogIHZhciBzZWxfYml0cmF0ZSA9IG1ldHJpY3ZpZXcuZ2V0VmFs dWUocm93LCAwICk7DQogIHZhciBzZWxfbWV0cmljID0gbWV0cmljdmlldy5nZXRWYWx1ZShyb3cs IGNvbCk7DQoNCiAgdmFyIG1lc3NhZ2UgPSAiQXQgIiArIHNlbF9tZXRyaWMudG9GaXhlZCgyKSAr ICIgZGVjaWJlbHMsIDxlbT4iDQogIG1lc3NhZ2UgPSBtZXNzYWdlICsgbWV0cmljZGF0YS5nZXRD b2x1bW5MYWJlbChjb2wpICsgIjwvZW0+IGlzIDx1bD4iDQoNCiAgLy8gY29sIDAgaXMgZGF0YXJh dGUNCiAgZm9yKCB2YXIgaT0xO2k8Y29sczsrK2kpIHsNCg0KICAgIHZhciBtZXRyaWNfZ3JlYXRl c3RfdGhhdHNfbGVzcyA9IDA7DQogICAgdmFyIHJhdGVfZ3JlYXRlc3RfdGhhdHNfbGVzcyA9IDA7 DQogICAgdmFyIG1ldHJpY19zbWFsbGVzdF90aGF0c19ncmVhdGVyID0gOTk5Ow0KICAgIHZhciBy YXRlX3NtYWxsZXN0X3RoYXRzX2dyZWF0ZXIgPSAwOw0KDQogICAgaWYoaT09Y29sKQ0KICAgICAg Y29udGludWU7DQoNCiAgICAvLyBGaW5kIHRoZSBsb3dlc3QgbWV0cmljIGZvciB0aGUgY29sdW1u IHRoYXQncyBncmVhdGVyIHRoYW4gc2VsX21ldHJpYyBhbmQNCiAgICAvLyB0aGUgaGlnaGVzdCBt ZXRyaWMgZm9yIHRoaXMgY29sdW1uIHRoYXQncyBsZXNzIHRoYW4gdGhlIG1ldHJpYy4NCiAgICBm b3IodmFyIGxpbmVfY291bnQgPSAwOyBsaW5lX2NvdW50IDwgcm93czsgKytsaW5lX2NvdW50KSB7 DQogICAgICB0aGlzX21ldHJpYyA9IG1ldHJpY2RhdGEuZ2V0VmFsdWUobGluZV9jb3VudCwgaSkN CiAgICAgIHRoaXNfcmF0ZSA9IG1ldHJpY2RhdGEuZ2V0VmFsdWUobGluZV9jb3VudCwgMCkNCiAg ICAgIGlmKCF0aGlzX21ldHJpYykNCiAgICAgICAgY29udGludWU7DQoNCiAgICAgIGlmKHRoaXNf bWV0cmljID4gbWV0cmljX2dyZWF0ZXN0X3RoYXRzX2xlc3MgJiYNCiAgICAgICAgIHRoaXNfbWV0 cmljIDwgc2VsX21ldHJpYykgew0KICAgICAgICBtZXRyaWNfZ3JlYXRlc3RfdGhhdHNfbGVzcyA9 IHRoaXNfbWV0cmljOw0KICAgICAgICByYXRlX2dyZWF0ZXN0X3RoYXRzX2xlc3MgPSB0aGlzX3Jh dGU7DQogICAgICB9DQogICAgICBpZih0aGlzX21ldHJpYyA8IG1ldHJpY19zbWFsbGVzdF90aGF0 c19ncmVhdGVyICYmDQogICAgICAgIHRoaXNfbWV0cmljID4gc2VsX21ldHJpYykgew0KICAgICAg ICBtZXRyaWNfc21hbGxlc3RfdGhhdHNfZ3JlYXRlciA9IHRoaXNfbWV0cmljOw0KICAgICAgICBy YXRlX3NtYWxsZXN0X3RoYXRzX2dyZWF0ZXIgPSB0aGlzX3JhdGU7DQogICAgICB9DQogICAgfQ0K DQogICAgaWYocmF0ZV9zbWFsbGVzdF90aGF0c19ncmVhdGVyID09IDAgfHwgcmF0ZV9ncmVhdGVz dF90aGF0c19sZXNzID09IDApIHsNCiAgICAgIG1lc3NhZ2UgPSBtZXNzYWdlICsgIiA8bGk+IENv dWxkbid0IGZpbmQgYSBwb2ludCBvbiBib3RoIHNpZGVzLjwvbGk+Ig0KICAgIH0gZWxzZSB7DQog ICAgICBtZXRyaWNfc2xvcGUgPSAoIHJhdGVfc21hbGxlc3RfdGhhdHNfZ3JlYXRlciAtIHJhdGVf Z3JlYXRlc3RfdGhhdHNfbGVzcykgLw0KICAgICAgICAgICggbWV0cmljX3NtYWxsZXN0X3RoYXRz X2dyZWF0ZXIgLSBtZXRyaWNfZ3JlYXRlc3RfdGhhdHNfbGVzcyk7DQoNCiAgICAgIHByb2plY3Rl ZF9yYXRlID0gKCBzZWxfbWV0cmljIC0gbWV0cmljX2dyZWF0ZXN0X3RoYXRzX2xlc3MpICoNCiAg ICAgICAgICBtZXRyaWNfc2xvcGUgKyByYXRlX2dyZWF0ZXN0X3RoYXRzX2xlc3M7DQoNCiAgICAg IGRpZmZlcmVuY2UgPSAxMDAgKiAocHJvamVjdGVkX3JhdGUgLyBzZWxfYml0cmF0ZSAtIDEpOw0K DQoNCiAgICAgIGlmIChkaWZmZXJlbmNlID4gMCkNCiAgICAgICAgbWVzc2FnZSA9IG1lc3NhZ2Ug KyAiPGxpPiAgIiArIGRpZmZlcmVuY2UudG9GaXhlZCgyKSArDQogICAgICAgICAgICAgICAgICAi JSBzbWFsbGVyIHRoYW4gPGVtPiIgKw0KICAgICAgICAgICAgICAgICAgbWV0cmljZGF0YS5nZXRD b2x1bW5MYWJlbChpKSArICI8L2VtPjwvbGk+ICINCiAgICAgIGVsc2UNCiAgICAgICAgbWVzc2Fn ZSA9IG1lc3NhZ2UgKyAiPGxpPiAgIiArIC1kaWZmZXJlbmNlLnRvRml4ZWQoMikgKw0KICAgICAg ICAgICAgICAgICAgIiUgYmlnZ2VyIHRoYW4gPGVtPiIgKw0KICAgICAgICAgICAgICAgICAgbWV0 cmljZGF0YS5nZXRDb2x1bW5MYWJlbChpKSArICI8L2VtPjwvbGk+ICINCiAgICB9DQoNCiAgfQ0K ICBtZXNzYWdlID0gbWVzc2FnZSArICI8L3VsPiINCiAgc3RhdHVzYmFyID0gZG9jdW1lbnQuZ2V0 RWxlbWVudEJ5SWQoJ3N0YXR1cycpOw0KICBzdGF0dXNiYXIuaW5uZXJIVE1MID0gIjxwPiIgKyBt ZXNzYWdlICsgIjwvcD4iOw0KICBzdGF0dXNiYXIuc3R5bGUuZGlzcGxheSA9ICdibG9jayc7DQp9 DQoNCmZ1bmN0aW9uIGNoYXJ0U2VsZWN0KCkgew0KICB2YXIgc2VsZWN0aW9uID0gY2hhcnQuZ2V0 U2VsZWN0aW9uKCk7DQogIHZhciBtZXNzYWdlID0gJyc7DQogIHZhciBtaW4gPSBtZXRyaWN2aWV3 LmdldEZvcm1hdHRlZFZhbHVlKHNlbGVjdGlvblswXS5yb3csIDApOw0KICB2YXIgbWF4ID0gbWV0 cmljdmlldy5nZXRGb3JtYXR0ZWRWYWx1ZShzZWxlY3Rpb25bc2VsZWN0aW9uLmxlbmd0aC0xXS5y b3csIDApOw0KICB2YXIgdmFsID0gbWV0cmljdmlldy5nZXRGb3JtYXR0ZWRWYWx1ZShzZWxlY3Rp b25bMF0ucm93LHNlbGVjdGlvblswXS5jb2x1bW4pOw0KDQogIHBvaW50RGlmZmVyZW5jZShzZWxl Y3Rpb25bMF0ucm93LCBzZWxlY3Rpb25bMF0uY29sdW1uKQ0KICBtaW4gPSBtaW4gLyAzDQogIG1h eCA9IG1heCAqIDMNCiAgbWV0cmljdmlldy5zZXRSb3dzKG1ldHJpY2RhdGEuZ2V0RmlsdGVyZWRS b3dzKA0KICAgICAgW3tjb2x1bW46IDAsbWluVmFsdWU6IG1pbiwgbWF4VmFsdWU6bWF4fV0pKTsN Cg0KICBjaGFydC5kcmF3KG1ldHJpY3ZpZXcsIHtjdXJ2ZVR5cGU6J2Z1bmN0aW9uJywNCiAgICAg IGNoYXJ0QXJlYTp7bGVmdDo0MCwgdG9wOjEwLCB3aWR0aDpjaGFydF93aWR0aCwgaGVpZ2h0OmNo YXJ0X2hlaWdodCAtIDExMH0sDQogICAgICBoQXhpczp7dGl0bGU6ImRhdGFyYXRlIGluIGticHMi fSwgdkF4aXM6e3RpdGxlOiJxdWFsaXR5IGluIGRlY2liZWxzIn0sDQogICAgICBsZWdlbmQ6e3Bv c2l0aW9uOiJpbiJ9LCB0aXRsZTppbWFnZXN0ciwgcG9pbnRTaXplOjIsIGxpbmVXaWR0aDoxLA0K ICAgICAgd2lkdGg6Y2hhcnRfd2lkdGgsIGhlaWdodDpjaGFydF9oZWlnaHQgLSA1MH0pOw0KfQ0K DQpmdW5jdGlvbiBzZWxlY3RCZXR0ZXJIYW5kbGVyKCkgew0KICB2YXIgc2VsZWN0aW9uID0gYmV0 dGVydGFibGUuZ2V0U2VsZWN0aW9uKCk7DQogIGZvciAodmFyIGkgPSAwOyBpIDwgc2VsZWN0aW9u Lmxlbmd0aDsgaSsrKSB7DQogICAgaXRlbSA9IHNlbGVjdGlvbltpXTsNCiAgfQ0KICBzZWxlY3Rl ZCA9IGl0ZW0ucm93DQogIHF1ZXJ5X2ZpbGUoKQ0KfQ0KDQpnb29nbGUubG9hZCgndmlzdWFsaXph dGlvbicsICcxJywgeydwYWNrYWdlcycgOiBbJ2NvcmVjaGFydCcsJ3RhYmxlJ119KTsNCmdvb2ds ZS5zZXRPbkxvYWRDYWxsYmFjayhzZXR1cF92aXMpOw0KPC9zY3JpcHQ+DQo8L2hlYWQ+DQoNCjxi b2R5Pg0KDQogIDxkaXYgY2xhc3M9ImNvbnRhaW5lcl8xMiI+DQoNCiAgICA8ZGl2IGNsYXNzPSJn cmlkXzEyIGhlYWRlciI+DQogICAgICA8aDI+VlA4IFJlc3VsdHM8L2gyPg0KICAgIDwvZGl2Pg0K DQogICAgPGRpdiBjbGFzcz0iZ3JpZF8xMiByYWRpbyI+DQoNCiAgICA8ZGl2IGNsYXNzPSJncmlk XzEyIG1haW4iPg0KDQogICAgICA8ZGl2IGNsYXNzPSJncmlkXzUgYWxwaGEgY2xpcGxpc3QiPg0K ICAgICAgICA8ZGl2IGlkPSJiZXR0ZXJ0YWJsZSI+PC9kaXY+DQogICAgICA8L2Rpdj4NCg0KICAg ICAgPGRpdiBjbGFzcz0iZ3JpZF81IGNoYXJ0YXJlYSI+DQogICAgICAgIDxkaXYgaWQ9Im1ldHJp Y2dyYXBoIj48L2Rpdj4NCiAgICAgIDwvZGl2Pg0KDQogICAgICA8ZGl2IGNsYXNzPSJncmlkXzIg b21lZ2EgaW5kaWNhdG9ycyI+DQogICAgICAgIDxkaXYgY2xhc3M9ImNvbnRlbnQiPg0KICAgICAg ICAgIDxoNT5JbmRpY2F0b3JzPC9oNT4NCiAgICAgICAgICA8aHI+DQogICAgICAgICAgPGRpdiBp ZD0ic3RhdHVzIj48L2Rpdj4NCiAgICAgICAgPC9kaXY+DQogICAgICA8L2Rpdj4NCg0KICAgIDwv ZGl2Pg0KDQogIDwvZGl2Pg0KDQo8L2JvZHk+DQo8L2h0bWw+DQoK --_006_BBE9739C2C302046BD34B42713A1E2A22DECC12FESESSMB105erics_ Content-Type: text/html; name="vp8_vs_x264_baseline.html" Content-Description: vp8_vs_x264_baseline.html Content-Disposition: attachment; filename="vp8_vs_x264_baseline.html"; size=22102; creation-date="Sat, 22 Jun 2013 13:41:08 GMT"; modification-date="Sat, 22 Jun 2013 13:41:08 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWw+DQo8aHRtbCBsYW5nPSJlbiI+DQo8aGVhZD4NCjxtZXRhIGNoYXJzZXQ9 InV0Zi04Ij4NCjx0aXRsZT5Db21wYXJhdGl2ZSBSZXN1bHRzPC90aXRsZT4NCjxzdHlsZSB0eXBl PSJ0ZXh0L2NzcyI+DQo8IS0tIEJlZ2luIDk2MCByZXNldCAtLT4NCmEsYWJicixhY3JvbnltLGFk ZHJlc3MsYXBwbGV0LGFydGljbGUsYXNpZGUsYXVkaW8sYixiaWcsYmxvY2txdW90ZSxib2R5LGNh bnZhcyxjYXB0aW9uLGNlbnRlcixjaXRlLGMNCm9kZSxkZCxkZWwsZGV0YWlscyxkZm4sZGlhbG9n LGRpdixkbCxkdCxlbSxlbWJlZCxmaWVsZHNldCxmaWdjYXB0aW9uLGZpZ3VyZSxmb250LGZvb3Rl cixmb3JtLGgxLGgyLGgNCjMsaDQsaDUsaDYsaGVhZGVyLGhncm91cCxocixodG1sLGksaWZyYW1l LGltZyxpbnMsa2JkLGxhYmVsLGxlZ2VuZCxsaSxtYXJrLG1lbnUsbWV0ZXIsbmF2LG9iamVjdCxv bCwNCm91dHB1dCxwLHByZSxwcm9ncmVzcyxxLHJwLHJ0LHJ1YnkscyxzYW1wLHNlY3Rpb24sc21h bGwsc3BhbixzdHJpa2Usc3Ryb25nLHN1YixzdW1tYXJ5LHN1cCx0YWJsZSx0Ym8NCmR5LHRkLHRm b290LHRoLHRoZWFkLHRpbWUsdHIsdHQsdSx1bCx2YXIsdmlkZW8seG1we2JvcmRlcjowO21hcmdp bjowO3BhZGRpbmc6MDtmb250LXNpemU6MTAwJX1odG1sLGINCm9keXtoZWlnaHQ6MTAwJX1hcnRp Y2xlLGFzaWRlLGRldGFpbHMsZmlnY2FwdGlvbixmaWd1cmUsZm9vdGVyLGhlYWRlcixoZ3JvdXAs bWVudSxuYXYsc2VjdGlvbntkaXNwbGENCnk6YmxvY2t9YixzdHJvbmd7Zm9udC13ZWlnaHQ6Ym9s ZH1pbWd7Y29sb3I6dHJhbnNwYXJlbnQ7Zm9udC1zaXplOjA7dmVydGljYWwtYWxpZ246bWlkZGxl Oy1tcy1pbnRlcnANCm9sYXRpb24tbW9kZTpiaWN1YmljfW9sLHVse2xpc3Qtc3R5bGU6bm9uZX1s aXtkaXNwbGF5Omxpc3QtaXRlbX10YWJsZXtib3JkZXItY29sbGFwc2U6Y29sbGFwc2U7Ym9yZGUN CnItc3BhY2luZzowfXRoLHRkLGNhcHRpb257Zm9udC13ZWlnaHQ6bm9ybWFsO3ZlcnRpY2FsLWFs aWduOnRvcDt0ZXh0LWFsaWduOmxlZnR9cXtxdW90ZXM6bm9uZX1xOmJlZm8NCnJlLHE6YWZ0ZXJ7 Y29udGVudDonJztjb250ZW50Om5vbmV9c3ViLHN1cCxzbWFsbHtmb250LXNpemU6NzUlfXN1Yixz dXB7bGluZS1oZWlnaHQ6MDtwb3NpdGlvbjpyZWxhdGkNCnZlO3ZlcnRpY2FsLWFsaWduOmJhc2Vs aW5lfXN1Yntib3R0b206LTAuMjVlbX1zdXB7dG9wOi0wLjVlbX1zdmd7b3ZlcmZsb3c6aGlkZGVu fQ0KPCEtLSBFbmQgOTYwIHJlc2V0IC0tPg0KPCEtLSBCZWdpbiA5NjAgdGV4dCAtLT4NCmJvZHl7 Zm9udDoxM3B4LzEuNSAnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLCdMaWJlcmF0aW9uIFNhbnMnLEZy ZWVTYW5zLHNhbnMtc2VyaWZ9cHJlLGNvZGV7Zm9udC1mYW1pbHkNCjonRGVqYVZ1IFNhbnMgTW9u bycsTWVubG8sQ29uc29sYXMsbW9ub3NwYWNlfWhye2JvcmRlcjowICNjY2Mgc29saWQ7Ym9yZGVy LXRvcC13aWR0aDoxcHg7Y2xlYXI6Ym90aDsNCmhlaWdodDowfWgxe2ZvbnQtc2l6ZToyNXB4fWgy e2ZvbnQtc2l6ZToyM3B4fWgze2ZvbnQtc2l6ZToyMXB4fWg0e2ZvbnQtc2l6ZToxOXB4fWg1e2Zv bnQtc2l6ZToxN3B4fWgNCjZ7Zm9udC1zaXplOjE1cHh9b2x7bGlzdC1zdHlsZTpkZWNpbWFsfXVs e2xpc3Qtc3R5bGU6ZGlzY31saXttYXJnaW4tbGVmdDozMHB4fXAsZGwsaHIsaDEsaDIsaDMsaDQs aDUNCixoNixvbCx1bCxwcmUsdGFibGUsYWRkcmVzcyxmaWVsZHNldCxmaWd1cmV7bWFyZ2luLWJv dHRvbToyMHB4fQ0KPCEtLSBFbmQgOTYwIHRleHQgLS0+DQo8IS0tIEJlZ2luIDk2MCBncmlkIChm bHVpZCB2YXJpYW50KQ0KICAgICAxMiBjb2x1bW5zLCAxMTUycHggdG90YWwgd2lkdGgNCiAgICAg aHR0cDovLzk2MC5ncy8gfCBodHRwOi8vZ3JpZHMuaGVyb2t1LmNvbS8gLS0+DQouY29udGFpbmVy XzEye3dpZHRoOjkyJTttYXJnaW4tbGVmdDo0JTttYXJnaW4tcmlnaHQ6NCV9LmdyaWRfMSwuZ3Jp ZF8yLC5ncmlkXzMsLmdyaWRfNCwuZ3JpZF81LC5ncmlkDQpfNiwuZ3JpZF83LC5ncmlkXzgsLmdy aWRfOSwuZ3JpZF8xMCwuZ3JpZF8xMSwuZ3JpZF8xMntkaXNwbGF5OmlubGluZTtmbG9hdDpsZWZ0 O3Bvc2l0aW9uOnJlbGF0aXZlO21hDQpyZ2luLWxlZnQ6MSU7bWFyZ2luLXJpZ2h0OjElfS5hbHBo YXttYXJnaW4tbGVmdDowfS5vbWVnYXttYXJnaW4tcmlnaHQ6MH0uY29udGFpbmVyXzEyIC5ncmlk XzF7d2lkdGg6DQo2LjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF8ye3dpZHRoOjE0LjY2NyV9LmNv bnRhaW5lcl8xMiAuZ3JpZF8ze3dpZHRoOjIzLjAlfS5jb250YWluZXJfMTIgLmdyaWRfNHt3DQpp ZHRoOjMxLjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF81e3dpZHRoOjM5LjY2NyV9LmNvbnRhaW5l cl8xMiAuZ3JpZF82e3dpZHRoOjQ4LjAlfS5jb250YWluZXJfMTIgLmdyDQppZF83e3dpZHRoOjU2 LjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF84e3dpZHRoOjY0LjY2NyV9LmNvbnRhaW5lcl8xMiAu Z3JpZF85e3dpZHRoOjczLjAlfS5jb250YWluZXJfDQoxMiAuZ3JpZF8xMHt3aWR0aDo4MS4zMzMl fS5jb250YWluZXJfMTIgLmdyaWRfMTF7d2lkdGg6ODkuNjY3JX0uY29udGFpbmVyXzEyIC5ncmlk XzEye3dpZHRoOjk4LjAlfS5jDQpvbnRhaW5lcl8xMiAucHJlZml4XzF7cGFkZGluZy1sZWZ0Ojgu MzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfMntwYWRkaW5nLWxlZnQ6MTYuNjY3JX0uY29udGFp bmVyXzEyDQogLnByZWZpeF8ze3BhZGRpbmctbGVmdDoyNS4wJX0uY29udGFpbmVyXzEyIC5wcmVm aXhfNHtwYWRkaW5nLWxlZnQ6MzMuMzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfNXtwDQphZGRp bmctbGVmdDo0MS42NjclfS5jb250YWluZXJfMTIgLnByZWZpeF82e3BhZGRpbmctbGVmdDo1MC4w JX0uY29udGFpbmVyXzEyIC5wcmVmaXhfN3twYWRkaW5nLWxlZnQ6DQo1OC4zMzMlfS5jb250YWlu ZXJfMTIgLnByZWZpeF84e3BhZGRpbmctbGVmdDo2Ni42NjclfS5jb250YWluZXJfMTIgLnByZWZp eF85e3BhZGRpbmctbGVmdDo3NS4wJX0uY29uDQp0YWluZXJfMTIgLnByZWZpeF8xMHtwYWRkaW5n LWxlZnQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfMTF7cGFkZGluZy1sZWZ0OjkxLjY2 NyV9LmNvbnRhaW5lcl8xDQoyIC5zdWZmaXhfMXtwYWRkaW5nLXJpZ2h0OjguMzMzJX0uY29udGFp bmVyXzEyIC5zdWZmaXhfMntwYWRkaW5nLXJpZ2h0OjE2LjY2NyV9LmNvbnRhaW5lcl8xMiAuc3Vm Zml4DQpfM3twYWRkaW5nLXJpZ2h0OjI1LjAlfS5jb250YWluZXJfMTIgLnN1ZmZpeF80e3BhZGRp bmctcmlnaHQ6MzMuMzMzJX0uY29udGFpbmVyXzEyIC5zdWZmaXhfNXtwYWRkaW5nDQotcmlnaHQ6 NDEuNjY3JX0uY29udGFpbmVyXzEyIC5zdWZmaXhfNntwYWRkaW5nLXJpZ2h0OjUwLjAlfS5jb250 YWluZXJfMTIgLnN1ZmZpeF83e3BhZGRpbmctcmlnaHQ6NTguDQozMzMlfS5jb250YWluZXJfMTIg LnN1ZmZpeF84e3BhZGRpbmctcmlnaHQ6NjYuNjY3JX0uY29udGFpbmVyXzEyIC5zdWZmaXhfOXtw YWRkaW5nLXJpZ2h0Ojc1LjAlfS5jb250DQphaW5lcl8xMiAuc3VmZml4XzEwe3BhZGRpbmctcmln aHQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5zdWZmaXhfMTF7cGFkZGluZy1yaWdodDo5MS42Njcl fS5jb250YWluZXJfDQoxMiAucHVzaF8xe2xlZnQ6OC4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hf MntsZWZ0OjE2LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVzaF8ze2xlZnQ6MjUuMCV9LmNvbnRhaW5l DQpyXzEyIC5wdXNoXzR7bGVmdDozMy4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hfNXtsZWZ0OjQx LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVzaF82e2xlZnQ6NTAuMCV9LmNvbnRhDQppbmVyXzEyIC5w dXNoXzd7bGVmdDo1OC4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hfOHtsZWZ0OjY2LjY2NyV9LmNv bnRhaW5lcl8xMiAucHVzaF85e2xlZnQ6NzUuMCV9LmNvDQpudGFpbmVyXzEyIC5wdXNoXzEwe2xl ZnQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5wdXNoXzExe2xlZnQ6OTEuNjY3JX0uY29udGFpbmVy XzEyIC5wdWxsXzF7bGVmdDotOC4zDQozMyV9LmNvbnRhaW5lcl8xMiAucHVsbF8ye2xlZnQ6LTE2 LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVsbF8ze2xlZnQ6LTI1LjAlfS5jb250YWluZXJfMTIgLnB1 bGxfNHtsZWZ0DQo6LTMzLjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF81e2xlZnQ6LTQxLjY2NyV9 LmNvbnRhaW5lcl8xMiAucHVsbF82e2xlZnQ6LTUwLjAlfS5jb250YWluZXJfMTIgLnB1bGxfDQo3 e2xlZnQ6LTU4LjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF84e2xlZnQ6LTY2LjY2NyV9LmNvbnRh aW5lcl8xMiAucHVsbF85e2xlZnQ6LTc1LjAlfS5jb250YWluZXJfMTINCi5wdWxsXzEwe2xlZnQ6 LTgzLjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF8xMXtsZWZ0Oi05MS42NjclfS5jbGVhcntjbGVh cjpib3RoO2Rpc3BsYXk6YmxvY2s7b3ZlcmZsb3cNCjpoaWRkZW47dmlzaWJpbGl0eTpoaWRkZW47 d2lkdGg6MDtoZWlnaHQ6MH0uY2xlYXJmaXg6YWZ0ZXJ7Y2xlYXI6Ym90aDtjb250ZW50OicgJztk aXNwbGF5OmJsb2NrO2ZvbnQNCi1zaXplOjA7bGluZS1oZWlnaHQ6MDt2aXNpYmlsaXR5OmhpZGRl bjt3aWR0aDowO2hlaWdodDowfS5jbGVhcmZpeHtkaXNwbGF5OmlubGluZS1ibG9ja30qIGh0bWwg LmNsZWENCnJmaXh7aGVpZ2h0OjElfS5jbGVhcmZpeHtkaXNwbGF5OmJsb2NrfQ0KPCEtLSBFbmQg OTYwIGdyaWQgLS0+DQoNCmRpdi5tZXRyaWNncmFwaCB7DQoNCn0NCg0KYm9keSB7DQoNCn0NCg0K ZGl2LmhlYWRlciB7DQogIGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsNCn0NCg0KZGl2 LmhlYWRlciBoMiB7DQogIG1hcmdpbjogLjVlbSBhdXRvOw0KfQ0KDQpkaXYucmFkaW8gew0KICBm b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7DQogIG1hcmdpbi1ib3R0b206IDFlbTsNCn0N Cg0KZGl2Lm1haW4gew0KDQp9DQoNCmRpdi5jbGlwbGlzdCB7DQogIGZvbnQtZmFtaWx5OiBBcmlh bCwgc2Fucy1zZXJpZjsNCiAgbWFyZ2luLXRvcDogNnB4Ow0KfQ0KDQpkaXYuY2hhcnRhcmVhIHsN CiAgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOw0KfQ0KDQpkaXYuaW5kaWNhdG9ycyB7 DQogIGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsNCiAgZm9udC1zaXplOiAxM3B4Ow0K ICBtYXJnaW4tdG9wOiA2cHg7DQogIG1pbi1oZWlnaHQ6IDYwMHB4Ow0KICBiYWNrZ3JvdW5kLWNv bG9yOiAjZjdmN2Y3Ow0KfQ0KDQpkaXYuaW5kaWNhdG9ycyBkaXYuY29udGVudCB7DQogIG1hcmdp bjogMWVtOw0KfQ0KDQpkaXYuaW5kaWNhdG9ycyBkaXYuY29udGVudCBoNSB7DQogIGZvbnQtc2l6 ZTogMTNweDsNCiAgdGV4dC1hbGlnbjogY2VudGVyOw0KICBtYXJnaW46IDA7DQp9DQoNCmRpdi5p bmRpY2F0b3JzIGRpdi5jb250ZW50IHVsIHsNCiAgbWFyZ2luLWxlZnQ6IDA7DQogIHBhZGRpbmct bGVmdDogMDsNCiAgbWFyZ2luLXRvcDogMDsNCn0NCg0KZGl2LmluZGljYXRvcnMgZGl2LmNvbnRl bnQgdWwgbGkgew0KICBtYXJnaW4tbGVmdDogMS41ZW07DQp9DQoNCmRpdi5pbmRpY2F0b3JzIGRp di5jb250ZW50IHA6Zmlyc3QtY2hpbGQgew0KICBtYXJnaW4tYm90dG9tOiAuNWVtOw0KfQ0KDQpz cGFuLmdvb2dsZS12aXN1YWxpemF0aW9uLXRhYmxlLXNvcnRpbmQgew0KICBjb2xvcjogIzAwMDsN Cn0NCg0KLmhlYWRlci1zdHlsZSB7DQogIGZvbnQtd2VpZ2h0OiBib2xkOw0KICBib3JkZXI6IDFw eCBzb2xpZCAjZmZmOw0KICBiYWNrZ3JvdW5kLWNvbG9yOiAjY2NjOw0KfQ0KDQp0ZC5oZWFkZXIt c3R5bGUrdGQgew0KDQp9DQoNCi5vcmFuZ2UtYmFja2dyb3VuZCB7DQogIGJhY2tncm91bmQtY29s b3I6IG9yYW5nZTsNCn0NCg0KLmxpZ2h0LWdyYXktYmFja2dyb3VuZCB7DQogIGJhY2tncm91bmQt Y29sb3I6ICNmMGYwZjA7DQp9DQo8L3N0eWxlPg0KPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3Jp cHQiIHNyYz0iaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9qc2FwaSI+PC9zY3JpcHQ+DQo8c2NyaXB0 IHR5cGU9InRleHQvamF2YXNjcmlwdCI+DQpnb29nbGUubG9hZCgndmlzdWFsaXphdGlvbicsICcx LjEnLCB7J3BhY2thZ2VzJzpbJ3RhYmxlJ119KTsNCnZhciBjaGFydF9sZWZ0ICAgPSA2MDsNCnZh ciBjaGFydF90b3AgICAgPSA2Ow0KdmFyIGNoYXJ0X2hlaWdodCA9IGRvY3VtZW50LmRvY3VtZW50 RWxlbWVudC5jbGllbnRIZWlnaHQtMTAwOw0KdmFyIGNoYXJ0X3dpZHRoICA9ICIxMDAlIjsNCmZ0 YWJsZT0nZmlsZXN0YWJsZV9hdmcnDQp2YXIgc25ycyA9IFtdOw0KdmFyIGZpbGVzdGFibGVfZHNu ciA9IFtdOw0KdmFyIGZpbGVzdGFibGVfZHJhdGUgPSBbXTsNCnZhciBmaWxlc3RhYmxlX2F2ZyA9 IFtdOw0KDQovLyBQeXRob24gdGVtcGxhdGUgY29kZSByZXBsYWNlcyB0aGUgZm9sbG93aW5nIDIg bGluZXMuDQpmaWxlc3RhYmxlX2RzbnJbMV09eyJyb3dzIjpbeyJjIjpbeyJ2IjoiZGVza3RvcF82 NDBfMzYwXzMwIn0seyJ2IjowLjEwODA0MTg2MDAwMjcyMDk3fV19LHsiYyI6W3sidiI6ImdpcHNy ZWNtb3Rpb25fMTI4MF83MjBfNTAifSx7InYiOi0wLjE2MDUyMjAzMDgzNDk5ODg2fV19LHsiYyI6 W3sidiI6ImdpcHNyZWNzdGF0XzEyODBfNzIwXzUwIn0seyJ2IjowLjIzNjkxOTczMDA5OTU0OTEx fV19LHsiYyI6W3sidiI6ImtpcmxhbmRfNjQwXzQ4MF8zMCJ9LHsidiI6MC4zMTM5NTg2NjkxODg1 MzQ3MX1dfSx7ImMiOlt7InYiOiJtYWNtYXJjb21vdmluZ182NDBfNDgwXzMwIn0seyJ2IjotMC4y MDA1MzA3OTU1MDk5NjI5Mn1dfSx7ImMiOlt7InYiOiJtYWNtYXJjb3N0YXRpb25hcnlfNjQwXzQ4 MF8zMCJ9LHsidiI6LTAuMDMzNTA3NDgzOTIzNDg5OTU2fV19LHsiYyI6W3sidiI6Im5pa2xhc18x MjgwXzcyMF8zMCJ9LHsidiI6LTAuMTQ3NDEyMDA4MDYyMzgyNjd9XX0seyJjIjpbeyJ2Ijoibmlr bGFzXzY0MF80ODBfMzAifSx7InYiOi0wLjM5MTIwNzE1NzI0MDY5MTMzfV19LHsiYyI6W3sidiI6 InRhY29tYW5hcnJvd3NfNjQwXzQ4MF8zMCJ9LHsidiI6MC42NDc3OTA2NjY0MzU2NjI4NX1dfSx7 ImMiOlt7InYiOiJ0YWNvbWFzbWFsbGNhbWVyYW1vdmVtZW50XzY0MF80ODBfMzAifSx7InYiOi0w LjA5NTgyMTg4MDAzMTM3OTAwOX1dfSx7ImMiOlt7InYiOiJ0aGFsb3VuZGVza210Z182NDBfNDgw XzMwIn0seyJ2IjowLjQxNTczMDE3OTAzMDQ0MzY4fV19LHsiYyI6W3sidiI6Ik9WRVJBTEwifSx7 InYiOjAuMDYzMDM5OTc3MTk1ODE4Nzc1fV19XSwiY29scyI6W3sidHlwZSI6InN0cmluZyIsImlk IjoiZmlsZSIsImxhYmVsIjoiRmlsZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMveDI2 NF9iYXNlbGluZSIsImxhYmVsIjoic3RhdHMveDI2NF9iYXNlbGluZSJ9XX0KDQpmaWxlc3RhYmxl X2F2Z1sxXT17InJvd3MiOlt7ImMiOlt7InYiOiJkZXNrdG9wXzY0MF8zNjBfMzAifSx7InYiOjIu NTI2NzcyMTc0MjUyMDAzN31dfSx7ImMiOlt7InYiOiJnaXBzcmVjbW90aW9uXzEyODBfNzIwXzUw In0seyJ2IjotNC40OTY4OTg4MTg2MTY1ODR9XX0seyJjIjpbeyJ2IjoiZ2lwc3JlY3N0YXRfMTI4 MF83MjBfNTAifSx7InYiOjkuOTQzMjczNDQ5OTM5NDF9XX0seyJjIjpbeyJ2Ijoia2lybGFuZF82 NDBfNDgwXzMwIn0seyJ2Ijo3LjEwMjAyMjE3Mjk2ODU4MX1dfSx7ImMiOlt7InYiOiJtYWNtYXJj b21vdmluZ182NDBfNDgwXzMwIn0seyJ2IjotOC41MzIwODEwMzYxMDg4NTh9XX0seyJjIjpbeyJ2 IjoibWFjbWFyY29zdGF0aW9uYXJ5XzY0MF80ODBfMzAifSx7InYiOjAuNzIwMjIxMjUxNjY1MDM3 NX1dfSx7ImMiOlt7InYiOiJuaWtsYXNfMTI4MF83MjBfMzAifSx7InYiOi03LjAxMDM5MzU1NDQ2 NTYyOX1dfSx7ImMiOlt7InYiOiJuaWtsYXNfNjQwXzQ4MF8zMCJ9LHsidiI6LTguMjc4MTQ1MzA5 NzIxMDAxfV19LHsiYyI6W3sidiI6InRhY29tYW5hcnJvd3NfNjQwXzQ4MF8zMCJ9LHsidiI6MTgu NDEyNTc5Njk5NjE4OTk1fV19LHsiYyI6W3sidiI6InRhY29tYXNtYWxsY2FtZXJhbW92ZW1lbnRf NjQwXzQ4MF8zMCJ9LHsidiI6LTMuNDMzMzg2MDQ4OTQyNjQ3OH1dfSx7ImMiOlt7InYiOiJ0aGFs b3VuZGVza210Z182NDBfNDgwXzMwIn0seyJ2Ijo2LjI5NDAyMjc3NDY0MjkyMX1dfSx7ImMiOlt7 InYiOiJPVkVSQUxMIn0seyJ2IjoxLjIwNDM2MjQzMjI5MzgzOX1dfV0sImNvbHMiOlt7InR5cGUi OiJzdHJpbmciLCJpZCI6ImZpbGUiLCJsYWJlbCI6IkZpbGUifSx7InR5cGUiOiJudW1iZXIiLCJp ZCI6InN0YXRzL3gyNjRfYmFzZWxpbmUiLCJsYWJlbCI6InN0YXRzL3gyNjRfYmFzZWxpbmUifV19 Cg0KZmlsZXN0YWJsZV9kcmF0ZVsxXT17InJvd3MiOlt7ImMiOlt7InYiOiJkZXNrdG9wXzY0MF8z NjBfMzAifSx7InYiOjIuOTg5MjU3NjU4MDMzNjM5NH1dfSx7ImMiOlt7InYiOiJnaXBzcmVjbW90 aW9uXzEyODBfNzIwXzUwIn0seyJ2IjotNC41NzE4ODg3MDkwMTk1NDV9XX0seyJjIjpbeyJ2Ijoi Z2lwc3JlY3N0YXRfMTI4MF83MjBfNTAifSx7InYiOjguNTY3MTQ4MzAwODU1NDU0fV19LHsiYyI6 W3sidiI6ImtpcmxhbmRfNjQwXzQ4MF8zMCJ9LHsidiI6MTAuNTI2MTUyNTQ1NjgwMjMzfV19LHsi YyI6W3sidiI6Im1hY21hcmNvbW92aW5nXzY0MF80ODBfMzAifSx7InYiOi03LjQ3OTg2NzUwMDM2 OTI0Mn1dfSx7ImMiOlt7InYiOiJtYWNtYXJjb3N0YXRpb25hcnlfNjQwXzQ4MF8zMCJ9LHsidiI6 LTAuNjgyNDc2NDEzOTA4NjE3fV19LHsiYyI6W3sidiI6Im5pa2xhc18xMjgwXzcyMF8zMCJ9LHsi diI6LTQuOTE2NjUxNDcwNjMzODkzfV19LHsiYyI6W3sidiI6Im5pa2xhc182NDBfNDgwXzMwIn0s eyJ2IjotNy44MTE3MDQyNDg2MzgyNH1dfSx7ImMiOlt7InYiOiJ0YWNvbWFuYXJyb3dzXzY0MF80 ODBfMzAifSx7InYiOjE5LjUzNTEwOTEyNjAwNjAyNH1dfSx7ImMiOlt7InYiOiJ0YWNvbWFzbWFs bGNhbWVyYW1vdmVtZW50XzY0MF80ODBfMzAifSx7InYiOi0yLjY0NDUzODEyMDE1MTQwNzN9XX0s eyJjIjpbeyJ2IjoidGhhbG91bmRlc2ttdGdfNjQwXzQ4MF8zMCJ9LHsidiI6Ny42ODMyNTEyMTUy NjQ4MDh9XX0seyJjIjpbeyJ2IjoiT1ZFUkFMTCJ9LHsidiI6MS45MjY3MDgzOTg0NjUzODN9XX1d LCJjb2xzIjpbeyJ0eXBlIjoic3RyaW5nIiwiaWQiOiJmaWxlIiwibGFiZWwiOiJGaWxlIn0seyJ0 eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy94MjY0X2Jhc2VsaW5lIiwibGFiZWwiOiJzdGF0cy94 MjY0X2Jhc2VsaW5lIn1dfQoNCnNucnNbMV0gPSBbJ3sicm93cyI6W3siYyI6W3sidiI6MjE2LjM2 fSxudWxsLHsidiI6MzIuNDE0fV19LHsiYyI6W3sidiI6NTIyLjIxfSxudWxsLHsidiI6MzUuNjQy fV19LHsiYyI6W3sidiI6MTI1NC4zfSxudWxsLHsidiI6MzguODh9XX0seyJjIjpbeyJ2IjoyOTI3 LjY4fSxudWxsLHsidiI6NDIuMDIzfV19LHsiYyI6W3sidiI6NTEyLjA0fSx7InYiOjM1LjMyM30s bnVsbF19LHsiYyI6W3sidiI6OTM4LjUzfSx7InYiOjM3LjY5NH0sbnVsbF19LHsiYyI6W3sidiI6 MTcwNy41OH0seyJ2IjozOS45Nn0sbnVsbF19LHsiYyI6W3sidiI6MzU0NC43M30seyJ2Ijo0Mi42 NDF9LG51bGxdfV0sImNvbHMiOlt7InR5cGUiOiJudW1iZXIiLCJpZCI6ImRhdGFyYXRlIiwibGFi ZWwiOiJEYXRhcmF0ZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvdnA4IiwibGFiZWwi OiJzdGF0cy92cDgifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3gyNjRfYmFzZWxpbmUi LCJsYWJlbCI6InN0YXRzL3gyNjRfYmFzZWxpbmUifV19JywneyJyb3dzIjpbeyJjIjpbeyJ2Ijo4 NTEuNzh9LG51bGwseyJ2IjozNC43MTZ9XX0seyJjIjpbeyJ2IjoxNjM0LjQyfSxudWxsLHsidiI6 MzcuNjM0fV19LHsiYyI6W3sidiI6MzUzNy43OX0sbnVsbCx7InYiOjQwLjYzfV19LHsiYyI6W3si diI6ODM2OS44Mn0sbnVsbCx7InYiOjQzLjQxMX1dfSx7ImMiOlt7InYiOjE1MTIuMTV9LHsidiI6 MzcuNDU1fSxudWxsXX0seyJjIjpbeyJ2IjoyNTU1LjU5fSx7InYiOjM5LjY3N30sbnVsbF19LHsi YyI6W3sidiI6NDgxOC41NX0seyJ2Ijo0MS44MjN9LG51bGxdfSx7ImMiOlt7InYiOjEwMzcwLjU4 fSx7InYiOjQzLjk4Mn0sbnVsbF19XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIsImlkIjoiZGF0 YXJhdGUiLCJsYWJlbCI6IkRhdGFyYXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92 cDgiLCJsYWJlbCI6InN0YXRzL3ZwOCJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMveDI2 NF9iYXNlbGluZSIsImxhYmVsIjoic3RhdHMveDI2NF9iYXNlbGluZSJ9XX0nLCd7InJvd3MiOlt7 ImMiOlt7InYiOjM4MC41NX0sbnVsbCx7InYiOjM1LjN9XX0seyJjIjpbeyJ2Ijo3NTYuNTh9LG51 bGwseyJ2IjozOC4xNjl9XX0seyJjIjpbeyJ2IjoxODQ2LjA3fSxudWxsLHsidiI6NDEuMDQyfV19 LHsiYyI6W3sidiI6NDg5MC4xMX0sbnVsbCx7InYiOjQzLjc2fV19LHsiYyI6W3sidiI6ODQzLjQz fSx7InYiOjM4LjAyNX0sbnVsbF19LHsiYyI6W3sidiI6MTQ4My40OH0seyJ2Ijo0MC4yMTV9LG51 bGxdfSx7ImMiOlt7InYiOjMwODAuODR9LHsidiI6NDIuMjg5fSxudWxsXX0seyJjIjpbeyJ2Ijo2 OTc3LjYyfSx7InYiOjQ0LjI4OX0sbnVsbF19XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIsImlk IjoiZGF0YXJhdGUiLCJsYWJlbCI6IkRhdGFyYXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJz dGF0cy92cDgiLCJsYWJlbCI6InN0YXRzL3ZwOCJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3Rh dHMveDI2NF9iYXNlbGluZSIsImxhYmVsIjoic3RhdHMveDI2NF9iYXNlbGluZSJ9XX0nLCd7InJv d3MiOlt7ImMiOlt7InYiOjQzLjY4fSxudWxsLHsidiI6MzguNTM5fV19LHsiYyI6W3sidiI6NzIu MDN9LG51bGwseyJ2Ijo0MS40MDV9XX0seyJjIjpbeyJ2IjoxNDcuNDV9LG51bGwseyJ2Ijo0NC4y OTZ9XX0seyJjIjpbeyJ2Ijo0MjguNjd9LG51bGwseyJ2Ijo0Ni42OTJ9XX0seyJjIjpbeyJ2Ijo2 OS41NX0seyJ2Ijo0MS4xMTd9LG51bGxdfSx7ImMiOlt7InYiOjExMS42N30seyJ2Ijo0My4wODZ9 LG51bGxdfSx7ImMiOlt7InYiOjIyMS4wfSx7InYiOjQ1LjAxN30sbnVsbF19LHsiYyI6W3sidiI6 NTY3LjQ1fSx7InYiOjQ2LjkwN30sbnVsbF19XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIsImlk IjoiZGF0YXJhdGUiLCJsYWJlbCI6IkRhdGFyYXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJz dGF0cy92cDgiLCJsYWJlbCI6InN0YXRzL3ZwOCJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3Rh dHMveDI2NF9iYXNlbGluZSIsImxhYmVsIjoic3RhdHMveDI2NF9iYXNlbGluZSJ9XX0nLCd7InJv d3MiOlt7ImMiOlt7InYiOjE1Ni4yNH0sbnVsbCx7InYiOjM1LjU1M31dfSx7ImMiOlt7InYiOjI4 NS4xMn0sbnVsbCx7InYiOjM4LjE1NX1dfSx7ImMiOlt7InYiOjY2MS40NH0sbnVsbCx7InYiOjQw LjU2NX1dfSx7ImMiOlt7InYiOjE5NTEuMzR9LG51bGwseyJ2Ijo0Mi45OH1dfSx7ImMiOlt7InYi OjI0NC40OH0seyJ2IjozOC4xMTV9LG51bGxdfSx7ImMiOlt7InYiOjQzMi43OX0seyJ2IjozOS44 NTN9LG51bGxdfSx7ImMiOlt7InYiOjk3Mi4xM30seyJ2Ijo0MS41MDJ9LG51bGxdfSx7ImMiOlt7 InYiOjI2ODQuNn0seyJ2Ijo0My41OH0sbnVsbF19XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIs ImlkIjoiZGF0YXJhdGUiLCJsYWJlbCI6IkRhdGFyYXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQi OiJzdGF0cy92cDgiLCJsYWJlbCI6InN0YXRzL3ZwOCJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoi c3RhdHMveDI2NF9iYXNlbGluZSIsImxhYmVsIjoic3RhdHMveDI2NF9iYXNlbGluZSJ9XX0nLCd7 InJvd3MiOlt7ImMiOlt7InYiOjcwLjA1fSxudWxsLHsidiI6MzUuMjI4fV19LHsiYyI6W3sidiI6 MTM3LjQ5fSxudWxsLHsidiI6MzcuNDY2fV19LHsiYyI6W3sidiI6NDM2LjUzfSxudWxsLHsidiI6 MzkuODU1fV19LHsiYyI6W3sidiI6MTcwNy42OX0sbnVsbCx7InYiOjQyLjQ3M31dfSx7ImMiOlt7 InYiOjEzNy4zfSx7InYiOjM3LjUyMn0sbnVsbF19LHsiYyI6W3sidiI6Mjc3LjExfSx7InYiOjM5 LjIwOH0sbnVsbF19LHsiYyI6W3sidiI6ODAxLjE4fSx7InYiOjQwLjg3N30sbnVsbF19LHsiYyI6 W3sidiI6MjU2Ni45M30seyJ2Ijo0My4xMjZ9LG51bGxdfV0sImNvbHMiOlt7InR5cGUiOiJudW1i ZXIiLCJpZCI6ImRhdGFyYXRlIiwibGFiZWwiOiJEYXRhcmF0ZSJ9LHsidHlwZSI6Im51bWJlciIs ImlkIjoic3RhdHMvdnA4IiwibGFiZWwiOiJzdGF0cy92cDgifSx7InR5cGUiOiJudW1iZXIiLCJp ZCI6InN0YXRzL3gyNjRfYmFzZWxpbmUiLCJsYWJlbCI6InN0YXRzL3gyNjRfYmFzZWxpbmUifV19 JywneyJyb3dzIjpbeyJjIjpbeyJ2Ijo1OTkuNTF9LG51bGwseyJ2IjozNS42MTh9XX0seyJjIjpb eyJ2IjoxMDc4Ljk4fSxudWxsLHsidiI6MzguNjY5fV19LHsiYyI6W3sidiI6MjI1My44fSxudWxs LHsidiI6NDEuNjE1fV19LHsiYyI6W3sidiI6NjM4Ni4wNn0sbnVsbCx7InYiOjQ0LjU0NX1dfSx7 ImMiOlt7InYiOjg4OS43NH0seyJ2IjozOC4zMTh9LG51bGxdfSx7ImMiOlt7InYiOjE0OTUuMjR9 LHsidiI6NDAuNTMzfSxudWxsXX0seyJjIjpbeyJ2IjozMDk5Ljc2fSx7InYiOjQyLjU2NX0sbnVs bF19LHsiYyI6W3sidiI6Nzg1MS41MX0seyJ2Ijo0NS4wOH0sbnVsbF19XSwiY29scyI6W3sidHlw ZSI6Im51bWJlciIsImlkIjoiZGF0YXJhdGUiLCJsYWJlbCI6IkRhdGFyYXRlIn0seyJ0eXBlIjoi bnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJsYWJlbCI6InN0YXRzL3ZwOCJ9LHsidHlwZSI6Im51 bWJlciIsImlkIjoic3RhdHMveDI2NF9iYXNlbGluZSIsImxhYmVsIjoic3RhdHMveDI2NF9iYXNl bGluZSJ9XX0nLCd7InJvd3MiOlt7ImMiOlt7InYiOjI1MS40MX0sbnVsbCx7InYiOjMzLjg0NX1d fSx7ImMiOlt7InYiOjQ2MS45OX0sbnVsbCx7InYiOjM3LjA3M31dfSx7ImMiOlt7InYiOjg4Ni40 M30sbnVsbCx7InYiOjQwLjQ1MX1dfSx7ImMiOlt7InYiOjE4MDIuODJ9LG51bGwseyJ2Ijo0My42 ODZ9XX0seyJjIjpbeyJ2IjozODcuMzJ9LHsidiI6MzYuNjY3fSxudWxsXX0seyJjIjpbeyJ2Ijo2 MjEuMjh9LHsidiI6MzkuMTM3fSxudWxsXX0seyJjIjpbeyJ2IjoxMDMyLjk2fSx7InYiOjQxLjU1 Mn0sbnVsbF19LHsiYyI6W3sidiI6MjAyMy41N30seyJ2Ijo0NC4yMDJ9LG51bGxdfV0sImNvbHMi Olt7InR5cGUiOiJudW1iZXIiLCJpZCI6ImRhdGFyYXRlIiwibGFiZWwiOiJEYXRhcmF0ZSJ9LHsi dHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvdnA4IiwibGFiZWwiOiJzdGF0cy92cDgifSx7InR5 cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3gyNjRfYmFzZWxpbmUiLCJsYWJlbCI6InN0YXRzL3gy NjRfYmFzZWxpbmUifV19JywneyJyb3dzIjpbeyJjIjpbeyJ2IjoyNy44NX0sbnVsbCx7InYiOjM3 LjEyNX1dfSx7ImMiOlt7InYiOjQ3LjI1fSxudWxsLHsidiI6MzkuOTg0fV19LHsiYyI6W3sidiI6 OTIuODl9LG51bGwseyJ2Ijo0Mi45MDh9XX0seyJjIjpbeyJ2IjoyNzkuNTF9LG51bGwseyJ2Ijo0 NS42MTZ9XX0seyJjIjpbeyJ2Ijo1My4zNn0seyJ2IjozOS40OTZ9LG51bGxdfSx7ImMiOlt7InYi Ojc5Ljc2fSx7InYiOjQxLjczfSxudWxsXX0seyJjIjpbeyJ2IjoxNTMuNDZ9LHsidiI6NDMuODQ4 fSxudWxsXX0seyJjIjpbeyJ2Ijo0MDkuMDh9LHsidiI6NDYuMDE1fSxudWxsXX1dLCJjb2xzIjpb eyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0YXJhdGUifSx7InR5 cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4In0seyJ0eXBl IjoibnVtYmVyIiwiaWQiOiJzdGF0cy94MjY0X2Jhc2VsaW5lIiwibGFiZWwiOiJzdGF0cy94MjY0 X2Jhc2VsaW5lIn1dfScsJ3sicm93cyI6W3siYyI6W3sidiI6MTAwLjk0fSxudWxsLHsidiI6MzQu OTA5fV19LHsiYyI6W3sidiI6MTgzLjY3fSxudWxsLHsidiI6MzguMDgyfV19LHsiYyI6W3sidiI6 NDU2Ljg4fSxudWxsLHsidiI6NDEuNDE3fV19LHsiYyI6W3sidiI6MTI0MS43OH0sbnVsbCx7InYi OjQ0LjYwNX1dfSx7ImMiOlt7InYiOjE3NC45fSx7InYiOjM3Ljk3Mn0sbnVsbF19LHsiYyI6W3si diI6MzIzLjk2fSx7InYiOjQwLjM4OX0sbnVsbF19LHsiYyI6W3sidiI6Njc2Ljg4fSx7InYiOjQy Ljc1NH0sbnVsbF19LHsiYyI6W3sidiI6MTU0NC44Nn0seyJ2Ijo0NS4yNTZ9LG51bGxdfV0sImNv bHMiOlt7InR5cGUiOiJudW1iZXIiLCJpZCI6ImRhdGFyYXRlIiwibGFiZWwiOiJEYXRhcmF0ZSJ9 LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvdnA4IiwibGFiZWwiOiJzdGF0cy92cDgifSx7 InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3gyNjRfYmFzZWxpbmUiLCJsYWJlbCI6InN0YXRz L3gyNjRfYmFzZWxpbmUifV19JywneyJyb3dzIjpbeyJjIjpbeyJ2IjoxMDkuMDd9LG51bGwseyJ2 IjozMS43NjZ9XX0seyJjIjpbeyJ2IjoyMDQuMDJ9LG51bGwseyJ2IjozNS42MzF9XX0seyJjIjpb eyJ2Ijo0MDkuNTV9LG51bGwseyJ2IjozOS40MjR9XX0seyJjIjpbeyJ2IjoxMjA1LjE1fSxudWxs LHsidiI6NDIuOTQ2fV19LHsiYyI6W3sidiI6MjAwLjI1fSx7InYiOjM1LjA0Nn0sbnVsbF19LHsi YyI6W3sidiI6MzEyLjAxfSx7InYiOjM3LjkxNX0sbnVsbF19LHsiYyI6W3sidiI6NjA4LjE2fSx7 InYiOjQwLjU2fSxudWxsXX0seyJjIjpbeyJ2IjoxNjIxLjEyfSx7InYiOjQzLjQ4OX0sbnVsbF19 XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIsImlkIjoiZGF0YXJhdGUiLCJsYWJlbCI6IkRhdGFy YXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJsYWJlbCI6InN0YXRzL3Zw OCJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMveDI2NF9iYXNlbGluZSIsImxhYmVsIjoi c3RhdHMveDI2NF9iYXNlbGluZSJ9XX0nLF0KDQoNCnZhciBzZWxlY3RlZCA9IDANCnZhciBpbWFn ZXN0ciA9ICcnOw0KdmFyIGJldHRlcnRhYmxlPTA7DQp2YXIgY2hhcnQ9MDsNCnZhciBiZXR0ZXI9 MDsNCnZhciBtZXRyaWNkYXRhPTA7DQp2YXIgbWV0cmljdmlldz0wOw0KdmFyIGNvbHVtbj0xOw0K dmFyIGZvcm1hdHRlcj0wOw0KDQpmdW5jdGlvbiBjaGFuZ2VDb2x1bW4oY29sKSB7DQogIGNvbHVt biA9IGNvbDsNCiAgZHJhd19maWxlcygpOw0KfQ0KDQpmdW5jdGlvbiBjaGFuZ2VNZXRyaWMobSkg ew0KICBmdGFibGU9bQ0KICBkcmF3X2ZpbGVzKCkNCn0NCg0KZnVuY3Rpb24gc2V0dXBfdmlzKCkg ew0KICBjaGFydCA9IG5ldyBnb29nbGUudmlzdWFsaXphdGlvbi5TY2F0dGVyQ2hhcnQoDQogICAg ICBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgibWV0cmljZ3JhcGgiKSk7DQoNCiAgYmV0dGVydGFi bGUgPSBuZXcgZ29vZ2xlLnZpc3VhbGl6YXRpb24uVGFibGUoDQogICAgICBkb2N1bWVudC5nZXRF bGVtZW50QnlJZCgiYmV0dGVydGFibGUiKSk7DQoNCiAgZHJhd19maWxlcygpOw0KfQ0KDQpmdW5j dGlvbiBkcmF3X2ZpbGVzKCkgew0KICB2YXIgY3NzQ2xhc3NOYW1lcyA9IHsNCiAgICAgICdoZWFk ZXJSb3cnOiAnYmx1ZS1mb250IHNtYWxsLWZvbnQgYm9sZC1mb250IHNtYWxsLW1hcmdpbicsDQog ICAgICAndGFibGVSb3cnOiAnc21hbGwtZm9udCBzbWFsbC1tYXJnaW4nLA0KICAgICAgJ29kZFRh YmxlUm93JzogJ2xpZ2h0LWdyYXktYmFja2dyb3VuZCBzbWFsbC1mb250IHNtYWxsLW1hcmdpbics DQogICAgICAnc2VsZWN0ZWRUYWJsZVJvdyc6ICdvcmFuZ2UtYmFja2dyb3VuZCBzbWFsbC1mb250 JywNCiAgICAgICdob3ZlclRhYmxlUm93JzogJ3NtYWxsLWZvbnQgaGVhZGVyLXN0eWxlJywNCiAg ICAgICdoZWFkZXJDZWxsJzogJ2hlYWRlci1zdHlsZSBzbWFsbC1tYXJnaW4nLA0KICAgICAgJ3Rh YmxlQ2VsbCc6ICdzbWFsbC1tYXJnaW4nfTsNCg0KICB2YXIgb3B0aW9ucyA9IHsnYWxsb3dIdG1s JzogdHJ1ZX07DQogIGlmIChiZXR0ZXIgIT0gMCkgZGVsZXRlIGJldHRlcjsNCg0KICBjb2w9ZXZh bChmdGFibGUrJ1tjb2x1bW5dJykNCiAgYmV0dGVyID0gbmV3IGdvb2dsZS52aXN1YWxpemF0aW9u LkRhdGFUYWJsZShjb2wpDQoNCiAgLy8gUHl0aG9uIFRlbXBsYXRlIGNvZGUgcmVwbGFjZXMgdGhl IGZvbGxvd2luZyBsaW5lIHdpdGggYSBsaXN0IG9mDQogIC8vIGZvcm1hdHRlcnMuDQogIGlmIChm dGFibGUgPT0gJ2ZpbGVzdGFibGVfZHNucicpDQogICAgZm9ybWF0dGVyID0gbmV3IGdvb2dsZS52 aXN1YWxpemF0aW9uLk51bWJlckZvcm1hdCgNCiAgICAgIHtmcmFjdGlvbkRpZ2l0czogNCwgc3Vm Zml4OiIgZGIifSk7DQogIGVsc2UNCiAgICBmb3JtYXR0ZXIgPSBuZXcgZ29vZ2xlLnZpc3VhbGl6 YXRpb24uTnVtYmVyRm9ybWF0KA0KICAgICAgIHtmcmFjdGlvbkRpZ2l0czogNCwgc3VmZml4OiIl In0pOw0KDQogICAgIGZvcm1hdHRlci5mb3JtYXQoYmV0dGVyLCAxKTsNCg0KICBiZXR0ZXJ0YWJs ZS5kcmF3KGJldHRlcixvcHRpb25zKTsNCiAgZ29vZ2xlLnZpc3VhbGl6YXRpb24uZXZlbnRzLmFk ZExpc3RlbmVyKGJldHRlcnRhYmxlLCAnc2VsZWN0JywNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHNlbGVjdEJldHRlckhhbmRsZXIpOw0KICBxdWVyeV9maWxlKCkN Cn0NCg0KZnVuY3Rpb24gcXVlcnlfZmlsZSgpIHsNCiAgaW1hZ2VzdHIgPSBiZXR0ZXIuZ2V0Rm9y bWF0dGVkVmFsdWUoc2VsZWN0ZWQsIDApDQogIHZhciBtZXRyaWNqc29uID0gZXZhbCgnKCcgKyBz bnJzW2NvbHVtbl1bc2VsZWN0ZWRdICsgJyknKTsNCiAgbWV0cmljZGF0YSA9IG5ldyBnb29nbGUu dmlzdWFsaXphdGlvbi5EYXRhVGFibGUobWV0cmljanNvbiwgMC42KTsNCiAgaWYoIG1ldHJpY3Zp ZXcgIT0gMCApIGRlbGV0ZSBtZXRyaWN2aWV3Ow0KICBtZXRyaWN2aWV3ID0gbmV3IGdvb2dsZS52 aXN1YWxpemF0aW9uLkRhdGFWaWV3KG1ldHJpY2RhdGEpOw0KDQogIGNoYXJ0LmRyYXcobWV0cmlj dmlldywge2N1cnZlVHlwZTonZnVuY3Rpb24nLA0KICAgICAgY2hhcnRBcmVhOntsZWZ0OmNoYXJ0 X2xlZnQsIHRvcDpjaGFydF90b3AsIHdpZHRoOmNoYXJ0X3dpZHRoLA0KICAgICAgaGVpZ2h0OmNo YXJ0X2hlaWdodC05MH0sDQogICAgICBoQXhpczp7dGl0bGU6ImRhdGFyYXRlIGluIGticHMifSwg dkF4aXM6e3RpdGxlOiJxdWFsaXR5IGluIGRlY2liZWxzIn0sDQogICAgICBsZWdlbmQ6e3Bvc2l0 aW9uOiJpbiJ9LCB0aXRsZTppbWFnZXN0ciwgcG9pbnRTaXplOjIsIGxpbmVXaWR0aDoxLA0KICAg ICAgd2lkdGg6Y2hhcnRfd2lkdGgsIGhlaWdodDpjaGFydF9oZWlnaHQtNTAgfSk7DQoNCiAgZ29v Z2xlLnZpc3VhbGl6YXRpb24uZXZlbnRzLmFkZExpc3RlbmVyKGNoYXJ0LCAnc2VsZWN0JywgY2hh cnRTZWxlY3QpOw0KICBnb29nbGUudmlzdWFsaXphdGlvbi5ldmVudHMuYWRkTGlzdGVuZXIoY2hh cnQsICdvbm1vdXNlb3ZlcicsIGNoYXJ0TW91c2VPdmVyKTsNCiAgZ29vZ2xlLnZpc3VhbGl6YXRp b24uZXZlbnRzLmFkZExpc3RlbmVyKGNoYXJ0LCAnb25tb3VzZW91dCcsIGNoYXJ0TW91c2VPdXQp Ow0KfQ0KDQpmdW5jdGlvbiBjaGFydE1vdXNlT3V0KGUpIHsNCiAgc3RhdHVzYmFyID0gZG9jdW1l bnQuZ2V0RWxlbWVudEJ5SWQoJ3N0YXR1cycpOw0KICBzdGF0dXNiYXIuc3R5bGUuZGlzcGxheSA9 ICdub25lJzsNCn0NCg0KZnVuY3Rpb24gY2hhcnRNb3VzZU92ZXIoZSkgew0KICBwb2ludERpZmZl cmVuY2UoZS5yb3csIGUuY29sdW1uKQ0KfQ0KDQpmdW5jdGlvbiBwb2ludERpZmZlcmVuY2Uocm93 LCBjb2wpIHsNCiAgaWYoIXJvdyB8fCAhY29sKQ0KICAgIHJldHVybjsNCg0KICB2YXIgY29scyA9 IG1ldHJpY2RhdGEuZ2V0TnVtYmVyT2ZDb2x1bW5zKCk7DQogIHZhciByb3dzID0gbWV0cmljZGF0 YS5nZXROdW1iZXJPZlJvd3MoKTsNCg0KICB2YXIgc2VsX2JpdHJhdGUgPSBtZXRyaWN2aWV3Lmdl dFZhbHVlKHJvdywgMCApOw0KICB2YXIgc2VsX21ldHJpYyA9IG1ldHJpY3ZpZXcuZ2V0VmFsdWUo cm93LCBjb2wpOw0KDQogIHZhciBtZXNzYWdlID0gIkF0ICIgKyBzZWxfbWV0cmljLnRvRml4ZWQo MikgKyAiIGRlY2liZWxzLCA8ZW0+Ig0KICBtZXNzYWdlID0gbWVzc2FnZSArIG1ldHJpY2RhdGEu Z2V0Q29sdW1uTGFiZWwoY29sKSArICI8L2VtPiBpcyA8dWw+Ig0KDQogIC8vIGNvbCAwIGlzIGRh dGFyYXRlDQogIGZvciggdmFyIGk9MTtpPGNvbHM7KytpKSB7DQoNCiAgICB2YXIgbWV0cmljX2dy ZWF0ZXN0X3RoYXRzX2xlc3MgPSAwOw0KICAgIHZhciByYXRlX2dyZWF0ZXN0X3RoYXRzX2xlc3Mg PSAwOw0KICAgIHZhciBtZXRyaWNfc21hbGxlc3RfdGhhdHNfZ3JlYXRlciA9IDk5OTsNCiAgICB2 YXIgcmF0ZV9zbWFsbGVzdF90aGF0c19ncmVhdGVyID0gMDsNCg0KICAgIGlmKGk9PWNvbCkNCiAg ICAgIGNvbnRpbnVlOw0KDQogICAgLy8gRmluZCB0aGUgbG93ZXN0IG1ldHJpYyBmb3IgdGhlIGNv bHVtbiB0aGF0J3MgZ3JlYXRlciB0aGFuIHNlbF9tZXRyaWMgYW5kDQogICAgLy8gdGhlIGhpZ2hl c3QgbWV0cmljIGZvciB0aGlzIGNvbHVtbiB0aGF0J3MgbGVzcyB0aGFuIHRoZSBtZXRyaWMuDQog ICAgZm9yKHZhciBsaW5lX2NvdW50ID0gMDsgbGluZV9jb3VudCA8IHJvd3M7ICsrbGluZV9jb3Vu dCkgew0KICAgICAgdGhpc19tZXRyaWMgPSBtZXRyaWNkYXRhLmdldFZhbHVlKGxpbmVfY291bnQs IGkpDQogICAgICB0aGlzX3JhdGUgPSBtZXRyaWNkYXRhLmdldFZhbHVlKGxpbmVfY291bnQsIDAp DQogICAgICBpZighdGhpc19tZXRyaWMpDQogICAgICAgIGNvbnRpbnVlOw0KDQogICAgICBpZih0 aGlzX21ldHJpYyA+IG1ldHJpY19ncmVhdGVzdF90aGF0c19sZXNzICYmDQogICAgICAgICB0aGlz X21ldHJpYyA8IHNlbF9tZXRyaWMpIHsNCiAgICAgICAgbWV0cmljX2dyZWF0ZXN0X3RoYXRzX2xl c3MgPSB0aGlzX21ldHJpYzsNCiAgICAgICAgcmF0ZV9ncmVhdGVzdF90aGF0c19sZXNzID0gdGhp c19yYXRlOw0KICAgICAgfQ0KICAgICAgaWYodGhpc19tZXRyaWMgPCBtZXRyaWNfc21hbGxlc3Rf dGhhdHNfZ3JlYXRlciAmJg0KICAgICAgICB0aGlzX21ldHJpYyA+IHNlbF9tZXRyaWMpIHsNCiAg ICAgICAgbWV0cmljX3NtYWxsZXN0X3RoYXRzX2dyZWF0ZXIgPSB0aGlzX21ldHJpYzsNCiAgICAg ICAgcmF0ZV9zbWFsbGVzdF90aGF0c19ncmVhdGVyID0gdGhpc19yYXRlOw0KICAgICAgfQ0KICAg IH0NCg0KICAgIGlmKHJhdGVfc21hbGxlc3RfdGhhdHNfZ3JlYXRlciA9PSAwIHx8IHJhdGVfZ3Jl YXRlc3RfdGhhdHNfbGVzcyA9PSAwKSB7DQogICAgICBtZXNzYWdlID0gbWVzc2FnZSArICIgPGxp PiBDb3VsZG4ndCBmaW5kIGEgcG9pbnQgb24gYm90aCBzaWRlcy48L2xpPiINCiAgICB9IGVsc2Ug ew0KICAgICAgbWV0cmljX3Nsb3BlID0gKCByYXRlX3NtYWxsZXN0X3RoYXRzX2dyZWF0ZXIgLSBy YXRlX2dyZWF0ZXN0X3RoYXRzX2xlc3MpIC8NCiAgICAgICAgICAoIG1ldHJpY19zbWFsbGVzdF90 aGF0c19ncmVhdGVyIC0gbWV0cmljX2dyZWF0ZXN0X3RoYXRzX2xlc3MpOw0KDQogICAgICBwcm9q ZWN0ZWRfcmF0ZSA9ICggc2VsX21ldHJpYyAtIG1ldHJpY19ncmVhdGVzdF90aGF0c19sZXNzKSAq DQogICAgICAgICAgbWV0cmljX3Nsb3BlICsgcmF0ZV9ncmVhdGVzdF90aGF0c19sZXNzOw0KDQog ICAgICBkaWZmZXJlbmNlID0gMTAwICogKHByb2plY3RlZF9yYXRlIC8gc2VsX2JpdHJhdGUgLSAx KTsNCg0KDQogICAgICBpZiAoZGlmZmVyZW5jZSA+IDApDQogICAgICAgIG1lc3NhZ2UgPSBtZXNz YWdlICsgIjxsaT4gICIgKyBkaWZmZXJlbmNlLnRvRml4ZWQoMikgKw0KICAgICAgICAgICAgICAg ICAgIiUgc21hbGxlciB0aGFuIDxlbT4iICsNCiAgICAgICAgICAgICAgICAgIG1ldHJpY2RhdGEu Z2V0Q29sdW1uTGFiZWwoaSkgKyAiPC9lbT48L2xpPiAiDQogICAgICBlbHNlDQogICAgICAgIG1l c3NhZ2UgPSBtZXNzYWdlICsgIjxsaT4gICIgKyAtZGlmZmVyZW5jZS50b0ZpeGVkKDIpICsNCiAg ICAgICAgICAgICAgICAgICIlIGJpZ2dlciB0aGFuIDxlbT4iICsNCiAgICAgICAgICAgICAgICAg IG1ldHJpY2RhdGEuZ2V0Q29sdW1uTGFiZWwoaSkgKyAiPC9lbT48L2xpPiAiDQogICAgfQ0KDQog IH0NCiAgbWVzc2FnZSA9IG1lc3NhZ2UgKyAiPC91bD4iDQogIHN0YXR1c2JhciA9IGRvY3VtZW50 LmdldEVsZW1lbnRCeUlkKCdzdGF0dXMnKTsNCiAgc3RhdHVzYmFyLmlubmVySFRNTCA9ICI8cD4i ICsgbWVzc2FnZSArICI8L3A+IjsNCiAgc3RhdHVzYmFyLnN0eWxlLmRpc3BsYXkgPSAnYmxvY2sn Ow0KfQ0KDQpmdW5jdGlvbiBjaGFydFNlbGVjdCgpIHsNCiAgdmFyIHNlbGVjdGlvbiA9IGNoYXJ0 LmdldFNlbGVjdGlvbigpOw0KICB2YXIgbWVzc2FnZSA9ICcnOw0KICB2YXIgbWluID0gbWV0cmlj dmlldy5nZXRGb3JtYXR0ZWRWYWx1ZShzZWxlY3Rpb25bMF0ucm93LCAwKTsNCiAgdmFyIG1heCA9 IG1ldHJpY3ZpZXcuZ2V0Rm9ybWF0dGVkVmFsdWUoc2VsZWN0aW9uW3NlbGVjdGlvbi5sZW5ndGgt MV0ucm93LCAwKTsNCiAgdmFyIHZhbCA9IG1ldHJpY3ZpZXcuZ2V0Rm9ybWF0dGVkVmFsdWUoc2Vs ZWN0aW9uWzBdLnJvdyxzZWxlY3Rpb25bMF0uY29sdW1uKTsNCg0KICBwb2ludERpZmZlcmVuY2Uo c2VsZWN0aW9uWzBdLnJvdywgc2VsZWN0aW9uWzBdLmNvbHVtbikNCiAgbWluID0gbWluIC8gMw0K ICBtYXggPSBtYXggKiAzDQogIG1ldHJpY3ZpZXcuc2V0Um93cyhtZXRyaWNkYXRhLmdldEZpbHRl cmVkUm93cygNCiAgICAgIFt7Y29sdW1uOiAwLG1pblZhbHVlOiBtaW4sIG1heFZhbHVlOm1heH1d KSk7DQoNCiAgY2hhcnQuZHJhdyhtZXRyaWN2aWV3LCB7Y3VydmVUeXBlOidmdW5jdGlvbicsDQog ICAgICBjaGFydEFyZWE6e2xlZnQ6NDAsIHRvcDoxMCwgd2lkdGg6Y2hhcnRfd2lkdGgsIGhlaWdo dDpjaGFydF9oZWlnaHQgLSAxMTB9LA0KICAgICAgaEF4aXM6e3RpdGxlOiJkYXRhcmF0ZSBpbiBr YnBzIn0sIHZBeGlzOnt0aXRsZToicXVhbGl0eSBpbiBkZWNpYmVscyJ9LA0KICAgICAgbGVnZW5k Ontwb3NpdGlvbjoiaW4ifSwgdGl0bGU6aW1hZ2VzdHIsIHBvaW50U2l6ZToyLCBsaW5lV2lkdGg6 MSwNCiAgICAgIHdpZHRoOmNoYXJ0X3dpZHRoLCBoZWlnaHQ6Y2hhcnRfaGVpZ2h0IC0gNTB9KTsN Cn0NCg0KZnVuY3Rpb24gc2VsZWN0QmV0dGVySGFuZGxlcigpIHsNCiAgdmFyIHNlbGVjdGlvbiA9 IGJldHRlcnRhYmxlLmdldFNlbGVjdGlvbigpOw0KICBmb3IgKHZhciBpID0gMDsgaSA8IHNlbGVj dGlvbi5sZW5ndGg7IGkrKykgew0KICAgIGl0ZW0gPSBzZWxlY3Rpb25baV07DQogIH0NCiAgc2Vs ZWN0ZWQgPSBpdGVtLnJvdw0KICBxdWVyeV9maWxlKCkNCn0NCg0KZ29vZ2xlLmxvYWQoJ3Zpc3Vh bGl6YXRpb24nLCAnMScsIHsncGFja2FnZXMnIDogWydjb3JlY2hhcnQnLCd0YWJsZSddfSk7DQpn b29nbGUuc2V0T25Mb2FkQ2FsbGJhY2soc2V0dXBfdmlzKTsNCjwvc2NyaXB0Pg0KPC9oZWFkPg0K DQo8Ym9keT4NCg0KICA8ZGl2IGNsYXNzPSJjb250YWluZXJfMTIiPg0KDQogICAgPGRpdiBjbGFz cz0iZ3JpZF8xMiBoZWFkZXIiPg0KICAgICAgPGgyPlZQOCBSZXN1bHRzPC9oMj4NCiAgICA8L2Rp dj4NCg0KICAgIDxkaXYgY2xhc3M9ImdyaWRfMTIgcmFkaW8iPg0KDQogICAgPGRpdiBjbGFzcz0i Z3JpZF8xMiBtYWluIj4NCg0KICAgICAgPGRpdiBjbGFzcz0iZ3JpZF81IGFscGhhIGNsaXBsaXN0 Ij4NCiAgICAgICAgPGRpdiBpZD0iYmV0dGVydGFibGUiPjwvZGl2Pg0KICAgICAgPC9kaXY+DQoN CiAgICAgIDxkaXYgY2xhc3M9ImdyaWRfNSBjaGFydGFyZWEiPg0KICAgICAgICA8ZGl2IGlkPSJt ZXRyaWNncmFwaCI+PC9kaXY+DQogICAgICA8L2Rpdj4NCg0KICAgICAgPGRpdiBjbGFzcz0iZ3Jp ZF8yIG9tZWdhIGluZGljYXRvcnMiPg0KICAgICAgICA8ZGl2IGNsYXNzPSJjb250ZW50Ij4NCiAg ICAgICAgICA8aDU+SW5kaWNhdG9yczwvaDU+DQogICAgICAgICAgPGhyPg0KICAgICAgICAgIDxk aXYgaWQ9InN0YXR1cyI+PC9kaXY+DQogICAgICAgIDwvZGl2Pg0KICAgICAgPC9kaXY+DQoNCiAg ICA8L2Rpdj4NCg0KICA8L2Rpdj4NCg0KPC9ib2R5Pg0KPC9odG1sPg0KCg== --_006_BBE9739C2C302046BD34B42713A1E2A22DECC12FESESSMB105erics_ Content-Type: text/html; name="vp8_vs_jm_constrained_high.html" Content-Description: vp8_vs_jm_constrained_high.html Content-Disposition: attachment; filename="vp8_vs_jm_constrained_high.html"; size=22247; creation-date="Sat, 22 Jun 2013 13:41:08 GMT"; modification-date="Sat, 22 Jun 2013 13:41:08 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWw+DQo8aHRtbCBsYW5nPSJlbiI+DQo8aGVhZD4NCjxtZXRhIGNoYXJzZXQ9 InV0Zi04Ij4NCjx0aXRsZT5Db21wYXJhdGl2ZSBSZXN1bHRzPC90aXRsZT4NCjxzdHlsZSB0eXBl PSJ0ZXh0L2NzcyI+DQo8IS0tIEJlZ2luIDk2MCByZXNldCAtLT4NCmEsYWJicixhY3JvbnltLGFk ZHJlc3MsYXBwbGV0LGFydGljbGUsYXNpZGUsYXVkaW8sYixiaWcsYmxvY2txdW90ZSxib2R5LGNh bnZhcyxjYXB0aW9uLGNlbnRlcixjaXRlLGMNCm9kZSxkZCxkZWwsZGV0YWlscyxkZm4sZGlhbG9n LGRpdixkbCxkdCxlbSxlbWJlZCxmaWVsZHNldCxmaWdjYXB0aW9uLGZpZ3VyZSxmb250LGZvb3Rl cixmb3JtLGgxLGgyLGgNCjMsaDQsaDUsaDYsaGVhZGVyLGhncm91cCxocixodG1sLGksaWZyYW1l LGltZyxpbnMsa2JkLGxhYmVsLGxlZ2VuZCxsaSxtYXJrLG1lbnUsbWV0ZXIsbmF2LG9iamVjdCxv bCwNCm91dHB1dCxwLHByZSxwcm9ncmVzcyxxLHJwLHJ0LHJ1YnkscyxzYW1wLHNlY3Rpb24sc21h bGwsc3BhbixzdHJpa2Usc3Ryb25nLHN1YixzdW1tYXJ5LHN1cCx0YWJsZSx0Ym8NCmR5LHRkLHRm b290LHRoLHRoZWFkLHRpbWUsdHIsdHQsdSx1bCx2YXIsdmlkZW8seG1we2JvcmRlcjowO21hcmdp bjowO3BhZGRpbmc6MDtmb250LXNpemU6MTAwJX1odG1sLGINCm9keXtoZWlnaHQ6MTAwJX1hcnRp Y2xlLGFzaWRlLGRldGFpbHMsZmlnY2FwdGlvbixmaWd1cmUsZm9vdGVyLGhlYWRlcixoZ3JvdXAs bWVudSxuYXYsc2VjdGlvbntkaXNwbGENCnk6YmxvY2t9YixzdHJvbmd7Zm9udC13ZWlnaHQ6Ym9s ZH1pbWd7Y29sb3I6dHJhbnNwYXJlbnQ7Zm9udC1zaXplOjA7dmVydGljYWwtYWxpZ246bWlkZGxl Oy1tcy1pbnRlcnANCm9sYXRpb24tbW9kZTpiaWN1YmljfW9sLHVse2xpc3Qtc3R5bGU6bm9uZX1s aXtkaXNwbGF5Omxpc3QtaXRlbX10YWJsZXtib3JkZXItY29sbGFwc2U6Y29sbGFwc2U7Ym9yZGUN CnItc3BhY2luZzowfXRoLHRkLGNhcHRpb257Zm9udC13ZWlnaHQ6bm9ybWFsO3ZlcnRpY2FsLWFs aWduOnRvcDt0ZXh0LWFsaWduOmxlZnR9cXtxdW90ZXM6bm9uZX1xOmJlZm8NCnJlLHE6YWZ0ZXJ7 Y29udGVudDonJztjb250ZW50Om5vbmV9c3ViLHN1cCxzbWFsbHtmb250LXNpemU6NzUlfXN1Yixz dXB7bGluZS1oZWlnaHQ6MDtwb3NpdGlvbjpyZWxhdGkNCnZlO3ZlcnRpY2FsLWFsaWduOmJhc2Vs aW5lfXN1Yntib3R0b206LTAuMjVlbX1zdXB7dG9wOi0wLjVlbX1zdmd7b3ZlcmZsb3c6aGlkZGVu fQ0KPCEtLSBFbmQgOTYwIHJlc2V0IC0tPg0KPCEtLSBCZWdpbiA5NjAgdGV4dCAtLT4NCmJvZHl7 Zm9udDoxM3B4LzEuNSAnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLCdMaWJlcmF0aW9uIFNhbnMnLEZy ZWVTYW5zLHNhbnMtc2VyaWZ9cHJlLGNvZGV7Zm9udC1mYW1pbHkNCjonRGVqYVZ1IFNhbnMgTW9u bycsTWVubG8sQ29uc29sYXMsbW9ub3NwYWNlfWhye2JvcmRlcjowICNjY2Mgc29saWQ7Ym9yZGVy LXRvcC13aWR0aDoxcHg7Y2xlYXI6Ym90aDsNCmhlaWdodDowfWgxe2ZvbnQtc2l6ZToyNXB4fWgy e2ZvbnQtc2l6ZToyM3B4fWgze2ZvbnQtc2l6ZToyMXB4fWg0e2ZvbnQtc2l6ZToxOXB4fWg1e2Zv bnQtc2l6ZToxN3B4fWgNCjZ7Zm9udC1zaXplOjE1cHh9b2x7bGlzdC1zdHlsZTpkZWNpbWFsfXVs e2xpc3Qtc3R5bGU6ZGlzY31saXttYXJnaW4tbGVmdDozMHB4fXAsZGwsaHIsaDEsaDIsaDMsaDQs aDUNCixoNixvbCx1bCxwcmUsdGFibGUsYWRkcmVzcyxmaWVsZHNldCxmaWd1cmV7bWFyZ2luLWJv dHRvbToyMHB4fQ0KPCEtLSBFbmQgOTYwIHRleHQgLS0+DQo8IS0tIEJlZ2luIDk2MCBncmlkIChm bHVpZCB2YXJpYW50KQ0KICAgICAxMiBjb2x1bW5zLCAxMTUycHggdG90YWwgd2lkdGgNCiAgICAg aHR0cDovLzk2MC5ncy8gfCBodHRwOi8vZ3JpZHMuaGVyb2t1LmNvbS8gLS0+DQouY29udGFpbmVy XzEye3dpZHRoOjkyJTttYXJnaW4tbGVmdDo0JTttYXJnaW4tcmlnaHQ6NCV9LmdyaWRfMSwuZ3Jp ZF8yLC5ncmlkXzMsLmdyaWRfNCwuZ3JpZF81LC5ncmlkDQpfNiwuZ3JpZF83LC5ncmlkXzgsLmdy aWRfOSwuZ3JpZF8xMCwuZ3JpZF8xMSwuZ3JpZF8xMntkaXNwbGF5OmlubGluZTtmbG9hdDpsZWZ0 O3Bvc2l0aW9uOnJlbGF0aXZlO21hDQpyZ2luLWxlZnQ6MSU7bWFyZ2luLXJpZ2h0OjElfS5hbHBo YXttYXJnaW4tbGVmdDowfS5vbWVnYXttYXJnaW4tcmlnaHQ6MH0uY29udGFpbmVyXzEyIC5ncmlk XzF7d2lkdGg6DQo2LjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF8ye3dpZHRoOjE0LjY2NyV9LmNv bnRhaW5lcl8xMiAuZ3JpZF8ze3dpZHRoOjIzLjAlfS5jb250YWluZXJfMTIgLmdyaWRfNHt3DQpp ZHRoOjMxLjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF81e3dpZHRoOjM5LjY2NyV9LmNvbnRhaW5l cl8xMiAuZ3JpZF82e3dpZHRoOjQ4LjAlfS5jb250YWluZXJfMTIgLmdyDQppZF83e3dpZHRoOjU2 LjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF84e3dpZHRoOjY0LjY2NyV9LmNvbnRhaW5lcl8xMiAu Z3JpZF85e3dpZHRoOjczLjAlfS5jb250YWluZXJfDQoxMiAuZ3JpZF8xMHt3aWR0aDo4MS4zMzMl fS5jb250YWluZXJfMTIgLmdyaWRfMTF7d2lkdGg6ODkuNjY3JX0uY29udGFpbmVyXzEyIC5ncmlk XzEye3dpZHRoOjk4LjAlfS5jDQpvbnRhaW5lcl8xMiAucHJlZml4XzF7cGFkZGluZy1sZWZ0Ojgu MzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfMntwYWRkaW5nLWxlZnQ6MTYuNjY3JX0uY29udGFp bmVyXzEyDQogLnByZWZpeF8ze3BhZGRpbmctbGVmdDoyNS4wJX0uY29udGFpbmVyXzEyIC5wcmVm aXhfNHtwYWRkaW5nLWxlZnQ6MzMuMzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfNXtwDQphZGRp bmctbGVmdDo0MS42NjclfS5jb250YWluZXJfMTIgLnByZWZpeF82e3BhZGRpbmctbGVmdDo1MC4w JX0uY29udGFpbmVyXzEyIC5wcmVmaXhfN3twYWRkaW5nLWxlZnQ6DQo1OC4zMzMlfS5jb250YWlu ZXJfMTIgLnByZWZpeF84e3BhZGRpbmctbGVmdDo2Ni42NjclfS5jb250YWluZXJfMTIgLnByZWZp eF85e3BhZGRpbmctbGVmdDo3NS4wJX0uY29uDQp0YWluZXJfMTIgLnByZWZpeF8xMHtwYWRkaW5n LWxlZnQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfMTF7cGFkZGluZy1sZWZ0OjkxLjY2 NyV9LmNvbnRhaW5lcl8xDQoyIC5zdWZmaXhfMXtwYWRkaW5nLXJpZ2h0OjguMzMzJX0uY29udGFp bmVyXzEyIC5zdWZmaXhfMntwYWRkaW5nLXJpZ2h0OjE2LjY2NyV9LmNvbnRhaW5lcl8xMiAuc3Vm Zml4DQpfM3twYWRkaW5nLXJpZ2h0OjI1LjAlfS5jb250YWluZXJfMTIgLnN1ZmZpeF80e3BhZGRp bmctcmlnaHQ6MzMuMzMzJX0uY29udGFpbmVyXzEyIC5zdWZmaXhfNXtwYWRkaW5nDQotcmlnaHQ6 NDEuNjY3JX0uY29udGFpbmVyXzEyIC5zdWZmaXhfNntwYWRkaW5nLXJpZ2h0OjUwLjAlfS5jb250 YWluZXJfMTIgLnN1ZmZpeF83e3BhZGRpbmctcmlnaHQ6NTguDQozMzMlfS5jb250YWluZXJfMTIg LnN1ZmZpeF84e3BhZGRpbmctcmlnaHQ6NjYuNjY3JX0uY29udGFpbmVyXzEyIC5zdWZmaXhfOXtw YWRkaW5nLXJpZ2h0Ojc1LjAlfS5jb250DQphaW5lcl8xMiAuc3VmZml4XzEwe3BhZGRpbmctcmln aHQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5zdWZmaXhfMTF7cGFkZGluZy1yaWdodDo5MS42Njcl fS5jb250YWluZXJfDQoxMiAucHVzaF8xe2xlZnQ6OC4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hf MntsZWZ0OjE2LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVzaF8ze2xlZnQ6MjUuMCV9LmNvbnRhaW5l DQpyXzEyIC5wdXNoXzR7bGVmdDozMy4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hfNXtsZWZ0OjQx LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVzaF82e2xlZnQ6NTAuMCV9LmNvbnRhDQppbmVyXzEyIC5w dXNoXzd7bGVmdDo1OC4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hfOHtsZWZ0OjY2LjY2NyV9LmNv bnRhaW5lcl8xMiAucHVzaF85e2xlZnQ6NzUuMCV9LmNvDQpudGFpbmVyXzEyIC5wdXNoXzEwe2xl ZnQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5wdXNoXzExe2xlZnQ6OTEuNjY3JX0uY29udGFpbmVy XzEyIC5wdWxsXzF7bGVmdDotOC4zDQozMyV9LmNvbnRhaW5lcl8xMiAucHVsbF8ye2xlZnQ6LTE2 LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVsbF8ze2xlZnQ6LTI1LjAlfS5jb250YWluZXJfMTIgLnB1 bGxfNHtsZWZ0DQo6LTMzLjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF81e2xlZnQ6LTQxLjY2NyV9 LmNvbnRhaW5lcl8xMiAucHVsbF82e2xlZnQ6LTUwLjAlfS5jb250YWluZXJfMTIgLnB1bGxfDQo3 e2xlZnQ6LTU4LjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF84e2xlZnQ6LTY2LjY2NyV9LmNvbnRh aW5lcl8xMiAucHVsbF85e2xlZnQ6LTc1LjAlfS5jb250YWluZXJfMTINCi5wdWxsXzEwe2xlZnQ6 LTgzLjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF8xMXtsZWZ0Oi05MS42NjclfS5jbGVhcntjbGVh cjpib3RoO2Rpc3BsYXk6YmxvY2s7b3ZlcmZsb3cNCjpoaWRkZW47dmlzaWJpbGl0eTpoaWRkZW47 d2lkdGg6MDtoZWlnaHQ6MH0uY2xlYXJmaXg6YWZ0ZXJ7Y2xlYXI6Ym90aDtjb250ZW50OicgJztk aXNwbGF5OmJsb2NrO2ZvbnQNCi1zaXplOjA7bGluZS1oZWlnaHQ6MDt2aXNpYmlsaXR5OmhpZGRl bjt3aWR0aDowO2hlaWdodDowfS5jbGVhcmZpeHtkaXNwbGF5OmlubGluZS1ibG9ja30qIGh0bWwg LmNsZWENCnJmaXh7aGVpZ2h0OjElfS5jbGVhcmZpeHtkaXNwbGF5OmJsb2NrfQ0KPCEtLSBFbmQg OTYwIGdyaWQgLS0+DQoNCmRpdi5tZXRyaWNncmFwaCB7DQoNCn0NCg0KYm9keSB7DQoNCn0NCg0K ZGl2LmhlYWRlciB7DQogIGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsNCn0NCg0KZGl2 LmhlYWRlciBoMiB7DQogIG1hcmdpbjogLjVlbSBhdXRvOw0KfQ0KDQpkaXYucmFkaW8gew0KICBm b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7DQogIG1hcmdpbi1ib3R0b206IDFlbTsNCn0N Cg0KZGl2Lm1haW4gew0KDQp9DQoNCmRpdi5jbGlwbGlzdCB7DQogIGZvbnQtZmFtaWx5OiBBcmlh bCwgc2Fucy1zZXJpZjsNCiAgbWFyZ2luLXRvcDogNnB4Ow0KfQ0KDQpkaXYuY2hhcnRhcmVhIHsN CiAgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOw0KfQ0KDQpkaXYuaW5kaWNhdG9ycyB7 DQogIGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsNCiAgZm9udC1zaXplOiAxM3B4Ow0K ICBtYXJnaW4tdG9wOiA2cHg7DQogIG1pbi1oZWlnaHQ6IDYwMHB4Ow0KICBiYWNrZ3JvdW5kLWNv bG9yOiAjZjdmN2Y3Ow0KfQ0KDQpkaXYuaW5kaWNhdG9ycyBkaXYuY29udGVudCB7DQogIG1hcmdp bjogMWVtOw0KfQ0KDQpkaXYuaW5kaWNhdG9ycyBkaXYuY29udGVudCBoNSB7DQogIGZvbnQtc2l6 ZTogMTNweDsNCiAgdGV4dC1hbGlnbjogY2VudGVyOw0KICBtYXJnaW46IDA7DQp9DQoNCmRpdi5p bmRpY2F0b3JzIGRpdi5jb250ZW50IHVsIHsNCiAgbWFyZ2luLWxlZnQ6IDA7DQogIHBhZGRpbmct bGVmdDogMDsNCiAgbWFyZ2luLXRvcDogMDsNCn0NCg0KZGl2LmluZGljYXRvcnMgZGl2LmNvbnRl bnQgdWwgbGkgew0KICBtYXJnaW4tbGVmdDogMS41ZW07DQp9DQoNCmRpdi5pbmRpY2F0b3JzIGRp di5jb250ZW50IHA6Zmlyc3QtY2hpbGQgew0KICBtYXJnaW4tYm90dG9tOiAuNWVtOw0KfQ0KDQpz cGFuLmdvb2dsZS12aXN1YWxpemF0aW9uLXRhYmxlLXNvcnRpbmQgew0KICBjb2xvcjogIzAwMDsN Cn0NCg0KLmhlYWRlci1zdHlsZSB7DQogIGZvbnQtd2VpZ2h0OiBib2xkOw0KICBib3JkZXI6IDFw eCBzb2xpZCAjZmZmOw0KICBiYWNrZ3JvdW5kLWNvbG9yOiAjY2NjOw0KfQ0KDQp0ZC5oZWFkZXIt c3R5bGUrdGQgew0KDQp9DQoNCi5vcmFuZ2UtYmFja2dyb3VuZCB7DQogIGJhY2tncm91bmQtY29s b3I6IG9yYW5nZTsNCn0NCg0KLmxpZ2h0LWdyYXktYmFja2dyb3VuZCB7DQogIGJhY2tncm91bmQt Y29sb3I6ICNmMGYwZjA7DQp9DQo8L3N0eWxlPg0KPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3Jp cHQiIHNyYz0iaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9qc2FwaSI+PC9zY3JpcHQ+DQo8c2NyaXB0 IHR5cGU9InRleHQvamF2YXNjcmlwdCI+DQpnb29nbGUubG9hZCgndmlzdWFsaXphdGlvbicsICcx LjEnLCB7J3BhY2thZ2VzJzpbJ3RhYmxlJ119KTsNCnZhciBjaGFydF9sZWZ0ICAgPSA2MDsNCnZh ciBjaGFydF90b3AgICAgPSA2Ow0KdmFyIGNoYXJ0X2hlaWdodCA9IGRvY3VtZW50LmRvY3VtZW50 RWxlbWVudC5jbGllbnRIZWlnaHQtMTAwOw0KdmFyIGNoYXJ0X3dpZHRoICA9ICIxMDAlIjsNCmZ0 YWJsZT0nZmlsZXN0YWJsZV9hdmcnDQp2YXIgc25ycyA9IFtdOw0KdmFyIGZpbGVzdGFibGVfZHNu ciA9IFtdOw0KdmFyIGZpbGVzdGFibGVfZHJhdGUgPSBbXTsNCnZhciBmaWxlc3RhYmxlX2F2ZyA9 IFtdOw0KDQovLyBQeXRob24gdGVtcGxhdGUgY29kZSByZXBsYWNlcyB0aGUgZm9sbG93aW5nIDIg bGluZXMuDQpmaWxlc3RhYmxlX2RzbnJbMV09eyJyb3dzIjpbeyJjIjpbeyJ2IjoiZGVza3RvcF82 NDBfMzYwXzMwIn0seyJ2IjowLjU4OTA0NDAzMzI1MjUyNzE5fV19LHsiYyI6W3sidiI6ImdpcHNy ZWNtb3Rpb25fMTI4MF83MjBfNTAifSx7InYiOjAuNTMyMTAzMzAwMTU3ODAyODN9XX0seyJjIjpb eyJ2IjoiZ2lwc3JlY3N0YXRfMTI4MF83MjBfNTAifSx7InYiOjAuODcxODI0MTM2NDQzNzk3NTN9 XX0seyJjIjpbeyJ2Ijoia2lybGFuZF82NDBfNDgwXzMwIn0seyJ2IjoxLjA5MDE4ODEwNzM4NTQz Njl9XX0seyJjIjpbeyJ2IjoibWFjbWFyY29tb3ZpbmdfNjQwXzQ4MF8zMCJ9LHsidiI6MC40NDg1 ODY4MDM3MTMxMjY0OH1dfSx7ImMiOlt7InYiOiJtYWNtYXJjb3N0YXRpb25hcnlfNjQwXzQ4MF8z MCJ9LHsidiI6MC41ODA3NzgxNDQ2MzQ2MTg1Mn1dfSx7ImMiOlt7InYiOiJuaWtsYXNfMTI4MF83 MjBfMzAifSx7InYiOjAuNDQ0ODk4NjMwNTgwNDk4NDR9XX0seyJjIjpbeyJ2IjoibmlrbGFzXzY0 MF80ODBfMzAifSx7InYiOjAuNTI4Nzg4OTAwNzYyMDY4ODZ9XX0seyJjIjpbeyJ2IjoidGFjb21h bmFycm93c182NDBfNDgwXzMwIn0seyJ2IjoxLjI3Mjk1MjU3NDI1MjI0MTh9XX0seyJjIjpbeyJ2 IjoidGFjb21hc21hbGxjYW1lcmFtb3ZlbWVudF82NDBfNDgwXzMwIn0seyJ2IjowLjQ0MDg1MDIy OTE0OTkxNDAxfV19LHsiYyI6W3sidiI6InRoYWxvdW5kZXNrbXRnXzY0MF80ODBfMzAifSx7InYi OjEuMzMzMTg3OTUzNTM4NTMyNX1dfSx7ImMiOlt7InYiOiJPVkVSQUxMIn0seyJ2IjowLjczOTM4 MjA3Mzk4ODIzMzE5fV19XSwiY29scyI6W3sidHlwZSI6InN0cmluZyIsImlkIjoiZmlsZSIsImxh YmVsIjoiRmlsZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvam1fY29uc3RyYWluZWRf aGlnaCIsImxhYmVsIjoic3RhdHMvam1fY29uc3RyYWluZWRfaGlnaCJ9XX0KDQpmaWxlc3RhYmxl X2F2Z1sxXT17InJvd3MiOlt7ImMiOlt7InYiOiJkZXNrdG9wXzY0MF8zNjBfMzAifSx7InYiOjE3 LjgzOTkzNTA3OTI3ODU1fV19LHsiYyI6W3sidiI6ImdpcHNyZWNtb3Rpb25fMTI4MF83MjBfNTAi fSx7InYiOjEzLjE1NTU3OTA5Njg3MTI4fV19LHsiYyI6W3sidiI6ImdpcHNyZWNzdGF0XzEyODBf NzIwXzUwIn0seyJ2IjoyOC44MjM4OTE1NDczMDMxM31dfSx7ImMiOlt7InYiOiJraXJsYW5kXzY0 MF80ODBfMzAifSx7InYiOjQ4LjY3MDM0ODEwMjg2NTA5fV19LHsiYyI6W3sidiI6Im1hY21hcmNv bW92aW5nXzY0MF80ODBfMzAifSx7InYiOjE1LjUyMDYxOTg2MTM0Nzc0OX1dfSx7ImMiOlt7InYi OiJtYWNtYXJjb3N0YXRpb25hcnlfNjQwXzQ4MF8zMCJ9LHsidiI6MjkuNzY4NTY5MTYxNzY5MDc2 fV19LHsiYyI6W3sidiI6Im5pa2xhc18xMjgwXzcyMF8zMCJ9LHsidiI6MTMuMDEwMjA2Nzg1OTQ3 NTMxfV19LHsiYyI6W3sidiI6Im5pa2xhc182NDBfNDgwXzMwIn0seyJ2IjoxMC42NDIwOTU2MjA0 OTMyNjl9XX0seyJjIjpbeyJ2IjoidGFjb21hbmFycm93c182NDBfNDgwXzMwIn0seyJ2Ijo0NS45 OTA2MDQzNTc3NjI5OX1dfSx7ImMiOlt7InYiOiJ0YWNvbWFzbWFsbGNhbWVyYW1vdmVtZW50XzY0 MF80ODBfMzAifSx7InYiOjEyLjE5MjY5OTI1NzY4ODA0OH1dfSx7ImMiOlt7InYiOiJ0aGFsb3Vu ZGVza210Z182NDBfNDgwXzMwIn0seyJ2IjozMS43NTc0Nzg1ODIwMDgxMjZ9XX0seyJjIjpbeyJ2 IjoiT1ZFUkFMTCJ9LHsidiI6MjQuMzA2NTQ3OTUwMzAzMTd9XX1dLCJjb2xzIjpbeyJ0eXBlIjoi c3RyaW5nIiwiaWQiOiJmaWxlIiwibGFiZWwiOiJGaWxlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQi OiJzdGF0cy9qbV9jb25zdHJhaW5lZF9oaWdoIiwibGFiZWwiOiJzdGF0cy9qbV9jb25zdHJhaW5l ZF9oaWdoIn1dfQoNCmZpbGVzdGFibGVfZHJhdGVbMV09eyJyb3dzIjpbeyJjIjpbeyJ2IjoiZGVz a3RvcF82NDBfMzYwXzMwIn0seyJ2IjoxNy43OTE4NjQ4NzEzODY5M31dfSx7ImMiOlt7InYiOiJn aXBzcmVjbW90aW9uXzEyODBfNzIwXzUwIn0seyJ2IjoxNi4wMzE2NzI3NjEwNTY1OX1dfSx7ImMi Olt7InYiOiJnaXBzcmVjc3RhdF8xMjgwXzcyMF81MCJ9LHsidiI6MzIuMDQ2MDIzMjgzMzEyODN9 XX0seyJjIjpbeyJ2Ijoia2lybGFuZF82NDBfNDgwXzMwIn0seyJ2Ijo0OS45NzQ4MDU4MzkyNTU2 NDR9XX0seyJjIjpbeyJ2IjoibWFjbWFyY29tb3ZpbmdfNjQwXzQ4MF8zMCJ9LHsidiI6MjEuMDU4 Mjc4MDY0NDI4ODgzfV19LHsiYyI6W3sidiI6Im1hY21hcmNvc3RhdGlvbmFyeV82NDBfNDgwXzMw In0seyJ2IjozOC42NTAyNTQyMTMxMTE5NjR9XX0seyJjIjpbeyJ2IjoibmlrbGFzXzEyODBfNzIw XzMwIn0seyJ2IjoxNS4wMzg4OTUwMzQyNDUwMDN9XX0seyJjIjpbeyJ2IjoibmlrbGFzXzY0MF80 ODBfMzAifSx7InYiOjEyLjMxODA4MDQ0ODAwOTk5NH1dfSx7ImMiOlt7InYiOiJ0YWNvbWFuYXJy b3dzXzY0MF80ODBfMzAifSx7InYiOjQ2LjEwMzU4MTMxNjEwNjg1NX1dfSx7ImMiOlt7InYiOiJ0 YWNvbWFzbWFsbGNhbWVyYW1vdmVtZW50XzY0MF80ODBfMzAifSx7InYiOjE0LjU0NDYzMTI3MDI4 MTcxNn1dfSx7ImMiOlt7InYiOiJ0aGFsb3VuZGVza210Z182NDBfNDgwXzMwIn0seyJ2IjozNS4z OTQzNzgzNDMzNDA5OH1dfSx7ImMiOlt7InYiOiJPVkVSQUxMIn0seyJ2IjoyNy4xNzc0OTY4NTg1 OTQzMTR9XX1dLCJjb2xzIjpbeyJ0eXBlIjoic3RyaW5nIiwiaWQiOiJmaWxlIiwibGFiZWwiOiJG aWxlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy9qbV9jb25zdHJhaW5lZF9oaWdoIiwi bGFiZWwiOiJzdGF0cy9qbV9jb25zdHJhaW5lZF9oaWdoIn1dfQoNCnNucnNbMV0gPSBbJ3sicm93 cyI6W3siYyI6W3sidiI6MjI3LjkxfSxudWxsLHsidiI6MzMuMjA1fV19LHsiYyI6W3sidiI6NTI0 LjAyfSxudWxsLHsidiI6MzYuMjQyfV19LHsiYyI6W3sidiI6MTI5Ny4xOX0sbnVsbCx7InYiOjM5 LjUxNX1dfSx7ImMiOlt7InYiOjMyNzQuMTd9LG51bGwseyJ2Ijo0Mi43MDN9XX0seyJjIjpbeyJ2 Ijo1MTIuMDR9LHsidiI6MzUuMzIzfSxudWxsXX0seyJjIjpbeyJ2Ijo5MzguNTN9LHsidiI6Mzcu Njk0fSxudWxsXX0seyJjIjpbeyJ2IjoxNzA3LjU4fSx7InYiOjM5Ljk2fSxudWxsXX0seyJjIjpb eyJ2IjozNTQ0LjczfSx7InYiOjQyLjY0MX0sbnVsbF19XSwiY29scyI6W3sidHlwZSI6Im51bWJl ciIsImlkIjoiZGF0YXJhdGUiLCJsYWJlbCI6IkRhdGFyYXRlIn0seyJ0eXBlIjoibnVtYmVyIiwi aWQiOiJzdGF0cy92cDgiLCJsYWJlbCI6InN0YXRzL3ZwOCJ9LHsidHlwZSI6Im51bWJlciIsImlk Ijoic3RhdHMvam1fY29uc3RyYWluZWRfaGlnaCIsImxhYmVsIjoic3RhdHMvam1fY29uc3RyYWlu ZWRfaGlnaCJ9XX0nLCd7InJvd3MiOlt7ImMiOlt7InYiOjc5NS4zOX0sbnVsbCx7InYiOjM1LjM0 fV19LHsiYyI6W3sidiI6MTYwMy44N30sbnVsbCx7InYiOjM4LjI1MX1dfSx7ImMiOlt7InYiOjM0 MjMuMzF9LG51bGwseyJ2Ijo0MS4yNjN9XX0seyJjIjpbeyJ2Ijo4Njc3LjE2fSxudWxsLHsidiI6 NDMuOTR9XX0seyJjIjpbeyJ2IjoxNTEyLjE1fSx7InYiOjM3LjQ1NX0sbnVsbF19LHsiYyI6W3si diI6MjU1NS41OX0seyJ2IjozOS42Nzd9LG51bGxdfSx7ImMiOlt7InYiOjQ4MTguNTV9LHsidiI6 NDEuODIzfSxudWxsXX0seyJjIjpbeyJ2IjoxMDM3MC41OH0seyJ2Ijo0My45ODJ9LG51bGxdfV0s ImNvbHMiOlt7InR5cGUiOiJudW1iZXIiLCJpZCI6ImRhdGFyYXRlIiwibGFiZWwiOiJEYXRhcmF0 ZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvdnA4IiwibGFiZWwiOiJzdGF0cy92cDgi fSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL2ptX2NvbnN0cmFpbmVkX2hpZ2giLCJsYWJl bCI6InN0YXRzL2ptX2NvbnN0cmFpbmVkX2hpZ2gifV19JywneyJyb3dzIjpbeyJjIjpbeyJ2Ijoz NTAuOH0sbnVsbCx7InYiOjM1Ljg1fV19LHsiYyI6W3sidiI6NzczLjIxfSxudWxsLHsidiI6Mzgu NjUxfV19LHsiYyI6W3sidiI6MTc1Ny44Nn0sbnVsbCx7InYiOjQxLjU5M31dfSx7ImMiOlt7InYi OjQ5MDQuNn0sbnVsbCx7InYiOjQ0LjE5fV19LHsiYyI6W3sidiI6ODQzLjQzfSx7InYiOjM4LjAy NX0sbnVsbF19LHsiYyI6W3sidiI6MTQ4My40OH0seyJ2Ijo0MC4yMTV9LG51bGxdfSx7ImMiOlt7 InYiOjMwODAuODR9LHsidiI6NDIuMjg5fSxudWxsXX0seyJjIjpbeyJ2Ijo2OTc3LjYyfSx7InYi OjQ0LjI4OX0sbnVsbF19XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIsImlkIjoiZGF0YXJhdGUi LCJsYWJlbCI6IkRhdGFyYXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJs YWJlbCI6InN0YXRzL3ZwOCJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvam1fY29uc3Ry YWluZWRfaGlnaCIsImxhYmVsIjoic3RhdHMvam1fY29uc3RyYWluZWRfaGlnaCJ9XX0nLCd7InJv d3MiOlt7ImMiOlt7InYiOjI5LjMxfSxudWxsLHsidiI6MzkuMjYxfV19LHsiYyI6W3sidiI6NTUu NH0sbnVsbCx7InYiOjQxLjk2M31dfSx7ImMiOlt7InYiOjEyNy41fSxudWxsLHsidiI6NDQuNjUz fV19LHsiYyI6W3sidiI6MzgyLjg2fSxudWxsLHsidiI6NDYuOTM0fV19LHsiYyI6W3sidiI6Njku NTV9LHsidiI6NDEuMTE3fSxudWxsXX0seyJjIjpbeyJ2IjoxMTEuNjd9LHsidiI6NDMuMDg2fSxu dWxsXX0seyJjIjpbeyJ2IjoyMjEuMH0seyJ2Ijo0NS4wMTd9LG51bGxdfSx7ImMiOlt7InYiOjU2 Ny40NX0seyJ2Ijo0Ni45MDd9LG51bGxdfV0sImNvbHMiOlt7InR5cGUiOiJudW1iZXIiLCJpZCI6 ImRhdGFyYXRlIiwibGFiZWwiOiJEYXRhcmF0ZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3Rh dHMvdnA4IiwibGFiZWwiOiJzdGF0cy92cDgifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRz L2ptX2NvbnN0cmFpbmVkX2hpZ2giLCJsYWJlbCI6InN0YXRzL2ptX2NvbnN0cmFpbmVkX2hpZ2gi fV19JywneyJyb3dzIjpbeyJjIjpbeyJ2IjoxMzIuMjl9LG51bGwseyJ2IjozNi4xODN9XX0seyJj IjpbeyJ2IjoyNTMuNzR9LG51bGwseyJ2IjozOC42NzV9XX0seyJjIjpbeyJ2Ijo1OTcuMDR9LG51 bGwseyJ2Ijo0MC45OTZ9XX0seyJjIjpbeyJ2IjoyMTA2LjY5fSxudWxsLHsidiI6NDMuNDM3fV19 LHsiYyI6W3sidiI6MjQ0LjQ4fSx7InYiOjM4LjExNX0sbnVsbF19LHsiYyI6W3sidiI6NDMyLjc5 fSx7InYiOjM5Ljg1M30sbnVsbF19LHsiYyI6W3sidiI6OTcyLjEzfSx7InYiOjQxLjUwMn0sbnVs bF19LHsiYyI6W3sidiI6MjY4NC42fSx7InYiOjQzLjU4fSxudWxsXX1dLCJjb2xzIjpbeyJ0eXBl IjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0YXJhdGUifSx7InR5cGUiOiJu dW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4In0seyJ0eXBlIjoibnVt YmVyIiwiaWQiOiJzdGF0cy9qbV9jb25zdHJhaW5lZF9oaWdoIiwibGFiZWwiOiJzdGF0cy9qbV9j b25zdHJhaW5lZF9oaWdoIn1dfScsJ3sicm93cyI6W3siYyI6W3sidiI6NjAuMTJ9LG51bGwseyJ2 IjozNS43Mzl9XX0seyJjIjpbeyJ2IjoxMjIuMjZ9LG51bGwseyJ2IjozNy45NTJ9XX0seyJjIjpb eyJ2IjozNzIuNDV9LG51bGwseyJ2Ijo0MC4yNDN9XX0seyJjIjpbeyJ2IjoxODM1Ljk0fSxudWxs LHsidiI6NDIuOTQ2fV19LHsiYyI6W3sidiI6MTM3LjN9LHsidiI6MzcuNTIyfSxudWxsXX0seyJj IjpbeyJ2IjoyNzcuMTF9LHsidiI6MzkuMjA4fSxudWxsXX0seyJjIjpbeyJ2Ijo4MDEuMTh9LHsi diI6NDAuODc3fSxudWxsXX0seyJjIjpbeyJ2IjoyNTY2LjkzfSx7InYiOjQzLjEyNn0sbnVsbF19 XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIsImlkIjoiZGF0YXJhdGUiLCJsYWJlbCI6IkRhdGFy YXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJsYWJlbCI6InN0YXRzL3Zw OCJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvam1fY29uc3RyYWluZWRfaGlnaCIsImxh YmVsIjoic3RhdHMvam1fY29uc3RyYWluZWRfaGlnaCJ9XX0nLCd7InJvd3MiOlt7ImMiOlt7InYi OjQ5MC40OH0sbnVsbCx7InYiOjM2LjE5fV19LHsiYyI6W3sidiI6OTUzLjg2fSxudWxsLHsidiI6 MzkuMjE4fV19LHsiYyI6W3sidiI6MjI5NS4yN30sbnVsbCx7InYiOjQyLjE2M31dfSx7ImMiOlt7 InYiOjc1ODYuOTV9LG51bGwseyJ2Ijo0NS40Njh9XX0seyJjIjpbeyJ2Ijo4ODkuNzR9LHsidiI6 MzguMzE4fSxudWxsXX0seyJjIjpbeyJ2IjoxNDk1LjI0fSx7InYiOjQwLjUzM30sbnVsbF19LHsi YyI6W3sidiI6MzA5OS43Nn0seyJ2Ijo0Mi41NjV9LG51bGxdfSx7ImMiOlt7InYiOjc4NTEuNTF9 LHsidiI6NDUuMDh9LG51bGxdfV0sImNvbHMiOlt7InR5cGUiOiJudW1iZXIiLCJpZCI6ImRhdGFy YXRlIiwibGFiZWwiOiJEYXRhcmF0ZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvdnA4 IiwibGFiZWwiOiJzdGF0cy92cDgifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL2ptX2Nv bnN0cmFpbmVkX2hpZ2giLCJsYWJlbCI6InN0YXRzL2ptX2NvbnN0cmFpbmVkX2hpZ2gifV19Jywn eyJyb3dzIjpbeyJjIjpbeyJ2IjoyMTcuNjl9LG51bGwseyJ2IjozNC41MTR9XX0seyJjIjpbeyJ2 Ijo0MTguNjJ9LG51bGwseyJ2IjozNy43MjR9XX0seyJjIjpbeyJ2Ijo4MjcuODJ9LG51bGwseyJ2 Ijo0MS4wNjN9XX0seyJjIjpbeyJ2IjoxNzk5LjY2fSxudWxsLHsidiI6NDQuMTk4fV19LHsiYyI6 W3sidiI6Mzg3LjMyfSx7InYiOjM2LjY2N30sbnVsbF19LHsiYyI6W3sidiI6NjIxLjI4fSx7InYi OjM5LjEzN30sbnVsbF19LHsiYyI6W3sidiI6MTAzMi45Nn0seyJ2Ijo0MS41NTJ9LG51bGxdfSx7 ImMiOlt7InYiOjIwMjMuNTd9LHsidiI6NDQuMjAyfSxudWxsXX1dLCJjb2xzIjpbeyJ0eXBlIjoi bnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0YXJhdGUifSx7InR5cGUiOiJudW1i ZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4In0seyJ0eXBlIjoibnVtYmVy IiwiaWQiOiJzdGF0cy9qbV9jb25zdHJhaW5lZF9oaWdoIiwibGFiZWwiOiJzdGF0cy9qbV9jb25z dHJhaW5lZF9oaWdoIn1dfScsJ3sicm93cyI6W3siYyI6W3sidiI6MjMuM30sbnVsbCx7InYiOjM3 LjU0NH1dfSx7ImMiOlt7InYiOjQyLjA4fSxudWxsLHsidiI6NDAuMzI2fV19LHsiYyI6W3sidiI6 ODIuNzZ9LG51bGwseyJ2Ijo0My4xMjh9XX0seyJjIjpbeyJ2IjoyMjQuNDV9LG51bGwseyJ2Ijo0 NS43ODN9XX0seyJjIjpbeyJ2Ijo1My4zNn0seyJ2IjozOS40OTZ9LG51bGxdfSx7ImMiOlt7InYi Ojc5Ljc2fSx7InYiOjQxLjczfSxudWxsXX0seyJjIjpbeyJ2IjoxNTMuNDZ9LHsidiI6NDMuODQ4 fSxudWxsXX0seyJjIjpbeyJ2Ijo0MDkuMDh9LHsidiI6NDYuMDE1fSxudWxsXX1dLCJjb2xzIjpb eyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0YXJhdGUifSx7InR5 cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4In0seyJ0eXBl IjoibnVtYmVyIiwiaWQiOiJzdGF0cy9qbV9jb25zdHJhaW5lZF9oaWdoIiwibGFiZWwiOiJzdGF0 cy9qbV9jb25zdHJhaW5lZF9oaWdoIn1dfScsJ3sicm93cyI6W3siYyI6W3sidiI6ODYuMH0sbnVs bCx7InYiOjM1LjU2OX1dfSx7ImMiOlt7InYiOjE3Mi4xMX0sbnVsbCx7InYiOjM4LjYxfV19LHsi YyI6W3sidiI6NDYzLjAyfSxudWxsLHsidiI6NDEuOTc2fV19LHsiYyI6W3sidiI6MTMyNC4wNX0s bnVsbCx7InYiOjQ1LjE1OH1dfSx7ImMiOlt7InYiOjE3NC45fSx7InYiOjM3Ljk3Mn0sbnVsbF19 LHsiYyI6W3sidiI6MzIzLjk2fSx7InYiOjQwLjM4OX0sbnVsbF19LHsiYyI6W3sidiI6Njc2Ljg4 fSx7InYiOjQyLjc1NH0sbnVsbF19LHsiYyI6W3sidiI6MTU0NC44Nn0seyJ2Ijo0NS4yNTZ9LG51 bGxdfV0sImNvbHMiOlt7InR5cGUiOiJudW1iZXIiLCJpZCI6ImRhdGFyYXRlIiwibGFiZWwiOiJE YXRhcmF0ZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvdnA4IiwibGFiZWwiOiJzdGF0 cy92cDgifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL2ptX2NvbnN0cmFpbmVkX2hpZ2gi LCJsYWJlbCI6InN0YXRzL2ptX2NvbnN0cmFpbmVkX2hpZ2gifV19JywneyJyb3dzIjpbeyJjIjpb eyJ2Ijo5Ny4zMX0sbnVsbCx7InYiOjMyLjkzOH1dfSx7ImMiOlt7InYiOjE4MS41Nn0sbnVsbCx7 InYiOjM2LjM0M31dfSx7ImMiOlt7InYiOjM2Ny40M30sbnVsbCx7InYiOjM5LjkzfV19LHsiYyI6 W3sidiI6MTE3Ny45OH0sbnVsbCx7InYiOjQzLjQwOH1dfSx7ImMiOlt7InYiOjIwMC4yNX0seyJ2 IjozNS4wNDZ9LG51bGxdfSx7ImMiOlt7InYiOjMxMi4wMX0seyJ2IjozNy45MTV9LG51bGxdfSx7 ImMiOlt7InYiOjYwOC4xNn0seyJ2Ijo0MC41Nn0sbnVsbF19LHsiYyI6W3sidiI6MTYyMS4xMn0s eyJ2Ijo0My40ODl9LG51bGxdfV0sImNvbHMiOlt7InR5cGUiOiJudW1iZXIiLCJpZCI6ImRhdGFy YXRlIiwibGFiZWwiOiJEYXRhcmF0ZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvdnA4 IiwibGFiZWwiOiJzdGF0cy92cDgifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL2ptX2Nv bnN0cmFpbmVkX2hpZ2giLCJsYWJlbCI6InN0YXRzL2ptX2NvbnN0cmFpbmVkX2hpZ2gifV19Jyxd Cg0KDQp2YXIgc2VsZWN0ZWQgPSAwDQp2YXIgaW1hZ2VzdHIgPSAnJzsNCnZhciBiZXR0ZXJ0YWJs ZT0wOw0KdmFyIGNoYXJ0PTA7DQp2YXIgYmV0dGVyPTA7DQp2YXIgbWV0cmljZGF0YT0wOw0KdmFy IG1ldHJpY3ZpZXc9MDsNCnZhciBjb2x1bW49MTsNCnZhciBmb3JtYXR0ZXI9MDsNCg0KZnVuY3Rp b24gY2hhbmdlQ29sdW1uKGNvbCkgew0KICBjb2x1bW4gPSBjb2w7DQogIGRyYXdfZmlsZXMoKTsN Cn0NCg0KZnVuY3Rpb24gY2hhbmdlTWV0cmljKG0pIHsNCiAgZnRhYmxlPW0NCiAgZHJhd19maWxl cygpDQp9DQoNCmZ1bmN0aW9uIHNldHVwX3ZpcygpIHsNCiAgY2hhcnQgPSBuZXcgZ29vZ2xlLnZp c3VhbGl6YXRpb24uU2NhdHRlckNoYXJ0KA0KICAgICAgZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQo Im1ldHJpY2dyYXBoIikpOw0KDQogIGJldHRlcnRhYmxlID0gbmV3IGdvb2dsZS52aXN1YWxpemF0 aW9uLlRhYmxlKA0KICAgICAgZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoImJldHRlcnRhYmxlIikp Ow0KDQogIGRyYXdfZmlsZXMoKTsNCn0NCg0KZnVuY3Rpb24gZHJhd19maWxlcygpIHsNCiAgdmFy IGNzc0NsYXNzTmFtZXMgPSB7DQogICAgICAnaGVhZGVyUm93JzogJ2JsdWUtZm9udCBzbWFsbC1m b250IGJvbGQtZm9udCBzbWFsbC1tYXJnaW4nLA0KICAgICAgJ3RhYmxlUm93JzogJ3NtYWxsLWZv bnQgc21hbGwtbWFyZ2luJywNCiAgICAgICdvZGRUYWJsZVJvdyc6ICdsaWdodC1ncmF5LWJhY2tn cm91bmQgc21hbGwtZm9udCBzbWFsbC1tYXJnaW4nLA0KICAgICAgJ3NlbGVjdGVkVGFibGVSb3cn OiAnb3JhbmdlLWJhY2tncm91bmQgc21hbGwtZm9udCcsDQogICAgICAnaG92ZXJUYWJsZVJvdyc6 ICdzbWFsbC1mb250IGhlYWRlci1zdHlsZScsDQogICAgICAnaGVhZGVyQ2VsbCc6ICdoZWFkZXIt c3R5bGUgc21hbGwtbWFyZ2luJywNCiAgICAgICd0YWJsZUNlbGwnOiAnc21hbGwtbWFyZ2luJ307 DQoNCiAgdmFyIG9wdGlvbnMgPSB7J2FsbG93SHRtbCc6IHRydWV9Ow0KICBpZiAoYmV0dGVyICE9 IDApIGRlbGV0ZSBiZXR0ZXI7DQoNCiAgY29sPWV2YWwoZnRhYmxlKydbY29sdW1uXScpDQogIGJl dHRlciA9IG5ldyBnb29nbGUudmlzdWFsaXphdGlvbi5EYXRhVGFibGUoY29sKQ0KDQogIC8vIFB5 dGhvbiBUZW1wbGF0ZSBjb2RlIHJlcGxhY2VzIHRoZSBmb2xsb3dpbmcgbGluZSB3aXRoIGEgbGlz dCBvZg0KICAvLyBmb3JtYXR0ZXJzLg0KICBpZiAoZnRhYmxlID09ICdmaWxlc3RhYmxlX2RzbnIn KQ0KICAgIGZvcm1hdHRlciA9IG5ldyBnb29nbGUudmlzdWFsaXphdGlvbi5OdW1iZXJGb3JtYXQo DQogICAgICB7ZnJhY3Rpb25EaWdpdHM6IDQsIHN1ZmZpeDoiIGRiIn0pOw0KICBlbHNlDQogICAg Zm9ybWF0dGVyID0gbmV3IGdvb2dsZS52aXN1YWxpemF0aW9uLk51bWJlckZvcm1hdCgNCiAgICAg ICB7ZnJhY3Rpb25EaWdpdHM6IDQsIHN1ZmZpeDoiJSJ9KTsNCg0KICAgICBmb3JtYXR0ZXIuZm9y bWF0KGJldHRlciwgMSk7DQoNCiAgYmV0dGVydGFibGUuZHJhdyhiZXR0ZXIsb3B0aW9ucyk7DQog IGdvb2dsZS52aXN1YWxpemF0aW9uLmV2ZW50cy5hZGRMaXN0ZW5lcihiZXR0ZXJ0YWJsZSwgJ3Nl bGVjdCcsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzZWxlY3RC ZXR0ZXJIYW5kbGVyKTsNCiAgcXVlcnlfZmlsZSgpDQp9DQoNCmZ1bmN0aW9uIHF1ZXJ5X2ZpbGUo KSB7DQogIGltYWdlc3RyID0gYmV0dGVyLmdldEZvcm1hdHRlZFZhbHVlKHNlbGVjdGVkLCAwKQ0K ICB2YXIgbWV0cmljanNvbiA9IGV2YWwoJygnICsgc25yc1tjb2x1bW5dW3NlbGVjdGVkXSArICcp Jyk7DQogIG1ldHJpY2RhdGEgPSBuZXcgZ29vZ2xlLnZpc3VhbGl6YXRpb24uRGF0YVRhYmxlKG1l dHJpY2pzb24sIDAuNik7DQogIGlmKCBtZXRyaWN2aWV3ICE9IDAgKSBkZWxldGUgbWV0cmljdmll dzsNCiAgbWV0cmljdmlldyA9IG5ldyBnb29nbGUudmlzdWFsaXphdGlvbi5EYXRhVmlldyhtZXRy aWNkYXRhKTsNCg0KICBjaGFydC5kcmF3KG1ldHJpY3ZpZXcsIHtjdXJ2ZVR5cGU6J2Z1bmN0aW9u JywNCiAgICAgIGNoYXJ0QXJlYTp7bGVmdDpjaGFydF9sZWZ0LCB0b3A6Y2hhcnRfdG9wLCB3aWR0 aDpjaGFydF93aWR0aCwNCiAgICAgIGhlaWdodDpjaGFydF9oZWlnaHQtOTB9LA0KICAgICAgaEF4 aXM6e3RpdGxlOiJkYXRhcmF0ZSBpbiBrYnBzIn0sIHZBeGlzOnt0aXRsZToicXVhbGl0eSBpbiBk ZWNpYmVscyJ9LA0KICAgICAgbGVnZW5kOntwb3NpdGlvbjoiaW4ifSwgdGl0bGU6aW1hZ2VzdHIs IHBvaW50U2l6ZToyLCBsaW5lV2lkdGg6MSwNCiAgICAgIHdpZHRoOmNoYXJ0X3dpZHRoLCBoZWln aHQ6Y2hhcnRfaGVpZ2h0LTUwIH0pOw0KDQogIGdvb2dsZS52aXN1YWxpemF0aW9uLmV2ZW50cy5h ZGRMaXN0ZW5lcihjaGFydCwgJ3NlbGVjdCcsIGNoYXJ0U2VsZWN0KTsNCiAgZ29vZ2xlLnZpc3Vh bGl6YXRpb24uZXZlbnRzLmFkZExpc3RlbmVyKGNoYXJ0LCAnb25tb3VzZW92ZXInLCBjaGFydE1v dXNlT3Zlcik7DQogIGdvb2dsZS52aXN1YWxpemF0aW9uLmV2ZW50cy5hZGRMaXN0ZW5lcihjaGFy dCwgJ29ubW91c2VvdXQnLCBjaGFydE1vdXNlT3V0KTsNCn0NCg0KZnVuY3Rpb24gY2hhcnRNb3Vz ZU91dChlKSB7DQogIHN0YXR1c2JhciA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCdzdGF0dXMn KTsNCiAgc3RhdHVzYmFyLnN0eWxlLmRpc3BsYXkgPSAnbm9uZSc7DQp9DQoNCmZ1bmN0aW9uIGNo YXJ0TW91c2VPdmVyKGUpIHsNCiAgcG9pbnREaWZmZXJlbmNlKGUucm93LCBlLmNvbHVtbikNCn0N Cg0KZnVuY3Rpb24gcG9pbnREaWZmZXJlbmNlKHJvdywgY29sKSB7DQogIGlmKCFyb3cgfHwgIWNv bCkNCiAgICByZXR1cm47DQoNCiAgdmFyIGNvbHMgPSBtZXRyaWNkYXRhLmdldE51bWJlck9mQ29s dW1ucygpOw0KICB2YXIgcm93cyA9IG1ldHJpY2RhdGEuZ2V0TnVtYmVyT2ZSb3dzKCk7DQoNCiAg dmFyIHNlbF9iaXRyYXRlID0gbWV0cmljdmlldy5nZXRWYWx1ZShyb3csIDAgKTsNCiAgdmFyIHNl bF9tZXRyaWMgPSBtZXRyaWN2aWV3LmdldFZhbHVlKHJvdywgY29sKTsNCg0KICB2YXIgbWVzc2Fn ZSA9ICJBdCAiICsgc2VsX21ldHJpYy50b0ZpeGVkKDIpICsgIiBkZWNpYmVscywgPGVtPiINCiAg bWVzc2FnZSA9IG1lc3NhZ2UgKyBtZXRyaWNkYXRhLmdldENvbHVtbkxhYmVsKGNvbCkgKyAiPC9l bT4gaXMgPHVsPiINCg0KICAvLyBjb2wgMCBpcyBkYXRhcmF0ZQ0KICBmb3IoIHZhciBpPTE7aTxj b2xzOysraSkgew0KDQogICAgdmFyIG1ldHJpY19ncmVhdGVzdF90aGF0c19sZXNzID0gMDsNCiAg ICB2YXIgcmF0ZV9ncmVhdGVzdF90aGF0c19sZXNzID0gMDsNCiAgICB2YXIgbWV0cmljX3NtYWxs ZXN0X3RoYXRzX2dyZWF0ZXIgPSA5OTk7DQogICAgdmFyIHJhdGVfc21hbGxlc3RfdGhhdHNfZ3Jl YXRlciA9IDA7DQoNCiAgICBpZihpPT1jb2wpDQogICAgICBjb250aW51ZTsNCg0KICAgIC8vIEZp bmQgdGhlIGxvd2VzdCBtZXRyaWMgZm9yIHRoZSBjb2x1bW4gdGhhdCdzIGdyZWF0ZXIgdGhhbiBz ZWxfbWV0cmljIGFuZA0KICAgIC8vIHRoZSBoaWdoZXN0IG1ldHJpYyBmb3IgdGhpcyBjb2x1bW4g dGhhdCdzIGxlc3MgdGhhbiB0aGUgbWV0cmljLg0KICAgIGZvcih2YXIgbGluZV9jb3VudCA9IDA7 IGxpbmVfY291bnQgPCByb3dzOyArK2xpbmVfY291bnQpIHsNCiAgICAgIHRoaXNfbWV0cmljID0g bWV0cmljZGF0YS5nZXRWYWx1ZShsaW5lX2NvdW50LCBpKQ0KICAgICAgdGhpc19yYXRlID0gbWV0 cmljZGF0YS5nZXRWYWx1ZShsaW5lX2NvdW50LCAwKQ0KICAgICAgaWYoIXRoaXNfbWV0cmljKQ0K ICAgICAgICBjb250aW51ZTsNCg0KICAgICAgaWYodGhpc19tZXRyaWMgPiBtZXRyaWNfZ3JlYXRl c3RfdGhhdHNfbGVzcyAmJg0KICAgICAgICAgdGhpc19tZXRyaWMgPCBzZWxfbWV0cmljKSB7DQog ICAgICAgIG1ldHJpY19ncmVhdGVzdF90aGF0c19sZXNzID0gdGhpc19tZXRyaWM7DQogICAgICAg IHJhdGVfZ3JlYXRlc3RfdGhhdHNfbGVzcyA9IHRoaXNfcmF0ZTsNCiAgICAgIH0NCiAgICAgIGlm KHRoaXNfbWV0cmljIDwgbWV0cmljX3NtYWxsZXN0X3RoYXRzX2dyZWF0ZXIgJiYNCiAgICAgICAg dGhpc19tZXRyaWMgPiBzZWxfbWV0cmljKSB7DQogICAgICAgIG1ldHJpY19zbWFsbGVzdF90aGF0 c19ncmVhdGVyID0gdGhpc19tZXRyaWM7DQogICAgICAgIHJhdGVfc21hbGxlc3RfdGhhdHNfZ3Jl YXRlciA9IHRoaXNfcmF0ZTsNCiAgICAgIH0NCiAgICB9DQoNCiAgICBpZihyYXRlX3NtYWxsZXN0 X3RoYXRzX2dyZWF0ZXIgPT0gMCB8fCByYXRlX2dyZWF0ZXN0X3RoYXRzX2xlc3MgPT0gMCkgew0K ICAgICAgbWVzc2FnZSA9IG1lc3NhZ2UgKyAiIDxsaT4gQ291bGRuJ3QgZmluZCBhIHBvaW50IG9u IGJvdGggc2lkZXMuPC9saT4iDQogICAgfSBlbHNlIHsNCiAgICAgIG1ldHJpY19zbG9wZSA9ICgg cmF0ZV9zbWFsbGVzdF90aGF0c19ncmVhdGVyIC0gcmF0ZV9ncmVhdGVzdF90aGF0c19sZXNzKSAv DQogICAgICAgICAgKCBtZXRyaWNfc21hbGxlc3RfdGhhdHNfZ3JlYXRlciAtIG1ldHJpY19ncmVh dGVzdF90aGF0c19sZXNzKTsNCg0KICAgICAgcHJvamVjdGVkX3JhdGUgPSAoIHNlbF9tZXRyaWMg LSBtZXRyaWNfZ3JlYXRlc3RfdGhhdHNfbGVzcykgKg0KICAgICAgICAgIG1ldHJpY19zbG9wZSAr IHJhdGVfZ3JlYXRlc3RfdGhhdHNfbGVzczsNCg0KICAgICAgZGlmZmVyZW5jZSA9IDEwMCAqIChw cm9qZWN0ZWRfcmF0ZSAvIHNlbF9iaXRyYXRlIC0gMSk7DQoNCg0KICAgICAgaWYgKGRpZmZlcmVu Y2UgPiAwKQ0KICAgICAgICBtZXNzYWdlID0gbWVzc2FnZSArICI8bGk+ICAiICsgZGlmZmVyZW5j ZS50b0ZpeGVkKDIpICsNCiAgICAgICAgICAgICAgICAgICIlIHNtYWxsZXIgdGhhbiA8ZW0+IiAr DQogICAgICAgICAgICAgICAgICBtZXRyaWNkYXRhLmdldENvbHVtbkxhYmVsKGkpICsgIjwvZW0+ PC9saT4gIg0KICAgICAgZWxzZQ0KICAgICAgICBtZXNzYWdlID0gbWVzc2FnZSArICI8bGk+ICAi ICsgLWRpZmZlcmVuY2UudG9GaXhlZCgyKSArDQogICAgICAgICAgICAgICAgICAiJSBiaWdnZXIg dGhhbiA8ZW0+IiArDQogICAgICAgICAgICAgICAgICBtZXRyaWNkYXRhLmdldENvbHVtbkxhYmVs KGkpICsgIjwvZW0+PC9saT4gIg0KICAgIH0NCg0KICB9DQogIG1lc3NhZ2UgPSBtZXNzYWdlICsg IjwvdWw+Ig0KICBzdGF0dXNiYXIgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgnc3RhdHVzJyk7 DQogIHN0YXR1c2Jhci5pbm5lckhUTUwgPSAiPHA+IiArIG1lc3NhZ2UgKyAiPC9wPiI7DQogIHN0 YXR1c2Jhci5zdHlsZS5kaXNwbGF5ID0gJ2Jsb2NrJzsNCn0NCg0KZnVuY3Rpb24gY2hhcnRTZWxl Y3QoKSB7DQogIHZhciBzZWxlY3Rpb24gPSBjaGFydC5nZXRTZWxlY3Rpb24oKTsNCiAgdmFyIG1l c3NhZ2UgPSAnJzsNCiAgdmFyIG1pbiA9IG1ldHJpY3ZpZXcuZ2V0Rm9ybWF0dGVkVmFsdWUoc2Vs ZWN0aW9uWzBdLnJvdywgMCk7DQogIHZhciBtYXggPSBtZXRyaWN2aWV3LmdldEZvcm1hdHRlZFZh bHVlKHNlbGVjdGlvbltzZWxlY3Rpb24ubGVuZ3RoLTFdLnJvdywgMCk7DQogIHZhciB2YWwgPSBt ZXRyaWN2aWV3LmdldEZvcm1hdHRlZFZhbHVlKHNlbGVjdGlvblswXS5yb3csc2VsZWN0aW9uWzBd LmNvbHVtbik7DQoNCiAgcG9pbnREaWZmZXJlbmNlKHNlbGVjdGlvblswXS5yb3csIHNlbGVjdGlv blswXS5jb2x1bW4pDQogIG1pbiA9IG1pbiAvIDMNCiAgbWF4ID0gbWF4ICogMw0KICBtZXRyaWN2 aWV3LnNldFJvd3MobWV0cmljZGF0YS5nZXRGaWx0ZXJlZFJvd3MoDQogICAgICBbe2NvbHVtbjog MCxtaW5WYWx1ZTogbWluLCBtYXhWYWx1ZTptYXh9XSkpOw0KDQogIGNoYXJ0LmRyYXcobWV0cmlj dmlldywge2N1cnZlVHlwZTonZnVuY3Rpb24nLA0KICAgICAgY2hhcnRBcmVhOntsZWZ0OjQwLCB0 b3A6MTAsIHdpZHRoOmNoYXJ0X3dpZHRoLCBoZWlnaHQ6Y2hhcnRfaGVpZ2h0IC0gMTEwfSwNCiAg ICAgIGhBeGlzOnt0aXRsZToiZGF0YXJhdGUgaW4ga2JwcyJ9LCB2QXhpczp7dGl0bGU6InF1YWxp dHkgaW4gZGVjaWJlbHMifSwNCiAgICAgIGxlZ2VuZDp7cG9zaXRpb246ImluIn0sIHRpdGxlOmlt YWdlc3RyLCBwb2ludFNpemU6MiwgbGluZVdpZHRoOjEsDQogICAgICB3aWR0aDpjaGFydF93aWR0 aCwgaGVpZ2h0OmNoYXJ0X2hlaWdodCAtIDUwfSk7DQp9DQoNCmZ1bmN0aW9uIHNlbGVjdEJldHRl ckhhbmRsZXIoKSB7DQogIHZhciBzZWxlY3Rpb24gPSBiZXR0ZXJ0YWJsZS5nZXRTZWxlY3Rpb24o KTsNCiAgZm9yICh2YXIgaSA9IDA7IGkgPCBzZWxlY3Rpb24ubGVuZ3RoOyBpKyspIHsNCiAgICBp dGVtID0gc2VsZWN0aW9uW2ldOw0KICB9DQogIHNlbGVjdGVkID0gaXRlbS5yb3cNCiAgcXVlcnlf ZmlsZSgpDQp9DQoNCmdvb2dsZS5sb2FkKCd2aXN1YWxpemF0aW9uJywgJzEnLCB7J3BhY2thZ2Vz JyA6IFsnY29yZWNoYXJ0JywndGFibGUnXX0pOw0KZ29vZ2xlLnNldE9uTG9hZENhbGxiYWNrKHNl dHVwX3Zpcyk7DQo8L3NjcmlwdD4NCjwvaGVhZD4NCg0KPGJvZHk+DQoNCiAgPGRpdiBjbGFzcz0i Y29udGFpbmVyXzEyIj4NCg0KICAgIDxkaXYgY2xhc3M9ImdyaWRfMTIgaGVhZGVyIj4NCiAgICAg IDxoMj5WUDggUmVzdWx0czwvaDI+DQogICAgPC9kaXY+DQoNCiAgICA8ZGl2IGNsYXNzPSJncmlk XzEyIHJhZGlvIj4NCg0KICAgIDxkaXYgY2xhc3M9ImdyaWRfMTIgbWFpbiI+DQoNCiAgICAgIDxk aXYgY2xhc3M9ImdyaWRfNSBhbHBoYSBjbGlwbGlzdCI+DQogICAgICAgIDxkaXYgaWQ9ImJldHRl cnRhYmxlIj48L2Rpdj4NCiAgICAgIDwvZGl2Pg0KDQogICAgICA8ZGl2IGNsYXNzPSJncmlkXzUg Y2hhcnRhcmVhIj4NCiAgICAgICAgPGRpdiBpZD0ibWV0cmljZ3JhcGgiPjwvZGl2Pg0KICAgICAg PC9kaXY+DQoNCiAgICAgIDxkaXYgY2xhc3M9ImdyaWRfMiBvbWVnYSBpbmRpY2F0b3JzIj4NCiAg ICAgICAgPGRpdiBjbGFzcz0iY29udGVudCI+DQogICAgICAgICAgPGg1PkluZGljYXRvcnM8L2g1 Pg0KICAgICAgICAgIDxocj4NCiAgICAgICAgICA8ZGl2IGlkPSJzdGF0dXMiPjwvZGl2Pg0KICAg ICAgICA8L2Rpdj4NCiAgICAgIDwvZGl2Pg0KDQogICAgPC9kaXY+DQoNCiAgPC9kaXY+DQoNCjwv Ym9keT4NCjwvaHRtbD4NCgo= --_006_BBE9739C2C302046BD34B42713A1E2A22DECC12FESESSMB105erics_ Content-Type: text/html; name="vp8_vs_x264_constrained_high.html" Content-Description: vp8_vs_x264_constrained_high.html Content-Disposition: attachment; filename="vp8_vs_x264_constrained_high.html"; size=22299; creation-date="Sat, 22 Jun 2013 13:41:08 GMT"; modification-date="Sat, 22 Jun 2013 13:41:08 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWw+DQo8aHRtbCBsYW5nPSJlbiI+DQo8aGVhZD4NCjxtZXRhIGNoYXJzZXQ9 InV0Zi04Ij4NCjx0aXRsZT5Db21wYXJhdGl2ZSBSZXN1bHRzPC90aXRsZT4NCjxzdHlsZSB0eXBl PSJ0ZXh0L2NzcyI+DQo8IS0tIEJlZ2luIDk2MCByZXNldCAtLT4NCmEsYWJicixhY3JvbnltLGFk ZHJlc3MsYXBwbGV0LGFydGljbGUsYXNpZGUsYXVkaW8sYixiaWcsYmxvY2txdW90ZSxib2R5LGNh bnZhcyxjYXB0aW9uLGNlbnRlcixjaXRlLGMNCm9kZSxkZCxkZWwsZGV0YWlscyxkZm4sZGlhbG9n LGRpdixkbCxkdCxlbSxlbWJlZCxmaWVsZHNldCxmaWdjYXB0aW9uLGZpZ3VyZSxmb250LGZvb3Rl cixmb3JtLGgxLGgyLGgNCjMsaDQsaDUsaDYsaGVhZGVyLGhncm91cCxocixodG1sLGksaWZyYW1l LGltZyxpbnMsa2JkLGxhYmVsLGxlZ2VuZCxsaSxtYXJrLG1lbnUsbWV0ZXIsbmF2LG9iamVjdCxv bCwNCm91dHB1dCxwLHByZSxwcm9ncmVzcyxxLHJwLHJ0LHJ1YnkscyxzYW1wLHNlY3Rpb24sc21h bGwsc3BhbixzdHJpa2Usc3Ryb25nLHN1YixzdW1tYXJ5LHN1cCx0YWJsZSx0Ym8NCmR5LHRkLHRm b290LHRoLHRoZWFkLHRpbWUsdHIsdHQsdSx1bCx2YXIsdmlkZW8seG1we2JvcmRlcjowO21hcmdp bjowO3BhZGRpbmc6MDtmb250LXNpemU6MTAwJX1odG1sLGINCm9keXtoZWlnaHQ6MTAwJX1hcnRp Y2xlLGFzaWRlLGRldGFpbHMsZmlnY2FwdGlvbixmaWd1cmUsZm9vdGVyLGhlYWRlcixoZ3JvdXAs bWVudSxuYXYsc2VjdGlvbntkaXNwbGENCnk6YmxvY2t9YixzdHJvbmd7Zm9udC13ZWlnaHQ6Ym9s ZH1pbWd7Y29sb3I6dHJhbnNwYXJlbnQ7Zm9udC1zaXplOjA7dmVydGljYWwtYWxpZ246bWlkZGxl Oy1tcy1pbnRlcnANCm9sYXRpb24tbW9kZTpiaWN1YmljfW9sLHVse2xpc3Qtc3R5bGU6bm9uZX1s aXtkaXNwbGF5Omxpc3QtaXRlbX10YWJsZXtib3JkZXItY29sbGFwc2U6Y29sbGFwc2U7Ym9yZGUN CnItc3BhY2luZzowfXRoLHRkLGNhcHRpb257Zm9udC13ZWlnaHQ6bm9ybWFsO3ZlcnRpY2FsLWFs aWduOnRvcDt0ZXh0LWFsaWduOmxlZnR9cXtxdW90ZXM6bm9uZX1xOmJlZm8NCnJlLHE6YWZ0ZXJ7 Y29udGVudDonJztjb250ZW50Om5vbmV9c3ViLHN1cCxzbWFsbHtmb250LXNpemU6NzUlfXN1Yixz dXB7bGluZS1oZWlnaHQ6MDtwb3NpdGlvbjpyZWxhdGkNCnZlO3ZlcnRpY2FsLWFsaWduOmJhc2Vs aW5lfXN1Yntib3R0b206LTAuMjVlbX1zdXB7dG9wOi0wLjVlbX1zdmd7b3ZlcmZsb3c6aGlkZGVu fQ0KPCEtLSBFbmQgOTYwIHJlc2V0IC0tPg0KPCEtLSBCZWdpbiA5NjAgdGV4dCAtLT4NCmJvZHl7 Zm9udDoxM3B4LzEuNSAnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLCdMaWJlcmF0aW9uIFNhbnMnLEZy ZWVTYW5zLHNhbnMtc2VyaWZ9cHJlLGNvZGV7Zm9udC1mYW1pbHkNCjonRGVqYVZ1IFNhbnMgTW9u bycsTWVubG8sQ29uc29sYXMsbW9ub3NwYWNlfWhye2JvcmRlcjowICNjY2Mgc29saWQ7Ym9yZGVy LXRvcC13aWR0aDoxcHg7Y2xlYXI6Ym90aDsNCmhlaWdodDowfWgxe2ZvbnQtc2l6ZToyNXB4fWgy e2ZvbnQtc2l6ZToyM3B4fWgze2ZvbnQtc2l6ZToyMXB4fWg0e2ZvbnQtc2l6ZToxOXB4fWg1e2Zv bnQtc2l6ZToxN3B4fWgNCjZ7Zm9udC1zaXplOjE1cHh9b2x7bGlzdC1zdHlsZTpkZWNpbWFsfXVs e2xpc3Qtc3R5bGU6ZGlzY31saXttYXJnaW4tbGVmdDozMHB4fXAsZGwsaHIsaDEsaDIsaDMsaDQs aDUNCixoNixvbCx1bCxwcmUsdGFibGUsYWRkcmVzcyxmaWVsZHNldCxmaWd1cmV7bWFyZ2luLWJv dHRvbToyMHB4fQ0KPCEtLSBFbmQgOTYwIHRleHQgLS0+DQo8IS0tIEJlZ2luIDk2MCBncmlkIChm bHVpZCB2YXJpYW50KQ0KICAgICAxMiBjb2x1bW5zLCAxMTUycHggdG90YWwgd2lkdGgNCiAgICAg aHR0cDovLzk2MC5ncy8gfCBodHRwOi8vZ3JpZHMuaGVyb2t1LmNvbS8gLS0+DQouY29udGFpbmVy XzEye3dpZHRoOjkyJTttYXJnaW4tbGVmdDo0JTttYXJnaW4tcmlnaHQ6NCV9LmdyaWRfMSwuZ3Jp ZF8yLC5ncmlkXzMsLmdyaWRfNCwuZ3JpZF81LC5ncmlkDQpfNiwuZ3JpZF83LC5ncmlkXzgsLmdy aWRfOSwuZ3JpZF8xMCwuZ3JpZF8xMSwuZ3JpZF8xMntkaXNwbGF5OmlubGluZTtmbG9hdDpsZWZ0 O3Bvc2l0aW9uOnJlbGF0aXZlO21hDQpyZ2luLWxlZnQ6MSU7bWFyZ2luLXJpZ2h0OjElfS5hbHBo YXttYXJnaW4tbGVmdDowfS5vbWVnYXttYXJnaW4tcmlnaHQ6MH0uY29udGFpbmVyXzEyIC5ncmlk XzF7d2lkdGg6DQo2LjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF8ye3dpZHRoOjE0LjY2NyV9LmNv bnRhaW5lcl8xMiAuZ3JpZF8ze3dpZHRoOjIzLjAlfS5jb250YWluZXJfMTIgLmdyaWRfNHt3DQpp ZHRoOjMxLjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF81e3dpZHRoOjM5LjY2NyV9LmNvbnRhaW5l cl8xMiAuZ3JpZF82e3dpZHRoOjQ4LjAlfS5jb250YWluZXJfMTIgLmdyDQppZF83e3dpZHRoOjU2 LjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF84e3dpZHRoOjY0LjY2NyV9LmNvbnRhaW5lcl8xMiAu Z3JpZF85e3dpZHRoOjczLjAlfS5jb250YWluZXJfDQoxMiAuZ3JpZF8xMHt3aWR0aDo4MS4zMzMl fS5jb250YWluZXJfMTIgLmdyaWRfMTF7d2lkdGg6ODkuNjY3JX0uY29udGFpbmVyXzEyIC5ncmlk XzEye3dpZHRoOjk4LjAlfS5jDQpvbnRhaW5lcl8xMiAucHJlZml4XzF7cGFkZGluZy1sZWZ0Ojgu MzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfMntwYWRkaW5nLWxlZnQ6MTYuNjY3JX0uY29udGFp bmVyXzEyDQogLnByZWZpeF8ze3BhZGRpbmctbGVmdDoyNS4wJX0uY29udGFpbmVyXzEyIC5wcmVm aXhfNHtwYWRkaW5nLWxlZnQ6MzMuMzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfNXtwDQphZGRp bmctbGVmdDo0MS42NjclfS5jb250YWluZXJfMTIgLnByZWZpeF82e3BhZGRpbmctbGVmdDo1MC4w JX0uY29udGFpbmVyXzEyIC5wcmVmaXhfN3twYWRkaW5nLWxlZnQ6DQo1OC4zMzMlfS5jb250YWlu ZXJfMTIgLnByZWZpeF84e3BhZGRpbmctbGVmdDo2Ni42NjclfS5jb250YWluZXJfMTIgLnByZWZp eF85e3BhZGRpbmctbGVmdDo3NS4wJX0uY29uDQp0YWluZXJfMTIgLnByZWZpeF8xMHtwYWRkaW5n LWxlZnQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfMTF7cGFkZGluZy1sZWZ0OjkxLjY2 NyV9LmNvbnRhaW5lcl8xDQoyIC5zdWZmaXhfMXtwYWRkaW5nLXJpZ2h0OjguMzMzJX0uY29udGFp bmVyXzEyIC5zdWZmaXhfMntwYWRkaW5nLXJpZ2h0OjE2LjY2NyV9LmNvbnRhaW5lcl8xMiAuc3Vm Zml4DQpfM3twYWRkaW5nLXJpZ2h0OjI1LjAlfS5jb250YWluZXJfMTIgLnN1ZmZpeF80e3BhZGRp bmctcmlnaHQ6MzMuMzMzJX0uY29udGFpbmVyXzEyIC5zdWZmaXhfNXtwYWRkaW5nDQotcmlnaHQ6 NDEuNjY3JX0uY29udGFpbmVyXzEyIC5zdWZmaXhfNntwYWRkaW5nLXJpZ2h0OjUwLjAlfS5jb250 YWluZXJfMTIgLnN1ZmZpeF83e3BhZGRpbmctcmlnaHQ6NTguDQozMzMlfS5jb250YWluZXJfMTIg LnN1ZmZpeF84e3BhZGRpbmctcmlnaHQ6NjYuNjY3JX0uY29udGFpbmVyXzEyIC5zdWZmaXhfOXtw YWRkaW5nLXJpZ2h0Ojc1LjAlfS5jb250DQphaW5lcl8xMiAuc3VmZml4XzEwe3BhZGRpbmctcmln aHQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5zdWZmaXhfMTF7cGFkZGluZy1yaWdodDo5MS42Njcl fS5jb250YWluZXJfDQoxMiAucHVzaF8xe2xlZnQ6OC4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hf MntsZWZ0OjE2LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVzaF8ze2xlZnQ6MjUuMCV9LmNvbnRhaW5l DQpyXzEyIC5wdXNoXzR7bGVmdDozMy4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hfNXtsZWZ0OjQx LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVzaF82e2xlZnQ6NTAuMCV9LmNvbnRhDQppbmVyXzEyIC5w dXNoXzd7bGVmdDo1OC4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hfOHtsZWZ0OjY2LjY2NyV9LmNv bnRhaW5lcl8xMiAucHVzaF85e2xlZnQ6NzUuMCV9LmNvDQpudGFpbmVyXzEyIC5wdXNoXzEwe2xl ZnQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5wdXNoXzExe2xlZnQ6OTEuNjY3JX0uY29udGFpbmVy XzEyIC5wdWxsXzF7bGVmdDotOC4zDQozMyV9LmNvbnRhaW5lcl8xMiAucHVsbF8ye2xlZnQ6LTE2 LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVsbF8ze2xlZnQ6LTI1LjAlfS5jb250YWluZXJfMTIgLnB1 bGxfNHtsZWZ0DQo6LTMzLjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF81e2xlZnQ6LTQxLjY2NyV9 LmNvbnRhaW5lcl8xMiAucHVsbF82e2xlZnQ6LTUwLjAlfS5jb250YWluZXJfMTIgLnB1bGxfDQo3 e2xlZnQ6LTU4LjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF84e2xlZnQ6LTY2LjY2NyV9LmNvbnRh aW5lcl8xMiAucHVsbF85e2xlZnQ6LTc1LjAlfS5jb250YWluZXJfMTINCi5wdWxsXzEwe2xlZnQ6 LTgzLjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF8xMXtsZWZ0Oi05MS42NjclfS5jbGVhcntjbGVh cjpib3RoO2Rpc3BsYXk6YmxvY2s7b3ZlcmZsb3cNCjpoaWRkZW47dmlzaWJpbGl0eTpoaWRkZW47 d2lkdGg6MDtoZWlnaHQ6MH0uY2xlYXJmaXg6YWZ0ZXJ7Y2xlYXI6Ym90aDtjb250ZW50OicgJztk aXNwbGF5OmJsb2NrO2ZvbnQNCi1zaXplOjA7bGluZS1oZWlnaHQ6MDt2aXNpYmlsaXR5OmhpZGRl bjt3aWR0aDowO2hlaWdodDowfS5jbGVhcmZpeHtkaXNwbGF5OmlubGluZS1ibG9ja30qIGh0bWwg LmNsZWENCnJmaXh7aGVpZ2h0OjElfS5jbGVhcmZpeHtkaXNwbGF5OmJsb2NrfQ0KPCEtLSBFbmQg OTYwIGdyaWQgLS0+DQoNCmRpdi5tZXRyaWNncmFwaCB7DQoNCn0NCg0KYm9keSB7DQoNCn0NCg0K ZGl2LmhlYWRlciB7DQogIGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsNCn0NCg0KZGl2 LmhlYWRlciBoMiB7DQogIG1hcmdpbjogLjVlbSBhdXRvOw0KfQ0KDQpkaXYucmFkaW8gew0KICBm b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7DQogIG1hcmdpbi1ib3R0b206IDFlbTsNCn0N Cg0KZGl2Lm1haW4gew0KDQp9DQoNCmRpdi5jbGlwbGlzdCB7DQogIGZvbnQtZmFtaWx5OiBBcmlh bCwgc2Fucy1zZXJpZjsNCiAgbWFyZ2luLXRvcDogNnB4Ow0KfQ0KDQpkaXYuY2hhcnRhcmVhIHsN CiAgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOw0KfQ0KDQpkaXYuaW5kaWNhdG9ycyB7 DQogIGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsNCiAgZm9udC1zaXplOiAxM3B4Ow0K ICBtYXJnaW4tdG9wOiA2cHg7DQogIG1pbi1oZWlnaHQ6IDYwMHB4Ow0KICBiYWNrZ3JvdW5kLWNv bG9yOiAjZjdmN2Y3Ow0KfQ0KDQpkaXYuaW5kaWNhdG9ycyBkaXYuY29udGVudCB7DQogIG1hcmdp bjogMWVtOw0KfQ0KDQpkaXYuaW5kaWNhdG9ycyBkaXYuY29udGVudCBoNSB7DQogIGZvbnQtc2l6 ZTogMTNweDsNCiAgdGV4dC1hbGlnbjogY2VudGVyOw0KICBtYXJnaW46IDA7DQp9DQoNCmRpdi5p bmRpY2F0b3JzIGRpdi5jb250ZW50IHVsIHsNCiAgbWFyZ2luLWxlZnQ6IDA7DQogIHBhZGRpbmct bGVmdDogMDsNCiAgbWFyZ2luLXRvcDogMDsNCn0NCg0KZGl2LmluZGljYXRvcnMgZGl2LmNvbnRl bnQgdWwgbGkgew0KICBtYXJnaW4tbGVmdDogMS41ZW07DQp9DQoNCmRpdi5pbmRpY2F0b3JzIGRp di5jb250ZW50IHA6Zmlyc3QtY2hpbGQgew0KICBtYXJnaW4tYm90dG9tOiAuNWVtOw0KfQ0KDQpz cGFuLmdvb2dsZS12aXN1YWxpemF0aW9uLXRhYmxlLXNvcnRpbmQgew0KICBjb2xvcjogIzAwMDsN Cn0NCg0KLmhlYWRlci1zdHlsZSB7DQogIGZvbnQtd2VpZ2h0OiBib2xkOw0KICBib3JkZXI6IDFw eCBzb2xpZCAjZmZmOw0KICBiYWNrZ3JvdW5kLWNvbG9yOiAjY2NjOw0KfQ0KDQp0ZC5oZWFkZXIt c3R5bGUrdGQgew0KDQp9DQoNCi5vcmFuZ2UtYmFja2dyb3VuZCB7DQogIGJhY2tncm91bmQtY29s b3I6IG9yYW5nZTsNCn0NCg0KLmxpZ2h0LWdyYXktYmFja2dyb3VuZCB7DQogIGJhY2tncm91bmQt Y29sb3I6ICNmMGYwZjA7DQp9DQo8L3N0eWxlPg0KPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3Jp cHQiIHNyYz0iaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9qc2FwaSI+PC9zY3JpcHQ+DQo8c2NyaXB0 IHR5cGU9InRleHQvamF2YXNjcmlwdCI+DQpnb29nbGUubG9hZCgndmlzdWFsaXphdGlvbicsICcx LjEnLCB7J3BhY2thZ2VzJzpbJ3RhYmxlJ119KTsNCnZhciBjaGFydF9sZWZ0ICAgPSA2MDsNCnZh ciBjaGFydF90b3AgICAgPSA2Ow0KdmFyIGNoYXJ0X2hlaWdodCA9IGRvY3VtZW50LmRvY3VtZW50 RWxlbWVudC5jbGllbnRIZWlnaHQtMTAwOw0KdmFyIGNoYXJ0X3dpZHRoICA9ICIxMDAlIjsNCmZ0 YWJsZT0nZmlsZXN0YWJsZV9hdmcnDQp2YXIgc25ycyA9IFtdOw0KdmFyIGZpbGVzdGFibGVfZHNu ciA9IFtdOw0KdmFyIGZpbGVzdGFibGVfZHJhdGUgPSBbXTsNCnZhciBmaWxlc3RhYmxlX2F2ZyA9 IFtdOw0KDQovLyBQeXRob24gdGVtcGxhdGUgY29kZSByZXBsYWNlcyB0aGUgZm9sbG93aW5nIDIg bGluZXMuDQpmaWxlc3RhYmxlX2RzbnJbMV09eyJyb3dzIjpbeyJjIjpbeyJ2IjoiZGVza3RvcF82 NDBfMzYwXzMwIn0seyJ2IjowLjY4MTE3Njc5MDg5ODQ1ODg0fV19LHsiYyI6W3sidiI6ImdpcHNy ZWNtb3Rpb25fMTI4MF83MjBfNTAifSx7InYiOjAuNjAwOTI5NzU0Mzk4MDA4fV19LHsiYyI6W3si diI6ImdpcHNyZWNzdGF0XzEyODBfNzIwXzUwIn0seyJ2IjowLjg5MjIwNDMzMTMxNTkwNzQ4fV19 LHsiYyI6W3sidiI6ImtpcmxhbmRfNjQwXzQ4MF8zMCJ9LHsidiI6MS4xMDI1MjE2ODAwMzE5MDg5 fV19LHsiYyI6W3sidiI6Im1hY21hcmNvbW92aW5nXzY0MF80ODBfMzAifSx7InYiOjAuNDAyMDMz NzkzMDk2NDEwMTN9XX0seyJjIjpbeyJ2IjoibWFjbWFyY29zdGF0aW9uYXJ5XzY0MF80ODBfMzAi fSx7InYiOjAuNDIxODg0NzkxOTYzOTExOTl9XX0seyJjIjpbeyJ2IjoibmlrbGFzXzEyODBfNzIw XzMwIn0seyJ2IjowLjQ5NzcyNDYyODYzNzE5NTc0fV19LHsiYyI6W3sidiI6Im5pa2xhc182NDBf NDgwXzMwIn0seyJ2IjowLjU1MTI5NjY1MjcyOTgxMDIxfV19LHsiYyI6W3sidiI6InRhY29tYW5h cnJvd3NfNjQwXzQ4MF8zMCJ9LHsidiI6MS4xMzU4NTE5MzY0NDQ1MjA1fV19LHsiYyI6W3sidiI6 InRhY29tYXNtYWxsY2FtZXJhbW92ZW1lbnRfNjQwXzQ4MF8zMCJ9LHsidiI6MC40NTI1NzcyMDMw OTEwNDQ3MX1dfSx7ImMiOlt7InYiOiJ0aGFsb3VuZGVza210Z182NDBfNDgwXzMwIn0seyJ2Ijox LjIyNDI0Nzk5NDAwNjQ2MTJ9XX0seyJjIjpbeyJ2IjoiT1ZFUkFMTCJ9LHsidiI6MC43MjM4NTkw NTA2MDEyMzk3OH1dfV0sImNvbHMiOlt7InR5cGUiOiJzdHJpbmciLCJpZCI6ImZpbGUiLCJsYWJl bCI6IkZpbGUifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3gyNjRfY29uc3RyYWluZWRf aGlnaCIsImxhYmVsIjoic3RhdHMveDI2NF9jb25zdHJhaW5lZF9oaWdoIn1dfQoNCmZpbGVzdGFi bGVfYXZnWzFdPXsicm93cyI6W3siYyI6W3sidiI6ImRlc2t0b3BfNjQwXzM2MF8zMCJ9LHsidiI6 MTkuNDk2OTExMjAwNjI4MjA4fV19LHsiYyI6W3sidiI6ImdpcHNyZWNtb3Rpb25fMTI4MF83MjBf NTAifSx7InYiOjE4LjI3NjgwNjI4MzQ0NDM4N31dfSx7ImMiOlt7InYiOiJnaXBzcmVjc3RhdF8x MjgwXzcyMF81MCJ9LHsidiI6MzcuMDUwOTE4NDQ4NjQ4Njh9XX0seyJjIjpbeyJ2Ijoia2lybGFu ZF82NDBfNDgwXzMwIn0seyJ2Ijo0OS41MTAyMjAwOTYyNzI0Mn1dfSx7ImMiOlt7InYiOiJtYWNt YXJjb21vdmluZ182NDBfNDgwXzMwIn0seyJ2IjoxNS43NjM4NTc1NjI0MzgxODN9XX0seyJjIjpb eyJ2IjoibWFjbWFyY29zdGF0aW9uYXJ5XzY0MF80ODBfMzAifSx7InYiOjIyLjkyMTcyNTEzODgx MzI0fV19LHsiYyI6W3sidiI6Im5pa2xhc18xMjgwXzcyMF8zMCJ9LHsidiI6MTEuOTUzMzE0NTY5 MjQ1NTI2fV19LHsiYyI6W3sidiI6Im5pa2xhc182NDBfNDgwXzMwIn0seyJ2IjoxMi4wNTIxMTgz NDI0MDY2OTJ9XX0seyJjIjpbeyJ2IjoidGFjb21hbmFycm93c182NDBfNDgwXzMwIn0seyJ2Ijoz OS43MjYxNzI5OTQ1MTU4NX1dfSx7ImMiOlt7InYiOiJ0YWNvbWFzbWFsbGNhbWVyYW1vdmVtZW50 XzY0MF80ODBfMzAifSx7InYiOjE1LjE0NjA3MDM3NzcxMTY3N31dfSx7ImMiOlt7InYiOiJ0aGFs b3VuZGVza210Z182NDBfNDgwXzMwIn0seyJ2IjoyOS41NjI5ODQxNjIzNzUyMzd9XX0seyJjIjpb eyJ2IjoiT1ZFUkFMTCJ9LHsidiI6MjQuNjc4MjgxNzQzMzE4MTg4fV19XSwiY29scyI6W3sidHlw ZSI6InN0cmluZyIsImlkIjoiZmlsZSIsImxhYmVsIjoiRmlsZSJ9LHsidHlwZSI6Im51bWJlciIs ImlkIjoic3RhdHMveDI2NF9jb25zdHJhaW5lZF9oaWdoIiwibGFiZWwiOiJzdGF0cy94MjY0X2Nv bnN0cmFpbmVkX2hpZ2gifV19Cg0KZmlsZXN0YWJsZV9kcmF0ZVsxXT17InJvd3MiOlt7ImMiOlt7 InYiOiJkZXNrdG9wXzY0MF8zNjBfMzAifSx7InYiOjIwLjQzNjcyNDEzOTg2ODl9XX0seyJjIjpb eyJ2IjoiZ2lwc3JlY21vdGlvbl8xMjgwXzcyMF81MCJ9LHsidiI6MTkuMzcxNzE5OTY0OTE5NzF9 XX0seyJjIjpbeyJ2IjoiZ2lwc3JlY3N0YXRfMTI4MF83MjBfNTAifSx7InYiOjM3LjA0ODE1MTYy NDQzOTc1NH1dfSx7ImMiOlt7InYiOiJraXJsYW5kXzY0MF80ODBfMzAifSx7InYiOjUzLjU5MjIz MDAzMzgyNTY1fV19LHsiYyI6W3sidiI6Im1hY21hcmNvbW92aW5nXzY0MF80ODBfMzAifSx7InYi OjE5LjA4MjExOTk5NzQ1NDE1fV19LHsiYyI6W3sidiI6Im1hY21hcmNvc3RhdGlvbmFyeV82NDBf NDgwXzMwIn0seyJ2IjoyNy40MTkzMDY1MzQ1MDI4Mn1dfSx7ImMiOlt7InYiOiJuaWtsYXNfMTI4 MF83MjBfMzAifSx7InYiOjE2LjQ3NDI3NTc2NTM5MTczfV19LHsiYyI6W3sidiI6Im5pa2xhc182 NDBfNDgwXzMwIn0seyJ2IjoxMi40NzI4OTIxNjUyNDY0MDd9XX0seyJjIjpbeyJ2IjoidGFjb21h bmFycm93c182NDBfNDgwXzMwIn0seyJ2IjozOS45OTM3NjU1NTIxNDcxMX1dfSx7ImMiOlt7InYi OiJ0YWNvbWFzbWFsbGNhbWVyYW1vdmVtZW50XzY0MF80ODBfMzAifSx7InYiOjE1LjI4MjI0MzUw ODg0NTE3M31dfSx7ImMiOlt7InYiOiJ0aGFsb3VuZGVza210Z182NDBfNDgwXzMwIn0seyJ2Ijoz MS42MTY3NzQ2MDc1MjA1MjZ9XX0seyJjIjpbeyJ2IjoiT1ZFUkFMTCJ9LHsidiI6MjYuNjE3Mjkx MjYzMTA1NjN9XX1dLCJjb2xzIjpbeyJ0eXBlIjoic3RyaW5nIiwiaWQiOiJmaWxlIiwibGFiZWwi OiJGaWxlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy94MjY0X2NvbnN0cmFpbmVkX2hp Z2giLCJsYWJlbCI6InN0YXRzL3gyNjRfY29uc3RyYWluZWRfaGlnaCJ9XX0KDQpzbnJzWzFdID0g Wyd7InJvd3MiOlt7ImMiOlt7InYiOjE5My40N30sbnVsbCx7InYiOjMyLjYzfV19LHsiYyI6W3si diI6NDU3LjgxfSxudWxsLHsidiI6MzUuNzl9XX0seyJjIjpbeyJ2IjoxMTExLjQxfSxudWxsLHsi diI6MzkuMDE4fV19LHsiYyI6W3sidiI6MjY2OS44fSxudWxsLHsidiI6NDIuMTUzfV19LHsiYyI6 W3sidiI6NTEyLjA0fSx7InYiOjM1LjMyM30sbnVsbF19LHsiYyI6W3sidiI6OTM4LjUzfSx7InYi OjM3LjY5NH0sbnVsbF19LHsiYyI6W3sidiI6MTcwNy41OH0seyJ2IjozOS45Nn0sbnVsbF19LHsi YyI6W3sidiI6MzU0NC43M30seyJ2Ijo0Mi42NDF9LG51bGxdfV0sImNvbHMiOlt7InR5cGUiOiJu dW1iZXIiLCJpZCI6ImRhdGFyYXRlIiwibGFiZWwiOiJEYXRhcmF0ZSJ9LHsidHlwZSI6Im51bWJl ciIsImlkIjoic3RhdHMvdnA4IiwibGFiZWwiOiJzdGF0cy92cDgifSx7InR5cGUiOiJudW1iZXIi LCJpZCI6InN0YXRzL3gyNjRfY29uc3RyYWluZWRfaGlnaCIsImxhYmVsIjoic3RhdHMveDI2NF9j b25zdHJhaW5lZF9oaWdoIn1dfScsJ3sicm93cyI6W3siYyI6W3sidiI6NzQwLjUyfSxudWxsLHsi diI6MzUuMDMyfV19LHsiYyI6W3sidiI6MTM3OS45OX0sbnVsbCx7InYiOjM3LjkzMn1dfSx7ImMi Olt7InYiOjI5NDkuODh9LG51bGwseyJ2Ijo0MC44MDF9XX0seyJjIjpbeyJ2Ijo3Mzk1Ljl9LG51 bGwseyJ2Ijo0My41MzF9XX0seyJjIjpbeyJ2IjoxNTEyLjE1fSx7InYiOjM3LjQ1NX0sbnVsbF19 LHsiYyI6W3sidiI6MjU1NS41OX0seyJ2IjozOS42Nzd9LG51bGxdfSx7ImMiOlt7InYiOjQ4MTgu NTV9LHsidiI6NDEuODIzfSxudWxsXX0seyJjIjpbeyJ2IjoxMDM3MC41OH0seyJ2Ijo0My45ODJ9 LG51bGxdfV0sImNvbHMiOlt7InR5cGUiOiJudW1iZXIiLCJpZCI6ImRhdGFyYXRlIiwibGFiZWwi OiJEYXRhcmF0ZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvdnA4IiwibGFiZWwiOiJz dGF0cy92cDgifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3gyNjRfY29uc3RyYWluZWRf aGlnaCIsImxhYmVsIjoic3RhdHMveDI2NF9jb25zdHJhaW5lZF9oaWdoIn1dfScsJ3sicm93cyI6 W3siYyI6W3sidiI6MzMxLjQ4fSxudWxsLHsidiI6MzUuNTg2fV19LHsiYyI6W3sidiI6NjM0Ljh9 LG51bGwseyJ2IjozOC40MDV9XX0seyJjIjpbeyJ2IjoxNTE5LjQ0fSxudWxsLHsidiI6NDEuMTgy fV19LHsiYyI6W3sidiI6NDIzMi4wM30sbnVsbCx7InYiOjQzLjg0NX1dfSx7ImMiOlt7InYiOjg0 My40M30seyJ2IjozOC4wMjV9LG51bGxdfSx7ImMiOlt7InYiOjE0ODMuNDh9LHsidiI6NDAuMjE1 fSxudWxsXX0seyJjIjpbeyJ2IjozMDgwLjg0fSx7InYiOjQyLjI4OX0sbnVsbF19LHsiYyI6W3si diI6Njk3Ny42Mn0seyJ2Ijo0NC4yODl9LG51bGxdfV0sImNvbHMiOlt7InR5cGUiOiJudW1iZXIi LCJpZCI6ImRhdGFyYXRlIiwibGFiZWwiOiJEYXRhcmF0ZSJ9LHsidHlwZSI6Im51bWJlciIsImlk Ijoic3RhdHMvdnA4IiwibGFiZWwiOiJzdGF0cy92cDgifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6 InN0YXRzL3gyNjRfY29uc3RyYWluZWRfaGlnaCIsImxhYmVsIjoic3RhdHMveDI2NF9jb25zdHJh aW5lZF9oaWdoIn1dfScsJ3sicm93cyI6W3siYyI6W3sidiI6MzEuNjV9LG51bGwseyJ2IjozOS4z NDd9XX0seyJjIjpbeyJ2Ijo1My4yM30sbnVsbCx7InYiOjQxLjk4NH1dfSx7ImMiOlt7InYiOjEx NC4wM30sbnVsbCx7InYiOjQ0LjQ0fV19LHsiYyI6W3sidiI6MzUzLjUxfSxudWxsLHsidiI6NDYu NzE0fV19LHsiYyI6W3sidiI6NjkuNTV9LHsidiI6NDEuMTE3fSxudWxsXX0seyJjIjpbeyJ2Ijox MTEuNjd9LHsidiI6NDMuMDg2fSxudWxsXX0seyJjIjpbeyJ2IjoyMjEuMH0seyJ2Ijo0NS4wMTd9 LG51bGxdfSx7ImMiOlt7InYiOjU2Ny40NX0seyJ2Ijo0Ni45MDd9LG51bGxdfV0sImNvbHMiOlt7 InR5cGUiOiJudW1iZXIiLCJpZCI6ImRhdGFyYXRlIiwibGFiZWwiOiJEYXRhcmF0ZSJ9LHsidHlw ZSI6Im51bWJlciIsImlkIjoic3RhdHMvdnA4IiwibGFiZWwiOiJzdGF0cy92cDgifSx7InR5cGUi OiJudW1iZXIiLCJpZCI6InN0YXRzL3gyNjRfY29uc3RyYWluZWRfaGlnaCIsImxhYmVsIjoic3Rh dHMveDI2NF9jb25zdHJhaW5lZF9oaWdoIn1dfScsJ3sicm93cyI6W3siYyI6W3sidiI6MTI4LjEy fSxudWxsLHsidiI6MzUuNzI5fV19LHsiYyI6W3sidiI6MjI4Ljk1fSxudWxsLHsidiI6MzguMjY5 fV19LHsiYyI6W3sidiI6NTE0LjEzfSxudWxsLHsidiI6NDAuNjE5fV19LHsiYyI6W3sidiI6MTY2 OC42NH0sbnVsbCx7InYiOjQyLjk5Nn1dfSx7ImMiOlt7InYiOjI0NC40OH0seyJ2IjozOC4xMTV9 LG51bGxdfSx7ImMiOlt7InYiOjQzMi43OX0seyJ2IjozOS44NTN9LG51bGxdfSx7ImMiOlt7InYi Ojk3Mi4xM30seyJ2Ijo0MS41MDJ9LG51bGxdfSx7ImMiOlt7InYiOjI2ODQuNn0seyJ2Ijo0My41 OH0sbnVsbF19XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIsImlkIjoiZGF0YXJhdGUiLCJsYWJl bCI6IkRhdGFyYXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJsYWJlbCI6 InN0YXRzL3ZwOCJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMveDI2NF9jb25zdHJhaW5l ZF9oaWdoIiwibGFiZWwiOiJzdGF0cy94MjY0X2NvbnN0cmFpbmVkX2hpZ2gifV19JywneyJyb3dz IjpbeyJjIjpbeyJ2Ijo2MC42Mn0sbnVsbCx7InYiOjM1LjQ3NH1dfSx7ImMiOlt7InYiOjExNS4y M30sbnVsbCx7InYiOjM3LjU5M31dfSx7ImMiOlt7InYiOjM0OC43OX0sbnVsbCx7InYiOjM5Ljk0 OH1dfSx7ImMiOlt7InYiOjE0OTkuMTd9LG51bGwseyJ2Ijo0Mi41MzZ9XX0seyJjIjpbeyJ2Ijox MzcuM30seyJ2IjozNy41MjJ9LG51bGxdfSx7ImMiOlt7InYiOjI3Ny4xMX0seyJ2IjozOS4yMDh9 LG51bGxdfSx7ImMiOlt7InYiOjgwMS4xOH0seyJ2Ijo0MC44Nzd9LG51bGxdfSx7ImMiOlt7InYi OjI1NjYuOTN9LHsidiI6NDMuMTI2fSxudWxsXX1dLCJjb2xzIjpbeyJ0eXBlIjoibnVtYmVyIiwi aWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0YXJhdGUifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6 InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4In0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJz dGF0cy94MjY0X2NvbnN0cmFpbmVkX2hpZ2giLCJsYWJlbCI6InN0YXRzL3gyNjRfY29uc3RyYWlu ZWRfaGlnaCJ9XX0nLCd7InJvd3MiOlt7ImMiOlt7InYiOjQ3NC4wNX0sbnVsbCx7InYiOjM1Ljc3 NX1dfSx7ImMiOlt7InYiOjg2My42Mn0sbnVsbCx7InYiOjM4Ljc1NH1dfSx7ImMiOlt7InYiOjE4 NjUuODN9LG51bGwseyJ2Ijo0MS42NDZ9XX0seyJjIjpbeyJ2Ijo2NDA4LjM2fSxudWxsLHsidiI6 NDQuOTE2fV19LHsiYyI6W3sidiI6ODg5Ljc0fSx7InYiOjM4LjMxOH0sbnVsbF19LHsiYyI6W3si diI6MTQ5NS4yNH0seyJ2Ijo0MC41MzN9LG51bGxdfSx7ImMiOlt7InYiOjMwOTkuNzZ9LHsidiI6 NDIuNTY1fSxudWxsXX0seyJjIjpbeyJ2Ijo3ODUxLjUxfSx7InYiOjQ1LjA4fSxudWxsXX1dLCJj b2xzIjpbeyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0YXJhdGUi fSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4In0s eyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy94MjY0X2NvbnN0cmFpbmVkX2hpZ2giLCJsYWJl bCI6InN0YXRzL3gyNjRfY29uc3RyYWluZWRfaGlnaCJ9XX0nLCd7InJvd3MiOlt7ImMiOlt7InYi OjIwNS4wNX0sbnVsbCx7InYiOjMzLjk0MX1dfSx7ImMiOlt7InYiOjM3Ni4yN30sbnVsbCx7InYi OjM3LjEyOH1dfSx7ImMiOlt7InYiOjcxOS41fSxudWxsLHsidiI6NDAuNDA3fV19LHsiYyI6W3si diI6MTQ4My4zOX0sbnVsbCx7InYiOjQzLjZ9XX0seyJjIjpbeyJ2IjozODcuMzJ9LHsidiI6MzYu NjY3fSxudWxsXX0seyJjIjpbeyJ2Ijo2MjEuMjh9LHsidiI6MzkuMTM3fSxudWxsXX0seyJjIjpb eyJ2IjoxMDMyLjk2fSx7InYiOjQxLjU1Mn0sbnVsbF19LHsiYyI6W3sidiI6MjAyMy41N30seyJ2 Ijo0NC4yMDJ9LG51bGxdfV0sImNvbHMiOlt7InR5cGUiOiJudW1iZXIiLCJpZCI6ImRhdGFyYXRl IiwibGFiZWwiOiJEYXRhcmF0ZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvdnA4Iiwi bGFiZWwiOiJzdGF0cy92cDgifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3gyNjRfY29u c3RyYWluZWRfaGlnaCIsImxhYmVsIjoic3RhdHMveDI2NF9jb25zdHJhaW5lZF9oaWdoIn1dfScs J3sicm93cyI6W3siYyI6W3sidiI6MjUuMn0sbnVsbCx7InYiOjM3LjI4Mn1dfSx7ImMiOlt7InYi OjQxLjY5fSxudWxsLHsidiI6NDAuMDg4fV19LHsiYyI6W3sidiI6ODAuNDR9LG51bGwseyJ2Ijo0 Mi45MzJ9XX0seyJjIjpbeyJ2IjoyMjUuMDN9LG51bGwseyJ2Ijo0NS42MDR9XX0seyJjIjpbeyJ2 Ijo1My4zNn0seyJ2IjozOS40OTZ9LG51bGxdfSx7ImMiOlt7InYiOjc5Ljc2fSx7InYiOjQxLjcz fSxudWxsXX0seyJjIjpbeyJ2IjoxNTMuNDZ9LHsidiI6NDMuODQ4fSxudWxsXX0seyJjIjpbeyJ2 Ijo0MDkuMDh9LHsidiI6NDYuMDE1fSxudWxsXX1dLCJjb2xzIjpbeyJ0eXBlIjoibnVtYmVyIiwi aWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0YXJhdGUifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6 InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4In0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJz dGF0cy94MjY0X2NvbnN0cmFpbmVkX2hpZ2giLCJsYWJlbCI6InN0YXRzL3gyNjRfY29uc3RyYWlu ZWRfaGlnaCJ9XX0nLCd7InJvd3MiOlt7ImMiOlt7InYiOjc5LjY1fSxudWxsLHsidiI6MzUuMTIz fV19LHsiYyI6W3sidiI6MTUwLjY1fSxudWxsLHsidiI6MzguMTg1fV19LHsiYyI6W3sidiI6Mzkz LjU1fSxudWxsLHsidiI6NDEuNDU3fV19LHsiYyI6W3sidiI6MTEwMS4zfSxudWxsLHsidiI6NDQu NjR9XX0seyJjIjpbeyJ2IjoxNzQuOX0seyJ2IjozNy45NzJ9LG51bGxdfSx7ImMiOlt7InYiOjMy My45Nn0seyJ2Ijo0MC4zODl9LG51bGxdfSx7ImMiOlt7InYiOjY3Ni44OH0seyJ2Ijo0Mi43NTR9 LG51bGxdfSx7ImMiOlt7InYiOjE1NDQuODZ9LHsidiI6NDUuMjU2fSxudWxsXX1dLCJjb2xzIjpb eyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0YXJhdGUifSx7InR5 cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4In0seyJ0eXBl IjoibnVtYmVyIiwiaWQiOiJzdGF0cy94MjY0X2NvbnN0cmFpbmVkX2hpZ2giLCJsYWJlbCI6InN0 YXRzL3gyNjRfY29uc3RyYWluZWRfaGlnaCJ9XX0nLCd7InJvd3MiOlt7ImMiOlt7InYiOjk1LjUy fSxudWxsLHsidiI6MzIuMjExfV19LHsiYyI6W3sidiI6MTcyLjMzfSxudWxsLHsidiI6MzUuODcx fV19LHsiYyI6W3sidiI6MzQxLjQ4fSxudWxsLHsidiI6MzkuNTIyfV19LHsiYyI6W3sidiI6MTAy MS40M30sbnVsbCx7InYiOjQyLjk2OX1dfSx7ImMiOlt7InYiOjIwMC4yNX0seyJ2IjozNS4wNDZ9 LG51bGxdfSx7ImMiOlt7InYiOjMxMi4wMX0seyJ2IjozNy45MTV9LG51bGxdfSx7ImMiOlt7InYi OjYwOC4xNn0seyJ2Ijo0MC41Nn0sbnVsbF19LHsiYyI6W3sidiI6MTYyMS4xMn0seyJ2Ijo0My40 ODl9LG51bGxdfV0sImNvbHMiOlt7InR5cGUiOiJudW1iZXIiLCJpZCI6ImRhdGFyYXRlIiwibGFi ZWwiOiJEYXRhcmF0ZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvdnA4IiwibGFiZWwi OiJzdGF0cy92cDgifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3gyNjRfY29uc3RyYWlu ZWRfaGlnaCIsImxhYmVsIjoic3RhdHMveDI2NF9jb25zdHJhaW5lZF9oaWdoIn1dfScsXQoNCg0K dmFyIHNlbGVjdGVkID0gMA0KdmFyIGltYWdlc3RyID0gJyc7DQp2YXIgYmV0dGVydGFibGU9MDsN CnZhciBjaGFydD0wOw0KdmFyIGJldHRlcj0wOw0KdmFyIG1ldHJpY2RhdGE9MDsNCnZhciBtZXRy aWN2aWV3PTA7DQp2YXIgY29sdW1uPTE7DQp2YXIgZm9ybWF0dGVyPTA7DQoNCmZ1bmN0aW9uIGNo YW5nZUNvbHVtbihjb2wpIHsNCiAgY29sdW1uID0gY29sOw0KICBkcmF3X2ZpbGVzKCk7DQp9DQoN CmZ1bmN0aW9uIGNoYW5nZU1ldHJpYyhtKSB7DQogIGZ0YWJsZT1tDQogIGRyYXdfZmlsZXMoKQ0K fQ0KDQpmdW5jdGlvbiBzZXR1cF92aXMoKSB7DQogIGNoYXJ0ID0gbmV3IGdvb2dsZS52aXN1YWxp emF0aW9uLlNjYXR0ZXJDaGFydCgNCiAgICAgIGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJtZXRy aWNncmFwaCIpKTsNCg0KICBiZXR0ZXJ0YWJsZSA9IG5ldyBnb29nbGUudmlzdWFsaXphdGlvbi5U YWJsZSgNCiAgICAgIGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJiZXR0ZXJ0YWJsZSIpKTsNCg0K ICBkcmF3X2ZpbGVzKCk7DQp9DQoNCmZ1bmN0aW9uIGRyYXdfZmlsZXMoKSB7DQogIHZhciBjc3ND bGFzc05hbWVzID0gew0KICAgICAgJ2hlYWRlclJvdyc6ICdibHVlLWZvbnQgc21hbGwtZm9udCBi b2xkLWZvbnQgc21hbGwtbWFyZ2luJywNCiAgICAgICd0YWJsZVJvdyc6ICdzbWFsbC1mb250IHNt YWxsLW1hcmdpbicsDQogICAgICAnb2RkVGFibGVSb3cnOiAnbGlnaHQtZ3JheS1iYWNrZ3JvdW5k IHNtYWxsLWZvbnQgc21hbGwtbWFyZ2luJywNCiAgICAgICdzZWxlY3RlZFRhYmxlUm93JzogJ29y YW5nZS1iYWNrZ3JvdW5kIHNtYWxsLWZvbnQnLA0KICAgICAgJ2hvdmVyVGFibGVSb3cnOiAnc21h bGwtZm9udCBoZWFkZXItc3R5bGUnLA0KICAgICAgJ2hlYWRlckNlbGwnOiAnaGVhZGVyLXN0eWxl IHNtYWxsLW1hcmdpbicsDQogICAgICAndGFibGVDZWxsJzogJ3NtYWxsLW1hcmdpbid9Ow0KDQog IHZhciBvcHRpb25zID0geydhbGxvd0h0bWwnOiB0cnVlfTsNCiAgaWYgKGJldHRlciAhPSAwKSBk ZWxldGUgYmV0dGVyOw0KDQogIGNvbD1ldmFsKGZ0YWJsZSsnW2NvbHVtbl0nKQ0KICBiZXR0ZXIg PSBuZXcgZ29vZ2xlLnZpc3VhbGl6YXRpb24uRGF0YVRhYmxlKGNvbCkNCg0KICAvLyBQeXRob24g VGVtcGxhdGUgY29kZSByZXBsYWNlcyB0aGUgZm9sbG93aW5nIGxpbmUgd2l0aCBhIGxpc3Qgb2YN CiAgLy8gZm9ybWF0dGVycy4NCiAgaWYgKGZ0YWJsZSA9PSAnZmlsZXN0YWJsZV9kc25yJykNCiAg ICBmb3JtYXR0ZXIgPSBuZXcgZ29vZ2xlLnZpc3VhbGl6YXRpb24uTnVtYmVyRm9ybWF0KA0KICAg ICAge2ZyYWN0aW9uRGlnaXRzOiA0LCBzdWZmaXg6IiBkYiJ9KTsNCiAgZWxzZQ0KICAgIGZvcm1h dHRlciA9IG5ldyBnb29nbGUudmlzdWFsaXphdGlvbi5OdW1iZXJGb3JtYXQoDQogICAgICAge2Zy YWN0aW9uRGlnaXRzOiA0LCBzdWZmaXg6IiUifSk7DQoNCiAgICAgZm9ybWF0dGVyLmZvcm1hdChi ZXR0ZXIsIDEpOw0KDQogIGJldHRlcnRhYmxlLmRyYXcoYmV0dGVyLG9wdGlvbnMpOw0KICBnb29n bGUudmlzdWFsaXphdGlvbi5ldmVudHMuYWRkTGlzdGVuZXIoYmV0dGVydGFibGUsICdzZWxlY3Qn LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VsZWN0QmV0dGVy SGFuZGxlcik7DQogIHF1ZXJ5X2ZpbGUoKQ0KfQ0KDQpmdW5jdGlvbiBxdWVyeV9maWxlKCkgew0K ICBpbWFnZXN0ciA9IGJldHRlci5nZXRGb3JtYXR0ZWRWYWx1ZShzZWxlY3RlZCwgMCkNCiAgdmFy IG1ldHJpY2pzb24gPSBldmFsKCcoJyArIHNucnNbY29sdW1uXVtzZWxlY3RlZF0gKyAnKScpOw0K ICBtZXRyaWNkYXRhID0gbmV3IGdvb2dsZS52aXN1YWxpemF0aW9uLkRhdGFUYWJsZShtZXRyaWNq c29uLCAwLjYpOw0KICBpZiggbWV0cmljdmlldyAhPSAwICkgZGVsZXRlIG1ldHJpY3ZpZXc7DQog IG1ldHJpY3ZpZXcgPSBuZXcgZ29vZ2xlLnZpc3VhbGl6YXRpb24uRGF0YVZpZXcobWV0cmljZGF0 YSk7DQoNCiAgY2hhcnQuZHJhdyhtZXRyaWN2aWV3LCB7Y3VydmVUeXBlOidmdW5jdGlvbicsDQog ICAgICBjaGFydEFyZWE6e2xlZnQ6Y2hhcnRfbGVmdCwgdG9wOmNoYXJ0X3RvcCwgd2lkdGg6Y2hh cnRfd2lkdGgsDQogICAgICBoZWlnaHQ6Y2hhcnRfaGVpZ2h0LTkwfSwNCiAgICAgIGhBeGlzOnt0 aXRsZToiZGF0YXJhdGUgaW4ga2JwcyJ9LCB2QXhpczp7dGl0bGU6InF1YWxpdHkgaW4gZGVjaWJl bHMifSwNCiAgICAgIGxlZ2VuZDp7cG9zaXRpb246ImluIn0sIHRpdGxlOmltYWdlc3RyLCBwb2lu dFNpemU6MiwgbGluZVdpZHRoOjEsDQogICAgICB3aWR0aDpjaGFydF93aWR0aCwgaGVpZ2h0OmNo YXJ0X2hlaWdodC01MCB9KTsNCg0KICBnb29nbGUudmlzdWFsaXphdGlvbi5ldmVudHMuYWRkTGlz dGVuZXIoY2hhcnQsICdzZWxlY3QnLCBjaGFydFNlbGVjdCk7DQogIGdvb2dsZS52aXN1YWxpemF0 aW9uLmV2ZW50cy5hZGRMaXN0ZW5lcihjaGFydCwgJ29ubW91c2VvdmVyJywgY2hhcnRNb3VzZU92 ZXIpOw0KICBnb29nbGUudmlzdWFsaXphdGlvbi5ldmVudHMuYWRkTGlzdGVuZXIoY2hhcnQsICdv bm1vdXNlb3V0JywgY2hhcnRNb3VzZU91dCk7DQp9DQoNCmZ1bmN0aW9uIGNoYXJ0TW91c2VPdXQo ZSkgew0KICBzdGF0dXNiYXIgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgnc3RhdHVzJyk7DQog IHN0YXR1c2Jhci5zdHlsZS5kaXNwbGF5ID0gJ25vbmUnOw0KfQ0KDQpmdW5jdGlvbiBjaGFydE1v dXNlT3ZlcihlKSB7DQogIHBvaW50RGlmZmVyZW5jZShlLnJvdywgZS5jb2x1bW4pDQp9DQoNCmZ1 bmN0aW9uIHBvaW50RGlmZmVyZW5jZShyb3csIGNvbCkgew0KICBpZighcm93IHx8ICFjb2wpDQog ICAgcmV0dXJuOw0KDQogIHZhciBjb2xzID0gbWV0cmljZGF0YS5nZXROdW1iZXJPZkNvbHVtbnMo KTsNCiAgdmFyIHJvd3MgPSBtZXRyaWNkYXRhLmdldE51bWJlck9mUm93cygpOw0KDQogIHZhciBz ZWxfYml0cmF0ZSA9IG1ldHJpY3ZpZXcuZ2V0VmFsdWUocm93LCAwICk7DQogIHZhciBzZWxfbWV0 cmljID0gbWV0cmljdmlldy5nZXRWYWx1ZShyb3csIGNvbCk7DQoNCiAgdmFyIG1lc3NhZ2UgPSAi QXQgIiArIHNlbF9tZXRyaWMudG9GaXhlZCgyKSArICIgZGVjaWJlbHMsIDxlbT4iDQogIG1lc3Nh Z2UgPSBtZXNzYWdlICsgbWV0cmljZGF0YS5nZXRDb2x1bW5MYWJlbChjb2wpICsgIjwvZW0+IGlz IDx1bD4iDQoNCiAgLy8gY29sIDAgaXMgZGF0YXJhdGUNCiAgZm9yKCB2YXIgaT0xO2k8Y29sczsr K2kpIHsNCg0KICAgIHZhciBtZXRyaWNfZ3JlYXRlc3RfdGhhdHNfbGVzcyA9IDA7DQogICAgdmFy IHJhdGVfZ3JlYXRlc3RfdGhhdHNfbGVzcyA9IDA7DQogICAgdmFyIG1ldHJpY19zbWFsbGVzdF90 aGF0c19ncmVhdGVyID0gOTk5Ow0KICAgIHZhciByYXRlX3NtYWxsZXN0X3RoYXRzX2dyZWF0ZXIg PSAwOw0KDQogICAgaWYoaT09Y29sKQ0KICAgICAgY29udGludWU7DQoNCiAgICAvLyBGaW5kIHRo ZSBsb3dlc3QgbWV0cmljIGZvciB0aGUgY29sdW1uIHRoYXQncyBncmVhdGVyIHRoYW4gc2VsX21l dHJpYyBhbmQNCiAgICAvLyB0aGUgaGlnaGVzdCBtZXRyaWMgZm9yIHRoaXMgY29sdW1uIHRoYXQn cyBsZXNzIHRoYW4gdGhlIG1ldHJpYy4NCiAgICBmb3IodmFyIGxpbmVfY291bnQgPSAwOyBsaW5l X2NvdW50IDwgcm93czsgKytsaW5lX2NvdW50KSB7DQogICAgICB0aGlzX21ldHJpYyA9IG1ldHJp Y2RhdGEuZ2V0VmFsdWUobGluZV9jb3VudCwgaSkNCiAgICAgIHRoaXNfcmF0ZSA9IG1ldHJpY2Rh dGEuZ2V0VmFsdWUobGluZV9jb3VudCwgMCkNCiAgICAgIGlmKCF0aGlzX21ldHJpYykNCiAgICAg ICAgY29udGludWU7DQoNCiAgICAgIGlmKHRoaXNfbWV0cmljID4gbWV0cmljX2dyZWF0ZXN0X3Ro YXRzX2xlc3MgJiYNCiAgICAgICAgIHRoaXNfbWV0cmljIDwgc2VsX21ldHJpYykgew0KICAgICAg ICBtZXRyaWNfZ3JlYXRlc3RfdGhhdHNfbGVzcyA9IHRoaXNfbWV0cmljOw0KICAgICAgICByYXRl X2dyZWF0ZXN0X3RoYXRzX2xlc3MgPSB0aGlzX3JhdGU7DQogICAgICB9DQogICAgICBpZih0aGlz X21ldHJpYyA8IG1ldHJpY19zbWFsbGVzdF90aGF0c19ncmVhdGVyICYmDQogICAgICAgIHRoaXNf bWV0cmljID4gc2VsX21ldHJpYykgew0KICAgICAgICBtZXRyaWNfc21hbGxlc3RfdGhhdHNfZ3Jl YXRlciA9IHRoaXNfbWV0cmljOw0KICAgICAgICByYXRlX3NtYWxsZXN0X3RoYXRzX2dyZWF0ZXIg PSB0aGlzX3JhdGU7DQogICAgICB9DQogICAgfQ0KDQogICAgaWYocmF0ZV9zbWFsbGVzdF90aGF0 c19ncmVhdGVyID09IDAgfHwgcmF0ZV9ncmVhdGVzdF90aGF0c19sZXNzID09IDApIHsNCiAgICAg IG1lc3NhZ2UgPSBtZXNzYWdlICsgIiA8bGk+IENvdWxkbid0IGZpbmQgYSBwb2ludCBvbiBib3Ro IHNpZGVzLjwvbGk+Ig0KICAgIH0gZWxzZSB7DQogICAgICBtZXRyaWNfc2xvcGUgPSAoIHJhdGVf c21hbGxlc3RfdGhhdHNfZ3JlYXRlciAtIHJhdGVfZ3JlYXRlc3RfdGhhdHNfbGVzcykgLw0KICAg ICAgICAgICggbWV0cmljX3NtYWxsZXN0X3RoYXRzX2dyZWF0ZXIgLSBtZXRyaWNfZ3JlYXRlc3Rf dGhhdHNfbGVzcyk7DQoNCiAgICAgIHByb2plY3RlZF9yYXRlID0gKCBzZWxfbWV0cmljIC0gbWV0 cmljX2dyZWF0ZXN0X3RoYXRzX2xlc3MpICoNCiAgICAgICAgICBtZXRyaWNfc2xvcGUgKyByYXRl X2dyZWF0ZXN0X3RoYXRzX2xlc3M7DQoNCiAgICAgIGRpZmZlcmVuY2UgPSAxMDAgKiAocHJvamVj dGVkX3JhdGUgLyBzZWxfYml0cmF0ZSAtIDEpOw0KDQoNCiAgICAgIGlmIChkaWZmZXJlbmNlID4g MCkNCiAgICAgICAgbWVzc2FnZSA9IG1lc3NhZ2UgKyAiPGxpPiAgIiArIGRpZmZlcmVuY2UudG9G aXhlZCgyKSArDQogICAgICAgICAgICAgICAgICAiJSBzbWFsbGVyIHRoYW4gPGVtPiIgKw0KICAg ICAgICAgICAgICAgICAgbWV0cmljZGF0YS5nZXRDb2x1bW5MYWJlbChpKSArICI8L2VtPjwvbGk+ ICINCiAgICAgIGVsc2UNCiAgICAgICAgbWVzc2FnZSA9IG1lc3NhZ2UgKyAiPGxpPiAgIiArIC1k aWZmZXJlbmNlLnRvRml4ZWQoMikgKw0KICAgICAgICAgICAgICAgICAgIiUgYmlnZ2VyIHRoYW4g PGVtPiIgKw0KICAgICAgICAgICAgICAgICAgbWV0cmljZGF0YS5nZXRDb2x1bW5MYWJlbChpKSAr ICI8L2VtPjwvbGk+ICINCiAgICB9DQoNCiAgfQ0KICBtZXNzYWdlID0gbWVzc2FnZSArICI8L3Vs PiINCiAgc3RhdHVzYmFyID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ3N0YXR1cycpOw0KICBz dGF0dXNiYXIuaW5uZXJIVE1MID0gIjxwPiIgKyBtZXNzYWdlICsgIjwvcD4iOw0KICBzdGF0dXNi YXIuc3R5bGUuZGlzcGxheSA9ICdibG9jayc7DQp9DQoNCmZ1bmN0aW9uIGNoYXJ0U2VsZWN0KCkg ew0KICB2YXIgc2VsZWN0aW9uID0gY2hhcnQuZ2V0U2VsZWN0aW9uKCk7DQogIHZhciBtZXNzYWdl ID0gJyc7DQogIHZhciBtaW4gPSBtZXRyaWN2aWV3LmdldEZvcm1hdHRlZFZhbHVlKHNlbGVjdGlv blswXS5yb3csIDApOw0KICB2YXIgbWF4ID0gbWV0cmljdmlldy5nZXRGb3JtYXR0ZWRWYWx1ZShz ZWxlY3Rpb25bc2VsZWN0aW9uLmxlbmd0aC0xXS5yb3csIDApOw0KICB2YXIgdmFsID0gbWV0cmlj dmlldy5nZXRGb3JtYXR0ZWRWYWx1ZShzZWxlY3Rpb25bMF0ucm93LHNlbGVjdGlvblswXS5jb2x1 bW4pOw0KDQogIHBvaW50RGlmZmVyZW5jZShzZWxlY3Rpb25bMF0ucm93LCBzZWxlY3Rpb25bMF0u Y29sdW1uKQ0KICBtaW4gPSBtaW4gLyAzDQogIG1heCA9IG1heCAqIDMNCiAgbWV0cmljdmlldy5z ZXRSb3dzKG1ldHJpY2RhdGEuZ2V0RmlsdGVyZWRSb3dzKA0KICAgICAgW3tjb2x1bW46IDAsbWlu VmFsdWU6IG1pbiwgbWF4VmFsdWU6bWF4fV0pKTsNCg0KICBjaGFydC5kcmF3KG1ldHJpY3ZpZXcs IHtjdXJ2ZVR5cGU6J2Z1bmN0aW9uJywNCiAgICAgIGNoYXJ0QXJlYTp7bGVmdDo0MCwgdG9wOjEw LCB3aWR0aDpjaGFydF93aWR0aCwgaGVpZ2h0OmNoYXJ0X2hlaWdodCAtIDExMH0sDQogICAgICBo QXhpczp7dGl0bGU6ImRhdGFyYXRlIGluIGticHMifSwgdkF4aXM6e3RpdGxlOiJxdWFsaXR5IGlu IGRlY2liZWxzIn0sDQogICAgICBsZWdlbmQ6e3Bvc2l0aW9uOiJpbiJ9LCB0aXRsZTppbWFnZXN0 ciwgcG9pbnRTaXplOjIsIGxpbmVXaWR0aDoxLA0KICAgICAgd2lkdGg6Y2hhcnRfd2lkdGgsIGhl aWdodDpjaGFydF9oZWlnaHQgLSA1MH0pOw0KfQ0KDQpmdW5jdGlvbiBzZWxlY3RCZXR0ZXJIYW5k bGVyKCkgew0KICB2YXIgc2VsZWN0aW9uID0gYmV0dGVydGFibGUuZ2V0U2VsZWN0aW9uKCk7DQog IGZvciAodmFyIGkgPSAwOyBpIDwgc2VsZWN0aW9uLmxlbmd0aDsgaSsrKSB7DQogICAgaXRlbSA9 IHNlbGVjdGlvbltpXTsNCiAgfQ0KICBzZWxlY3RlZCA9IGl0ZW0ucm93DQogIHF1ZXJ5X2ZpbGUo KQ0KfQ0KDQpnb29nbGUubG9hZCgndmlzdWFsaXphdGlvbicsICcxJywgeydwYWNrYWdlcycgOiBb J2NvcmVjaGFydCcsJ3RhYmxlJ119KTsNCmdvb2dsZS5zZXRPbkxvYWRDYWxsYmFjayhzZXR1cF92 aXMpOw0KPC9zY3JpcHQ+DQo8L2hlYWQ+DQoNCjxib2R5Pg0KDQogIDxkaXYgY2xhc3M9ImNvbnRh aW5lcl8xMiI+DQoNCiAgICA8ZGl2IGNsYXNzPSJncmlkXzEyIGhlYWRlciI+DQogICAgICA8aDI+ VlA4IFJlc3VsdHM8L2gyPg0KICAgIDwvZGl2Pg0KDQogICAgPGRpdiBjbGFzcz0iZ3JpZF8xMiBy YWRpbyI+DQoNCiAgICA8ZGl2IGNsYXNzPSJncmlkXzEyIG1haW4iPg0KDQogICAgICA8ZGl2IGNs YXNzPSJncmlkXzUgYWxwaGEgY2xpcGxpc3QiPg0KICAgICAgICA8ZGl2IGlkPSJiZXR0ZXJ0YWJs ZSI+PC9kaXY+DQogICAgICA8L2Rpdj4NCg0KICAgICAgPGRpdiBjbGFzcz0iZ3JpZF81IGNoYXJ0 YXJlYSI+DQogICAgICAgIDxkaXYgaWQ9Im1ldHJpY2dyYXBoIj48L2Rpdj4NCiAgICAgIDwvZGl2 Pg0KDQogICAgICA8ZGl2IGNsYXNzPSJncmlkXzIgb21lZ2EgaW5kaWNhdG9ycyI+DQogICAgICAg IDxkaXYgY2xhc3M9ImNvbnRlbnQiPg0KICAgICAgICAgIDxoNT5JbmRpY2F0b3JzPC9oNT4NCiAg ICAgICAgICA8aHI+DQogICAgICAgICAgPGRpdiBpZD0ic3RhdHVzIj48L2Rpdj4NCiAgICAgICAg PC9kaXY+DQogICAgICA8L2Rpdj4NCg0KICAgIDwvZGl2Pg0KDQogIDwvZGl2Pg0KDQo8L2JvZHk+ DQo8L2h0bWw+DQoK --_006_BBE9739C2C302046BD34B42713A1E2A22DECC12FESESSMB105erics_-- From lgeyser@gmail.com Sat Jun 22 09:54:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B597311E810C for ; Sat, 22 Jun 2013 09:54:27 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX8xef6dyn5N for ; Sat, 22 Jun 2013 09:54:26 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 806A611E810B for ; Sat, 22 Jun 2013 09:54:22 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ec20so8505709lab.41 for ; Sat, 22 Jun 2013 09:54: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=AQwII1HxNERAkb93TryJPpUiFiwJ3hFwCOzmVyXdnVg=; b=XC+6OAFGmjITRei0f7UbdggvgFg9LNxMnDnDjeSJFDrI6/H6iXsYPo6M0FjZJWJMpI HyuF/6Q2Ha3L6uqh8o+rF41gLPSiTu5CD3YiNhV0agCO0vE5natr5tHnaI76QX0s/+N6 Uz8+s78BGbEJZEpx67h+o3HryjCvB/X4Uz3QFfDk4sPGJMm7/6kB4F8rulEB+fsKsOgX l5TUKPmiNMoSgneePBDvL83wBXEEi/4KU2KL81xUL22bJ9iH9f5DpK3OWgyVTonwsphf lgQU9WBTQTeI+/IJMIQVVPgzuON8/lKpz9+Y8lO00vI6vWxQOa1kcXXoXmsuY59nCja0 soDw== MIME-Version: 1.0 X-Received: by 10.152.20.136 with SMTP id n8mr8103208lae.58.1371920061098; Sat, 22 Jun 2013 09:54:21 -0700 (PDT) Received: by 10.114.174.201 with HTTP; Sat, 22 Jun 2013 09:54:21 -0700 (PDT) In-Reply-To: References: Date: Sat, 22 Jun 2013 18:54:21 +0200 Message-ID: From: Leon Geyser To: Bo Burman Content-Type: multipart/alternative; boundary=089e01493e2ee6ed9904dfc107df Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Jun 2013 16:54:27 -0000 --089e01493e2ee6ed9904dfc107df Content-Type: text/plain; charset=ISO-8859-1 Hi Bo, Thanks for the additional testing done. I am not 100% why we have to test with fixed qp-levels when WebRTC is going to be used over the internet. I would assume that WebRTC would be used over the internet... My understanding of rate-control might be completely wrong. Why test modes that might not even be used in real-world scenarios? On 22 June 2013 15:41, Bo Burman wrote: > Hi all, > > We have had a look at Google's comparison between VP8 and H.264 > constrained baseline that was posted on April 3rd ( > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07028.html). This > post contains, as the one mentioned above (and if the attachments make it > to the list), information on the exact tools and options used for encoding > and should thus be repeatable by anyone interested. > > As was already stated by others on this list, one major problem is that > Google's test involves the rate control mechanism. Typically codecs are > measured with rate control turned off, since it acts as a huge noise on the > measurement. Instead we propose to compare the codecs using fixed > qp-levels. The qp-level is the quantization parameter that affects the > rate/distortion tradeoff. Comparing using fixed qp-levels is what has been > used when benchmarking HEVC against H.264 in the JCT-VC standardization, > for instance. We are going to select a codec (essentially bit stream > format), not a rate control mechanism: Once the codec is selected you can > choose whatever rate control mechanism you wish. > > We used Google's excellent framework as the baseline and changed the > parameter settings in order to make it possible to measure using fixed qp. > We used the same sequences, but limited them to the first 10 seconds since > they varied from 10 seconds to minutes; this also eased computation time. > > We used two H.264 encoder implementations: X264, which is an open-source > codec that can operate in everything from real-time to slow, and JM which > is the reference implementation that was used to develop H.264. JM is very > slow but attempts to be very efficient in terms of bits per quality. The > results were as follows: > > X264 baseline vs VP8: H.264 wins with 1% > JM baseline vs VP8: H.264 wins with 4% > > Running times: > X264: 1 hour 3 minutes > VP8: 2 hours 0 minutes > JM: order of magnitude slower > > It is interesting to note that the measurements are more stable in the new > test; the variance of the percentages for the sequences is now around 70, > down from around 700 in Google's test of April 3rd. We believe this is due > to the removal of the rate controller, which acts like noise on the > measurements. > > We also tried setting H.264 to constrained high (no interlace and no > B-pictures, compared to high). The results were then: > > X264 constrained high vs VP8: H.264 wins with 25% > JM constrained high vs VP8: H.264 wins with 24% > > We also note that the script that Google provided to calculate the rate > differences ("BD-rate") does not give exactly the same numbers as the > JCT-VC-way of calculating BD-rate. The main difference is that the JM score > for constrained high is better (around 29%) if the JCT-VC way of > calculating BD-rate is used. > > In summary we think that proper testing can conclude that there is no > clear performance advantage to any codec between VP8 and H.264 baseline. > When comparing VP8 against H.264 constrained high on the other hand, it > seems like there is an advantage for H.264 constrained high. > > The attached file includes the files necessary to reproduce the test. > > Best Regards, > > Bo Burman > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e01493e2ee6ed9904dfc107df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Bo,

    Thanks for the additional testing done.

    I am not 100% = why we have to test with fixed qp-levels when WebRTC is going to be used ov= er the internet. I would assume that WebRTC would be used over the internet= ...
    My understanding of rate-control might be completely wrong. Why test modes = that might not even be used in real-world scenarios?

    On 22 June 2013 15:41, Bo Burman <bo.burman@ericsson.com= > wrote:
    Hi all,

    We have had a look at Google's comparison between VP8 and H.264 constra= ined baseline that was posted on April 3rd (http://www= .ietf.org/mail-archive/web/rtcweb/current/msg07028.html). This post con= tains, as the one mentioned above (and if the attachments make it to the li= st), information on the exact tools and options used for encoding and shoul= d thus be repeatable by anyone interested.

    As was already stated by others on this list, one major problem is that Goo= gle's test involves the rate control mechanism. Typically codecs are me= asured with rate control turned off, since it acts as a huge noise on the m= easurement. Instead we propose to compare the codecs using fixed qp-levels.= The qp-level is the quantization parameter that affects the rate/distortio= n tradeoff. Comparing using fixed qp-levels is what has been used when benc= hmarking HEVC against H.264 in the JCT-VC standardization, for instance. We= are going to select a codec (essentially bit stream format), not a rate co= ntrol mechanism: Once the codec is selected you can choose whatever rate co= ntrol mechanism you wish.

    We used Google's excellent framework as the baseline and changed the pa= rameter settings in order to make it possible to measure using fixed qp. We= used the same sequences, but limited them to the first 10 seconds since th= ey varied from 10 seconds to minutes; this also eased computation time.

    We used two H.264 encoder implementations: X264, which is an open-source co= dec that can operate in everything from real-time to slow, and JM which is = the reference implementation that was used to develop H.264. JM is very slo= w but attempts to be very efficient in terms of bits per quality. The resul= ts were as follows:

    X264 baseline vs VP8: H.264 wins with 1%
    JM baseline vs VP8: H.264 wins with 4%

    Running times:
    X264: 1 hour 3 minutes
    VP8: 2 hours 0 minutes
    JM: order of magnitude slower

    It is interesting to note that the measurements are more stable in the new = test; the variance of the percentages for the sequences is now around 70, d= own from around 700 in Google's test of April 3rd. =A0We believe this i= s due to the removal of the rate controller, which acts like noise on the m= easurements.

    We also tried setting H.264 to constrained high (no interlace and no B-pict= ures, compared to high). The results were then:

    X264 constrained high vs VP8: H.264 wins with 25%
    JM constrained high vs VP8: H.264 wins with 24%

    We also note that the script that Google provided to calculate the rate dif= ferences ("BD-rate") does not give exactly the same numbers as th= e JCT-VC-way of calculating BD-rate. The main difference is that the JM sco= re for constrained high is better (around 29%) if the JCT-VC way of calcula= ting BD-rate is used.

    In summary we think that proper testing can conclude that there is no clear= performance advantage to any codec between VP8 and H.264 baseline. When co= mparing VP8 against H.264 constrained high on the other hand, it seems like= there is an advantage for H.264 constrained high.

    The attached file includes the files necessary to reproduce the test.

    Best Regards,

    Bo Burman


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


    --089e01493e2ee6ed9904dfc107df-- From mail@makk.es Sun Jun 23 05:52:03 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D946B21F9D4E for ; Sun, 23 Jun 2013 05:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_111=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+jwsGuSOoyT for ; Sun, 23 Jun 2013 05:51:57 -0700 (PDT) Received: from lupus.uberspace.de (lupus.uberspace.de [95.143.172.176]) by ietfa.amsl.com (Postfix) with SMTP id 6341F21F99D3 for ; Sun, 23 Jun 2013 05:51:56 -0700 (PDT) Received: (qmail 23314 invoked from network); 23 Jun 2013 12:51:53 -0000 Received: from unknown (HELO ?192.168.0.20?) (31.18.98.41) by lupus.uberspace.de with SMTP; 23 Jun 2013 12:51:53 -0000 Message-ID: <51C6EF5F.60405@makk.es> Date: Sun, 23 Jun 2013 14:51:43 +0200 From: Max Jonas Werner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dan Wing References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> <529DCF4E-2A8B-475F-8CCE-7E2ABC72EFB1@oracle.com> <2C6DDF0C-201D-4CA3-8EB0-F14B8A2D5758@cisco.com> In-Reply-To: <2C6DDF0C-201D-4CA3-8EB0-F14B8A2D5758@cisco.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2CTQQXMSFJXNRAFXNORFN" Cc: "" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Jun 2013 12:52:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2CTQQXMSFJXNRAFXNORFN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 21.06.2013 18:45, Dan Wing wrote: > On Jun 20, 2013, at 7:58 PM, Hadriel Kaplan = wrote: [...] >> We've talked about that one before I think. If jQuery is out to >> get you, it's game over. It's essentially equivalent to a >> malicious web-server, except of course that the operator of the >> web-server isn't intending to be malicious (which is an important >> distinction). But again, not only does jQuery have access to >> information such as who you're talking to and when, it can also >> redirect your media to a gateway of its choosing to terminate the >> DTLS-SRTP and record it, by fiddling with the JSON/SDP stuff. >=20 > For the attacker to succeed with the redirection of DTLS-SRTP to a > server it controls, the attacker would also need to modify the SDP's > a=3Dfingerprint line which is as trivial as the attacker's other SDP > modifications. To prevent the attacker from succeeding with such > modification, we need cryptographic identity (to protect the > From/To/Date/a=3Dfingerprint and other fields), and need the browser > (not JS) to verify the identity using an external service (e.g., > local disk, IdP separate from the web server providing us the > (compromised) JS and the SDP). While it is true that today we don't > have a way today to provide that cryptographic identity (RFC4474 does > not work, draft-wing-rtcweb-identity-media written by me and Hadriel > was met with silence) DTLS-SRTP creates the foundation to build > cryptographic identity which can be verified by the browser itself. > Such cryptographic identity protects from this specific attack, and > DTLS-SRTP protects from other attacks. draft-ietf-rtcweb-security-arch-06, section 5.6 talks quite clearly about verifying peer identities (without concentrating on a signalling protocol like SIP) so if you would want to have secure communication (even with a signalling server you don't trust) _and_ verified peers a combination of DTLS-SRTP and the mentioned peer authentication mechanism in draft-ietf-rtcweb-security-arch-06 would be a must. As far as I understand it, SDES cannot provide the same level of end-to-end security under the assumption that you don't trust the signalling server. Max ------enig2CTQQXMSFJXNRAFXNORFN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFRxu9n1IVn4/X13N8RAolNAJ9F+jLXTRFsohx369jIjDPPN1sLgACgqX4o AQi5uCwS4+/+8cSCePUI6bE= =mmjs -----END PGP SIGNATURE----- ------enig2CTQQXMSFJXNRAFXNORFN-- From martin.thomson@gmail.com Sun Jun 23 20:02:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B6D21E8084 for ; Sun, 23 Jun 2013 20:02: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.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8upHNVX5oOs for ; Sun, 23 Jun 2013 20:02:29 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8BC21E808D for ; Sun, 23 Jun 2013 20:02:28 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so7925470wev.0 for ; Sun, 23 Jun 2013 20:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b9Rx6//UR48GmxoO0yhsQoy3zoa9/Ol6lK/eTtNuoRA=; b=0cXyPoNI0M2YGCoA5/C0GNLYxcGN3+TxDjjW5UZtkVFyEmfbphQbPhWM4av35O2833 +JVoZ2ZhfMdvIj86/0+jzJ6Adcw804IgXdvrUhe6M6Vo4V7QV1tr1n/OcV6KGMBMhInZ tM0ibZAJsf3eDz1hpFCfuA8OI0GM/q1xFK42q9RLj9zY/rjlc0eJoOLLxBADbGs7gdOG gFdDxUmqQ3C50huTdpkURBC5C03Z98JcUkWF66648f5ez6KZMFklY/+n0I78lPkZQBma UeprrR4VC+XAXWC5rriTR1G9gLNPfI873iW/j23beaYDk/WygegJJZaJkdrpoee2p2QP BMNA== MIME-Version: 1.0 X-Received: by 10.180.9.212 with SMTP id c20mr4604808wib.65.1372042948211; Sun, 23 Jun 2013 20:02:28 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Sun, 23 Jun 2013 20:02:27 -0700 (PDT) In-Reply-To: References: <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <51C3209B.1030501@alvestrand.no> <51C335F9.4000900@alvestrand.no> <51C38356.3020402@jitsi.org> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> <9F33F40F6F2CD847824537F3C4E37DDF115D4A59@MCHP04MSX.global-ad.net> <4337C1D6-5D1E-4316-A96B-E6FBA2E647E7@siemens-enterprise.com> <51C48F4A.9070707@hookflash.com> Date: Sun, 23 Jun 2013 20:02:27 -0700 Message-ID: From: Martin Thomson To: Silvia Pfeiffer Content-Type: multipart/alternative; boundary=001a11c1879c8b774b04dfdda4ae Cc: diopmamadou@doubango.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 03:02:29 -0000 --001a11c1879c8b774b04dfdda4ae Content-Type: text/plain; charset=UTF-8 On 21 June 2013 16:54, Silvia Pfeiffer wrote: > Is it possible to continue using SDP but not do o/a ? Strictly speaking: yes. In practice, however, some of the features that we use depend on definitions that are only valid in the offer/answer context. This includes security features. Fixing that is possible, but it's easier to avoid SDP altogether. Because it's just not that hard to design an API without it. --001a11c1879c8b774b04dfdda4ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On 2= 1 June 2013 16:54, Silvia Pfeiffer <silviapfeiffer1@gmail.com&= gt; wrote:
    Is it possible to continue using SDP but not= do o/a ?

    Strictly s= peaking: yes.=C2=A0 In practice, however, some of the features that we use = depend on definitions that are only valid in the offer/answer context.=C2= =A0 This includes security features.

    Fixing that is possible, but it's = easier to avoid SDP altogether.=C2=A0 Because it's just not that hard t= o design an API without it.
    --001a11c1879c8b774b04dfdda4ae-- From stefan.lk.hakansson@ericsson.com Mon Jun 24 04:33:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E90921F9C0B for ; Mon, 24 Jun 2013 04:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.584 X-Spam-Level: X-Spam-Status: No, score=-5.584 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sORKefC8B6jJ for ; Mon, 24 Jun 2013 04:33:24 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DFE2221E80DC for ; Mon, 24 Jun 2013 04:33:23 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-26-51c82e822bec Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 70.23.18006.28E28C15; Mon, 24 Jun 2013 13:33:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Mon, 24 Jun 2013 13:33:22 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Leon Geyser Thread-Topic: [rtcweb] More H.264 vs VP8 tests Thread-Index: Ac5vQ4bE4hnmu5ERSv6YOg93i7vBVw== Date: Mon, 24 Jun 2013 11:33:21 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3020B6@ESESSMB209.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvrW6T3olAgx2XTCy6V89is1j7r53d gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4ubui4IdRxbnmNsYGxgfqXYycHBICJhIb /7xjg7DFJC7cWw9kc3EICRxmlNj+YCYzhLOIUeLE5xYWkCo2gUCJrfsWgHWICChLfPy2Bcxm FvCWWN89B6xGWEBXouH4GqgaPYmFz1+wwNi7939kBrFZBFQlZn58xdjFyMHBK+Ar8eW2KMSu KYwSty7OZAWpYQS66PupNUwQ88Ulbj2ZzwRxqYDEkj3nmSFsUYmXj/+xQtiKEjvPtjND1OtJ 3Jg6Beo2bYllC1+DxXkFBCVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjOy5iZk56eVGmxiB sXBwy2/VHYx3zokcYpTmYFES5/14alegkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkZDLdFb Eb2+lYZSaxWvJl01S9J/0t8jYdbVofJ+1pQM92CvZ41vzZ7unPVbxI0z+6qNo/RPo6o1u9cF 1ddUspndvD/1SU/ODw+ZzjJ94V3C34NvX//hrL3Lz/iUXvbhUHunE2E6kir7lqyftpc3a4bB wbwr+c3Gwd8OnRAr62tiKxZQFKibr8RSnJFoqMVcVJwIAKGxTsxTAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 11:33:29 -0000 On 2013-06-22 18:54, Leon Geyser wrote:=0A= > Hi Bo,=0A= >=0A= > Thanks for the additional testing done.=0A= >=0A= > I am not 100% why we have to test with fixed qp-levels when WebRTC is=0A= > going to be used over the internet. I would assume that WebRTC would be= =0A= > used over the internet...=0A= > My understanding of rate-control might be completely wrong. Why test=0A= > modes that might not even be used in real-world scenarios?=0A= =0A= Hi Leon (responding for Bo who is enjoying his vacation),=0A= =0A= you are absolutely right, these codecs are going to be used with =0A= rate-controllers when deployed in the real world. However, we still do =0A= not think it is a good idea having rate control turned on when comparing = =0A= them. The reason is that the rate controller influences the quality so =0A= much that it is very hard to get any comparable signal if you include =0A= them. Let me give you one example; let's say that you use the same =0A= codec, but two different rate controllers. Rate control A is very =0A= liberal with its bits in the beginning of the sequence, whereas rate =0A= control B is very frugal. On a video conferencing type sequence, where =0A= the camera is static and not much is happening, rate control A will win =0A= by a huge margin over rate control B. The reason is that the first frame = =0A= will be encoded very well and this data can be used during the remainder = =0A= of the sequence. Rate control B will not be able to stand a chance, even = =0A= though it has more bits for the remaining images. And this is with the =0A= same video codec!=0A= =0A= We could of course try to make sure that the two rate controllers have =0A= similar settings; however, since they are not identical they cannot be =0A= made to work exactly the same. Even small changes in rate control =0A= settings could have a huge effect on the end result.=0A= =0A= Rather than trying to make two pieces of software work the same, it is =0A= much easier to just shut off the rate controllers. This gives a direct =0A= measurement of the relative strengths of the codecs. This is also the =0A= reason why organizations such as JC-TVC have used this method to compare = =0A= their codecs.=0A= =0A= Best Regards,=0A= Stefan=0A= =0A= =0A= >=0A= > On 22 June 2013 15:41, Bo Burman > wrote:=0A= >=0A= > Hi all,=0A= >=0A= > We have had a look at Google's comparison between VP8 and H.264=0A= > constrained baseline that was posted on April 3rd=0A= > (http://www.ietf.org/mail-archive/web/rtcweb/current/msg07028.html).= =0A= > This post contains, as the one mentioned above (and if the=0A= > attachments make it to the list), information on the exact tools and= =0A= > options used for encoding and should thus be repeatable by anyone=0A= > interested.=0A= >=0A= > As was already stated by others on this list, one major problem is=0A= > that Google's test involves the rate control mechanism. Typically=0A= > codecs are measured with rate control turned off, since it acts as a= =0A= > huge noise on the measurement. Instead we propose to compare the=0A= > codecs using fixed qp-levels. The qp-level is the quantization=0A= > parameter that affects the rate/distortion tradeoff. Comparing using= =0A= > fixed qp-levels is what has been used when benchmarking HEVC against= =0A= > H.264 in the JCT-VC standardization, for instance. We are going to=0A= > select a codec (essentially bit stream format), not a rate control=0A= > mechanism: Once the codec is selected you can choose whatever rate=0A= > control mechanism you wish.=0A= >=0A= > We used Google's excellent framework as the baseline and changed the= =0A= > parameter settings in order to make it possible to measure using=0A= > fixed qp. We used the same sequences, but limited them to the first= =0A= > 10 seconds since they varied from 10 seconds to minutes; this also=0A= > eased computation time.=0A= >=0A= > We used two H.264 encoder implementations: X264, which is an=0A= > open-source codec that can operate in everything from real-time to=0A= > slow, and JM which is the reference implementation that was used to= =0A= > develop H.264. JM is very slow but attempts to be very efficient in= =0A= > terms of bits per quality. The results were as follows:=0A= >=0A= > X264 baseline vs VP8: H.264 wins with 1%=0A= > JM baseline vs VP8: H.264 wins with 4%=0A= >=0A= > Running times:=0A= > X264: 1 hour 3 minutes=0A= > VP8: 2 hours 0 minutes=0A= > JM: order of magnitude slower=0A= >=0A= > It is interesting to note that the measurements are more stable in=0A= > the new test; the variance of the percentages for the sequences is=0A= > now around 70, down from around 700 in Google's test of April 3rd.=0A= > We believe this is due to the removal of the rate controller,=0A= > which acts like noise on the measurements.=0A= >=0A= > We also tried setting H.264 to constrained high (no interlace and no= =0A= > B-pictures, compared to high). The results were then:=0A= >=0A= > X264 constrained high vs VP8: H.264 wins with 25%=0A= > JM constrained high vs VP8: H.264 wins with 24%=0A= >=0A= > We also note that the script that Google provided to calculate the=0A= > rate differences ("BD-rate") does not give exactly the same numbers= =0A= > as the JCT-VC-way of calculating BD-rate. The main difference is=0A= > that the JM score for constrained high is better (around 29%) if the= =0A= > JCT-VC way of calculating BD-rate is used.=0A= >=0A= > In summary we think that proper testing can conclude that there is=0A= > no clear performance advantage to any codec between VP8 and H.264=0A= > baseline. When comparing VP8 against H.264 constrained high on the=0A= > other hand, it seems like there is an advantage for H.264=0A= > constrained high.=0A= >=0A= > The attached file includes the files necessary to reproduce the test.= =0A= >=0A= > Best Regards,=0A= >=0A= > Bo Burman=0A= >=0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org =0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= >=0A= =0A= From harald@alvestrand.no Mon Jun 24 15:00:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B66C21E810C for ; Mon, 24 Jun 2013 15:00:01 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYa1S5edB3ob for ; Mon, 24 Jun 2013 14:59:54 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EFFC011E818C for ; Mon, 24 Jun 2013 14:59:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B476439E12F for ; Mon, 24 Jun 2013 23:59:52 +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 jQ5caegeIzBj for ; Mon, 24 Jun 2013 23:59:51 +0200 (CEST) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8775539E095 for ; Mon, 24 Jun 2013 23:59:51 +0200 (CEST) Message-ID: <51C8C16B.4070405@alvestrand.no> Date: Tue, 25 Jun 2013 00:00:11 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1447FA0C20ED5147A1AA0EF02890A64B1C3020B6@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C3020B6@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 22:00:02 -0000 First of all, Bo, thanks for running the tests, and for making the results fully open! On 06/24/2013 01:33 PM, Stefan Håkansson LK wrote: > On 2013-06-22 18:54, Leon Geyser wrote: >> Hi Bo, >> >> Thanks for the additional testing done. >> >> I am not 100% why we have to test with fixed qp-levels when WebRTC is >> going to be used over the internet. I would assume that WebRTC would be >> used over the internet... >> My understanding of rate-control might be completely wrong. Why test >> modes that might not even be used in real-world scenarios? > Hi Leon (responding for Bo who is enjoying his vacation), > > you are absolutely right, these codecs are going to be used with > rate-controllers when deployed in the real world. However, we still do > not think it is a good idea having rate control turned on when comparing > them. The reason is that the rate controller influences the quality so > much that it is very hard to get any comparable signal if you include > them. Let me give you one example; let's say that you use the same > codec, but two different rate controllers. Rate control A is very > liberal with its bits in the beginning of the sequence, whereas rate > control B is very frugal. On a video conferencing type sequence, where > the camera is static and not much is happening, rate control A will win > by a huge margin over rate control B. The reason is that the first frame > will be encoded very well and this data can be used during the remainder > of the sequence. Rate control B will not be able to stand a chance, even > though it has more bits for the remaining images. And this is with the > same video codec! This would seem to me to be an argument for including the rate control.... what we are looking for is the codec where people can demonstrate the best performance for our specific situations, not the codec that is best able to fulfil a set of conditions that are inappropriate for Real Life. For the example you give, the bit division between the I-frame/key-frame and the subsequent frames is not just influenced by the chosen Q value - it's also influenced by codec design. What will happen in a video conference scenario if someone uses this rate packing too much is that the I-frame takes a long time to transmit, because the available bit rate is in the ramp-up phase; if we wanted to make realistic scenario settings, we should probably draw constraints around the delay in delivering the second frame under specified bandwidth conditions. But on the other hand, people may find a delay to the second frame quite acceptable, and your "rate control A" is indeed the one that is most reasonable to use. > > We could of course try to make sure that the two rate controllers have > similar settings; however, since they are not identical they cannot be > made to work exactly the same. Even small changes in rate control > settings could have a huge effect on the end result. > > Rather than trying to make two pieces of software work the same, it is > much easier to just shut off the rate controllers. This gives a direct > measurement of the relative strengths of the codecs. This is also the > reason why organizations such as JC-TVC have used this method to compare > their codecs. And it's going to be discussed there.... I'll be late for the Berlin IETF meeting because I have to be at the MPEG meeting in Vienna to present Google's formal submission of VP8 to MPEG. The use or non-use of variable QP will probably be an item of debate .... again. The IETF has not started down the path of defining test conditions under which it wishes to measure codec performance; I think we do have rough consensus that the technical differences are not so great as to make a decisive difference between the proposed codecs - while the IPR differences are all too well known to us, and do matter enough to make a decisive difference to a lot of us. Harald From harald@alvestrand.no Tue Jun 25 03:17:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCD621F9E43 for ; Tue, 25 Jun 2013 03:17:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAbcaHgaXcrK for ; Tue, 25 Jun 2013 03:17:09 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0F021F90CD for ; Tue, 25 Jun 2013 03:17:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 490A439E11A; Tue, 25 Jun 2013 12:17: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 Hh8hGuqVZhpr; Tue, 25 Jun 2013 12:17:06 +0200 (CEST) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9327039E0D7; Tue, 25 Jun 2013 12:17:06 +0200 (CEST) Message-ID: <51C96E36.2000907@alvestrand.no> Date: Tue, 25 Jun 2013 12:17:26 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bo Burman References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080906090504050407010800" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 10:17:14 -0000 This is a multi-part message in MIME format. --------------080906090504050407010800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Again - thanks for releasing this openly! I ran the scripts (with a few tweaks; you run on a system where sh is bash, not dash, for instance), and got the same numbers within +/- 0.5% (probably some binary version skew); we may have disagreements on the parameters to use, but we agree on the numbers those parameters produce. (I have since modified the Google framework to include a script that pulls in the sources for the needed binaries and compiles them - if you want to make 100% sure people are working from the same sources, you may want to rebase to a newer version of the comparision toolkit.) On 06/22/2013 03:41 PM, Bo Burman wrote: > Hi all, > > We have had a look at Google's comparison between VP8 and H.264 constrained baseline that was posted on April 3rd (http://www.ietf.org/mail-archive/web/rtcweb/current/msg07028.html). This post contains, as the one mentioned above (and if the attachments make it to the list), information on the exact tools and options used for encoding and should thus be repeatable by anyone interested. > > As was already stated by others on this list, one major problem is that Google's test involves the rate control mechanism. Typically codecs are measured with rate control turned off, since it acts as a huge noise on the measurement. Instead we propose to compare the codecs using fixed qp-levels. The qp-level is the quantization parameter that affects the rate/distortion tradeoff. Comparing using fixed qp-levels is what has been used when benchmarking HEVC against H.264 in the JCT-VC standardization, for instance. We are going to select a codec (essentially bit stream format), not a rate control mechanism: Once the codec is selected you can choose whatever rate control mechanism you wish. > > We used Google's excellent framework as the baseline and changed the parameter settings in order to make it possible to measure using fixed qp. We used the same sequences, but limited them to the first 10 seconds since they varied from 10 seconds to minutes; this also eased computation time. > > We used two H.264 encoder implementations: X264, which is an open-source codec that can operate in everything from real-time to slow, and JM which is the reference implementation that was used to develop H.264. JM is very slow but attempts to be very efficient in terms of bits per quality. The results were as follows: > > X264 baseline vs VP8: H.264 wins with 1% > JM baseline vs VP8: H.264 wins with 4% > > Running times: > X264: 1 hour 3 minutes > VP8: 2 hours 0 minutes > JM: order of magnitude slower > > It is interesting to note that the measurements are more stable in the new test; the variance of the percentages for the sequences is now around 70, down from around 700 in Google's test of April 3rd. We believe this is due to the removal of the rate controller, which acts like noise on the measurements. > > We also tried setting H.264 to constrained high (no interlace and no B-pictures, compared to high). The results were then: > > X264 constrained high vs VP8: H.264 wins with 25% > JM constrained high vs VP8: H.264 wins with 24% > > We also note that the script that Google provided to calculate the rate differences ("BD-rate") does not give exactly the same numbers as the JCT-VC-way of calculating BD-rate. The main difference is that the JM score for constrained high is better (around 29%) if the JCT-VC way of calculating BD-rate is used. > > In summary we think that proper testing can conclude that there is no clear performance advantage to any codec between VP8 and H.264 baseline. When comparing VP8 against H.264 constrained high on the other hand, it seems like there is an advantage for H.264 constrained high. > > The attached file includes the files necessary to reproduce the test. > > Best Regards, > > Bo Burman > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------080906090504050407010800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    Again - thanks for releasing this openly!

    I ran the scripts (with a few tweaks; you run on a system where sh is bash, not dash, for instance), and got the same numbers within +/- 0.5% (probably some binary version skew); we may have disagreements on the parameters to use, but we agree on the numbers those parameters produce.

    (I have since modified the Google framework to include a script that pulls in the sources for the needed binaries and compiles them - if you want to make 100% sure people are working from the same sources, you may want to rebase to a newer version of the comparision toolkit.)

    On 06/22/2013 03:41 PM, Bo Burman wrote:
    Hi all, 

We have had a look at Google's comparison between VP8 and H.264 constrained baseline that was posted on April 3rd (http://www.ietf.org/mail-archive/web/rtcweb/current/msg07028.html). This post contains, as the one mentioned above (and if the attachments make it to the list), information on the exact tools and options used for encoding and should thus be repeatable by anyone interested.

As was already stated by others on this list, one major problem is that Google's test involves the rate control mechanism. Typically codecs are measured with rate control turned off, since it acts as a huge noise on the measurement. Instead we propose to compare the codecs using fixed qp-levels. The qp-level is the quantization parameter that affects the rate/distortion tradeoff. Comparing using fixed qp-levels is what has been used when benchmarking HEVC against H.264 in the JCT-VC standardization, for instance. We are going to select a codec (essentially bit stream format), not a rate control mechanism: Once the codec is selected you can choose whatever rate control mechanism you wish.

We used Google's excellent framework as the baseline and changed the parameter settings in order to make it possible to measure using fixed qp. We used the same sequences, but limited them to the first 10 seconds since they varied from 10 seconds to minutes; this also eased computation time.

We used two H.264 encoder implementations: X264, which is an open-source codec that can operate in everything from real-time to slow, and JM which is the reference implementation that was used to develop H.264. JM is very slow but attempts to be very efficient in terms of bits per quality. The results were as follows:

X264 baseline vs VP8: H.264 wins with 1%
JM baseline vs VP8: H.264 wins with 4%

Running times: 
X264: 1 hour 3 minutes
VP8: 2 hours 0 minutes
JM: order of magnitude slower

It is interesting to note that the measurements are more stable in the new test; the variance of the percentages for the sequences is now around 70, down from around 700 in Google's test of April 3rd.  We believe this is due to the removal of the rate controller, which acts like noise on the measurements. 

We also tried setting H.264 to constrained high (no interlace and no B-pictures, compared to high). The results were then:

X264 constrained high vs VP8: H.264 wins with 25%
JM constrained high vs VP8: H.264 wins with 24%

We also note that the script that Google provided to calculate the rate differences ("BD-rate") does not give exactly the same numbers as the JCT-VC-way of calculating BD-rate. The main difference is that the JM score for constrained high is better (around 29%) if the JCT-VC way of calculating BD-rate is used. 

In summary we think that proper testing can conclude that there is no clear performance advantage to any codec between VP8 and H.264 baseline. When comparing VP8 against H.264 constrained high on the other hand, it seems like there is an advantage for H.264 constrained high.

The attached file includes the files necessary to reproduce the test.

Best Regards,

Bo Burman



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

    --------------080906090504050407010800-- From stefan.lk.hakansson@ericsson.com Tue Jun 25 07:56:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECBD21F9B06 for ; Tue, 25 Jun 2013 07:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.82 X-Spam-Level: X-Spam-Status: No, score=-3.82 tagged_above=-999 required=5 tests=[AWL=-1.521, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8unK7xP12yN for ; Tue, 25 Jun 2013 07:56:47 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1466211E8132 for ; Tue, 25 Jun 2013 07:56:42 -0700 (PDT) X-AuditID: c1b4fb38-b7f476d0000049c9-bf-51c9af9fe7ba Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 8A.4F.18889.F9FA9C15; Tue, 25 Jun 2013 16:56:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Tue, 25 Jun 2013 16:56:31 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Harald Alvestrand Thread-Topic: [rtcweb] More H.264 vs VP8 tests Thread-Index: Ac5vQ4bE4hnmu5ERSv6YOg93i7vBVw== Date: Tue, 25 Jun 2013 14:56:30 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C302C38@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C3020B6@ESESSMB209.ericsson.se> <51C8C16B.4070405@alvestrand.no> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+Jvre6C9ScDDZasZLI41tfFZrH2Xzu7 A5PHlQlXWD2WLPnJFMAUxWWTkpqTWZZapG+XwJVx4uxWxoKVWhVTOv6zNDB+Vexi5OSQEDCR WNv8gBnCFpO4cG89WxcjF4eQwFFGibfLVzCCJIQEFjFKnGpQBbHZBAIltu5bwAZiiwjoSDzc 38AEYjMLqEvcWXyOHcQWFtCVaDi+BqpGT2Lh8xcsMPbu/R/BlrEIqEq0PbwOFucV8JX4vbGT HWLxb0aJ3rk3wAYxAl30/dQaqAXiEreezGeCuFRAYsme81BXi0q8fPyPFcJWlNh5tp0Zol5P 4sbUKWwQtrbEsoWvmSGWCUqcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGDmKU4uTctONDDYx AuPh4JbfFjsYL/+1OcQozcGiJM776dSuQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MzLbP Vs/M+L7A9r+BTr+mx5bil9M3rHPO/rZP5Lwdx8+8XYpsPh+bWVosVp1tXK3EvXPrw/6G/Jx9 6rudfkRtqFwQIrl/wdP4A9N0zhqmv3FMsF7nvvVmYcbSh9W1To0RXkK8mpsD2I/Yli7bOJc9 Xq2oRm6Wnnska2v5DdkNgn4ijm9mOPxTYinOSDTUYi4qTgQAkcNmrVUCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:56:52 -0000 On 2013-06-25 00:00, Harald Alvestrand wrote:=0A= > First of all, Bo, thanks for running the tests, and for making the=0A= > results fully open!=0A= >=0A= > On 06/24/2013 01:33 PM, Stefan H=E5kansson LK wrote:=0A= >> On 2013-06-22 18:54, Leon Geyser wrote:=0A= >>> Hi Bo,=0A= >>>=0A= >>> Thanks for the additional testing done.=0A= >>>=0A= >>> I am not 100% why we have to test with fixed qp-levels when WebRTC is= =0A= >>> going to be used over the internet. I would assume that WebRTC would be= =0A= >>> used over the internet...=0A= >>> My understanding of rate-control might be completely wrong. Why test=0A= >>> modes that might not even be used in real-world scenarios?=0A= >> Hi Leon (responding for Bo who is enjoying his vacation),=0A= >>=0A= >> you are absolutely right, these codecs are going to be used with=0A= >> rate-controllers when deployed in the real world. However, we still do= =0A= >> not think it is a good idea having rate control turned on when comparing= =0A= >> them. The reason is that the rate controller influences the quality so= =0A= >> much that it is very hard to get any comparable signal if you include=0A= >> them. Let me give you one example; let's say that you use the same=0A= >> codec, but two different rate controllers. Rate control A is very=0A= >> liberal with its bits in the beginning of the sequence, whereas rate=0A= >> control B is very frugal. On a video conferencing type sequence, where= =0A= >> the camera is static and not much is happening, rate control A will win= =0A= >> by a huge margin over rate control B. The reason is that the first frame= =0A= >> will be encoded very well and this data can be used during the remainder= =0A= >> of the sequence. Rate control B will not be able to stand a chance, even= =0A= >> though it has more bits for the remaining images. And this is with the= =0A= >> same video codec!=0A= >=0A= > This would seem to me to be an argument for including the rate=0A= > control.... what we are looking for is the codec where people can=0A= > demonstrate the best performance for our specific situations, not the=0A= > codec that is best able to fulfil a set of conditions that are=0A= > inappropriate for Real Life.=0A= >=0A= > For the example you give, the bit division between the I-frame/key-frame= =0A= > and the subsequent frames is not just influenced by the chosen Q value -= =0A= > it's also influenced by codec design.=0A= >=0A= > What will happen in a video conference scenario if someone uses this=0A= > rate packing too much is that the I-frame takes a long time to transmit,= =0A= > because the available bit rate is in the ramp-up phase; if we wanted to= =0A= > make realistic scenario settings, we should probably draw constraints=0A= > around the delay in delivering the second frame under specified=0A= > bandwidth conditions.=0A= >=0A= > But on the other hand, people may find a delay to the second frame quite= =0A= > acceptable, and your "rate control A" is indeed the one that is most=0A= > reasonable to use.=0A= =0A= I think that the rate control should be omitted from this kind of =0A= comparisons since it adds a lot of noise to the results and since - as =0A= far as I have understood - the rate controller is rather independent of =0A= the codec (you could use very similar rate controllers for VP8 and h.264).= =0A= =0A= But I agree to the main point you make further below, so perhaps this is = =0A= a debate that can be saved for another discussion.=0A= =0A= >=0A= >>=0A= >> We could of course try to make sure that the two rate controllers have= =0A= >> similar settings; however, since they are not identical they cannot be= =0A= >> made to work exactly the same. Even small changes in rate control=0A= >> settings could have a huge effect on the end result.=0A= >>=0A= >> Rather than trying to make two pieces of software work the same, it is= =0A= >> much easier to just shut off the rate controllers. This gives a direct= =0A= >> measurement of the relative strengths of the codecs. This is also the=0A= >> reason why organizations such as JC-TVC have used this method to compare= =0A= >> their codecs.=0A= >=0A= > And it's going to be discussed there.... I'll be late for the Berlin=0A= > IETF meeting because I have to be at the MPEG meeting in Vienna to=0A= > present Google's formal submission of VP8 to MPEG. The use or non-use of= =0A= > variable QP will probably be an item of debate .... again.=0A= >=0A= > The IETF has not started down the path of defining test conditions under= =0A= > which it wishes to measure codec performance; I think we do have rough=0A= > consensus that the technical differences are not so great as to make a=0A= > decisive difference between the proposed codecs - while the IPR=0A= > differences are all too well known to us, and do matter enough to make a= =0A= > decisive difference to a lot of us.=0A= =0A= I agree, and our tests underline, that the performance differences are =0A= not so great as to make any decisive difference between the VP8 and =0A= h.264 baseline - their performance is very similar.=0A= =0A= >=0A= > Harald=0A= >=0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From stefan.lk.hakansson@ericsson.com Tue Jun 25 07:59:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344C121F9B3E for ; Tue, 25 Jun 2013 07:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.428 X-Spam-Level: X-Spam-Status: No, score=-5.428 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svZ2myW1CPZ7 for ; Tue, 25 Jun 2013 07:59:36 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D701211E810F for ; Tue, 25 Jun 2013 07:59:31 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d000001cf9-3c-51c9b0529e2e Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 45.F2.07417.250B9C15; Tue, 25 Jun 2013 16:59:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Tue, 25 Jun 2013 16:59:30 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Harald Alvestrand Thread-Topic: [rtcweb] More H.264 vs VP8 tests Thread-Index: Ac5vQ4bE4hnmu5ERSv6YOg93i7vBVw== Date: Tue, 25 Jun 2013 14:59:30 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C302C4E@ESESSMB209.ericsson.se> References: <51C96E36.2000907@alvestrand.no> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+JvrW7QhpOBBlNPKlsc6+tis1j7r53d gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq48WIFU8EBlYqby5rZGxivynYxcnJICJhI TDt9hxnCFpO4cG89WxcjF4eQwGFGiUdT9kM5ixgllnR+ZwOpYhMIlNi6bwGYLSKgI/FwfwMT iM0s4C2xvnsOC4gtLKAr0XB8DVSNnsTC5y9YYOzd+z+CbWMRUJU4s6sLrIZXwFfi/Yk2VhBb SKBAYuqmLWAzGYEu+n5qDdR8cYlbT+YzQVwqILFkz3moq0UlXj7+xwphK0rsPNvODFGvJ3Fj 6hQ2CFtbYtnC18wQuwQlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzsuYmZOenl5psYgdFw cMtvgx2Mm+6LHWKU5mBREuf9dGpXoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGSX+Utmxj 4S1a7/tL2uXT/JrJugabD3yW6Fj3zkWMuS801vHViS8S8v1m29NTF3eLqPxterCL6dE57U1c Aotqah1EP/69kDK5NvbI/G23Z66+2PJu7ZPalIV2xTN3H0k8dmjn6aqwF5VJZrLpDOmChi+V WX40q95a1Na8tZ7F//Sa0qj5Z/QPKrEUZyQaajEXFScCAEJJRTBUAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:59:46 -0000 On 2013-06-25 12:17, Harald Alvestrand wrote:=0A= > Again - thanks for releasing this openly!=0A= >=0A= > I ran the scripts (with a few tweaks; you run on a system where sh is=0A= > bash, not dash, for instance), and got the same numbers within +/- 0.5%= =0A= > (probably some binary version skew); we may have disagreements on the=0A= > parameters to use, but we agree on the numbers those parameters produce.= =0A= =0A= Great. We spent quite some time trying to find the best parameter =0A= settings, but it is quite complex and we may have missed something - =0A= feedback is welcome.=0A= =0A= >=0A= > (I have since modified the Google framework to include a script that=0A= > pulls in the sources for the needed binaries and compiles them - if you= =0A= > want to make 100% sure people are working from the same sources, you may= =0A= > want to rebase to a newer version of the comparision toolkit.)=0A= =0A= We'll look into that.=0A= =0A= >=0A= > On 06/22/2013 03:41 PM, Bo Burman wrote:=0A= >> Hi all,=0A= >>=0A= >> We have had a look at Google's comparison between VP8 and H.264 constrai= ned baseline that was posted on April 3rd (http://www.ietf.org/mail-archive= /web/rtcweb/current/msg07028.html). This post contains, as the one mentione= d above (and if the attachments make it to the list), information on the ex= act tools and options used for encoding and should thus be repeatable by an= yone interested.=0A= >>=0A= >> As was already stated by others on this list, one major problem is that = Google's test involves the rate control mechanism. Typically codecs are mea= sured with rate control turned off, since it acts as a huge noise on the me= asurement. Instead we propose to compare the codecs using fixed qp-levels. = The qp-level is the quantization parameter that affects the rate/distortion= tradeoff. Comparing using fixed qp-levels is what has been used when bench= marking HEVC against H.264 in the JCT-VC standardization, for instance. We = are going to select a codec (essentially bit stream format), not a rate con= trol mechanism: Once the codec is selected you can choose whatever rate con= trol mechanism you wish.=0A= >>=0A= >> We used Google's excellent framework as the baseline and changed the par= ameter settings in order to make it possible to measure using fixed qp. We = used the same sequences, but limited them to the first 10 seconds since the= y varied from 10 seconds to minutes; this also eased computation time.=0A= >>=0A= >> We used two H.264 encoder implementations: X264, which is an open-source= codec that can operate in everything from real-time to slow, and JM which = is the reference implementation that was used to develop H.264. JM is very = slow but attempts to be very efficient in terms of bits per quality. The re= sults were as follows:=0A= >>=0A= >> X264 baseline vs VP8: H.264 wins with 1%=0A= >> JM baseline vs VP8: H.264 wins with 4%=0A= >>=0A= >> Running times:=0A= >> X264: 1 hour 3 minutes=0A= >> VP8: 2 hours 0 minutes=0A= >> JM: order of magnitude slower=0A= >>=0A= >> It is interesting to note that the measurements are more stable in the n= ew test; the variance of the percentages for the sequences is now around 70= , down from around 700 in Google's test of April 3rd. We believe this is d= ue to the removal of the rate controller, which acts like noise on the meas= urements.=0A= >>=0A= >> We also tried setting H.264 to constrained high (no interlace and no B-p= ictures, compared to high). The results were then:=0A= >>=0A= >> X264 constrained high vs VP8: H.264 wins with 25%=0A= >> JM constrained high vs VP8: H.264 wins with 24%=0A= >>=0A= >> We also note that the script that Google provided to calculate the rate = differences ("BD-rate") does not give exactly the same numbers as the JCT-V= C-way of calculating BD-rate. The main difference is that the JM score for = constrained high is better (around 29%) if the JCT-VC way of calculating BD= -rate is used.=0A= >>=0A= >> In summary we think that proper testing can conclude that there is no cl= ear performance advantage to any codec between VP8 and H.264 baseline. When= comparing VP8 against H.264 constrained high on the other hand, it seems l= ike there is an advantage for H.264 constrained high.=0A= >>=0A= >> The attached file includes the files necessary to reproduce the test.=0A= >>=0A= >> Best Regards,=0A= >>=0A= >> Bo Burman=0A= >>=0A= >>=0A= >> _______________________________________________=0A= >> rtcweb mailing list=0A= >> rtcweb@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From jkoleszar@google.com Tue Jun 25 08:36:21 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7914821E8091 for ; Tue, 25 Jun 2013 08:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhTwe8m4UmZx for ; Tue, 25 Jun 2013 08:36:21 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8B02511E80F2 for ; Tue, 25 Jun 2013 08:36:20 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so894706wiv.15 for ; Tue, 25 Jun 2013 08:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uBTwR+bnwE/irK59ws0bVwd6cnD2skW5s9eVm3hOPCU=; b=piWEswf8OplNY0kqcibJbn3xjjaPdlnTpTYK4iReemKz/FdjEpOMTIVBb8Bzahcb5T /Ge3xvAJTA8XFfWD97upMegt1PcpKbsQ2JbCpi/aFJ140bOdilLwd5YYlITv7ebWhJ/t +HYuVyBm5aQdDn+wY5wau+XLBXDD+ltRuYSvssdFUbpbn5ojFHOiMVwwZAv2nqBD8H7M hlO0TV9iVOdOJXj/JSe1Qn6stvEuRnpmkXI0+qNovCXx2Fk1zK4ZZ70NwxTeXSu2Rvt6 W4dgRa5uJtZA0UCqSmbPMwpNiIj/Cpb8IFf++W77cLV5XJtmX0EOxbVky9r9bO6I54UC DhBA== 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:content-transfer-encoding:x-gm-message-state; bh=uBTwR+bnwE/irK59ws0bVwd6cnD2skW5s9eVm3hOPCU=; b=Aex74bV/wRhk4VadCDpe5oWD6KBUn8ppUxOE5i0aJiWiVWcJ3I4L8o7brOmO3miXE2 Es932Wy6cEpVHCELWMrkz0kZvuk5uonbOKjNbYCcjrwrvdHq89qlgeGpqoMqiyig8EYy zY450LWrpu2YPyW58SWk3kW9O+aOGwDCJnLjJk/n4hqcaZrbILF/5PXVgxyEXQ28RNq/ 9Yvo8x50zYnAolG1VJ0LHi9e68bYQT/A4HoZkxLJ/10kMUzwII8O2UcqROuCh0LzGCQJ dUiKrO2J6xwQnHJ1Wnl7MX6dCXOr842SVIAaVzOnFaTjwMFCGDTr61QwP0rD1KPXzJJx KgVQ== MIME-Version: 1.0 X-Received: by 10.180.77.74 with SMTP id q10mr9504235wiw.28.1372174578409; Tue, 25 Jun 2013 08:36:18 -0700 (PDT) Received: by 10.194.138.148 with HTTP; Tue, 25 Jun 2013 08:36:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Jun 2013 08:36:18 -0700 Message-ID: From: John Koleszar To: Bo Burman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmnDfR8HIPhImjJkDnIKEBPWTy1egEZ2/uTsLRo8p9kp9q+muRC3m4V2c1ijAd7FXd/3UW2lBW5EOCFCWcHDtfm6WwqdYD3r7Z1dJTYHQki2cvwHGbyIHgNDRtHgryZXu20xj073mjZiv3rKhylKuVWrtvfd6epXo+kqdtTakC6UoRXuPe4tSUGZnrV63+KYe78WENU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:36:21 -0000 On Sat, Jun 22, 2013 at 6:41 AM, Bo Burman wrote: > Hi all, > > We have had a look at Google's comparison between VP8 and H.264 constrain= ed baseline that was posted on April 3rd (http://www.ietf.org/mail-archive/= web/rtcweb/current/msg07028.html). This post contains, as the one mentioned= above (and if the attachments make it to the list), information on the exa= ct tools and options used for encoding and should thus be repeatable by any= one interested. > > As was already stated by others on this list, one major problem is that G= oogle's test involves the rate control mechanism. Typically codecs are meas= ured with rate control turned off, since it acts as a huge noise on the mea= surement. Instead we propose to compare the codecs using fixed qp-levels. T= he qp-level is the quantization parameter that affects the rate/distortion = tradeoff. Comparing using fixed qp-levels is what has been used when benchm= arking HEVC against H.264 in the JCT-VC standardization, for instance. We a= re going to select a codec (essentially bit stream format), not a rate cont= rol mechanism: Once the codec is selected you can choose whatever rate cont= rol mechanism you wish. > > We used Google's excellent framework as the baseline and changed the para= meter settings in order to make it possible to measure using fixed qp. We u= sed the same sequences, but limited them to the first 10 seconds since they= varied from 10 seconds to minutes; this also eased computation time. > > We used two H.264 encoder implementations: X264, which is an open-source = codec that can operate in everything from real-time to slow, and JM which i= s the reference implementation that was used to develop H.264. JM is very s= low but attempts to be very efficient in terms of bits per quality. The res= ults were as follows: > > X264 baseline vs VP8: H.264 wins with 1% > JM baseline vs VP8: H.264 wins with 4% > > Running times: > X264: 1 hour 3 minutes > VP8: 2 hours 0 minutes > JM: order of magnitude slower > > It is interesting to note that the measurements are more stable in the ne= w test; the variance of the percentages for the sequences is now around 70,= down from around 700 in Google's test of April 3rd. We believe this is du= e to the removal of the rate controller, which acts like noise on the measu= rements. > > We also tried setting H.264 to constrained high (no interlace and no B-pi= ctures, compared to high). The results were then: > > X264 constrained high vs VP8: H.264 wins with 25% > JM constrained high vs VP8: H.264 wins with 24% > [...] At one point, running the libvpx implementation of VP8 in fixed qp mode would effectively limit the encoder to only a single reference frame. I don't recall if it's still the case. Another unexpected behavior for people trying this mode is that making libvpx bump up against the lower quantizer without setting an approximately correct target bitrate can also put the encoder into its "over quant" mode, where it'll throw away additional residual trying to hit the target bitrate. It doesn't have anything like the x264 ipratio (though I see you set this to 1, but this is something that bites people trying fixed-qp). This mode isn't really supported by libvpx, so I'd be careful about taking these results as representative of the very best VP8 can do. From robin@hookflash.com Tue Jun 25 21:37:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB3521E8094 for ; Tue, 25 Jun 2013 21:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aY6N1GXQZ2g for ; Tue, 25 Jun 2013 21:37:07 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 731FC11E8106 for ; Tue, 25 Jun 2013 21:37:07 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so29992707iea.18 for ; Tue, 25 Jun 2013 21:37: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:user-agent:mime-version:to:subject :content-type:x-gm-message-state; bh=h2l3Ku5J5lXt1TrR7CxGg6nHJKl+UW08/lqvacFiDoQ=; b=g3oM9ab+clDZek4aa9/F3925ruYvkGaU5JXGpttfZfcGTnc28WotsKaKlu9ioiMjsq zbIT2Wn0hR+UIEsufUgXwyAUYSy83wS8knzS9FslrjzYQmmcsHGesONHaqPpcQybAvu2 jMSpCDtg4HzExcQcVeUgCMKagSXYFiNheVvaTzVcEEZkY+yhZcD3w5arPNhAdsiQiuHK Q8WK6O1YfwFOJi2v/L+DnGv0xCOdQHRmsVKy/EG40plBjjTNlYJUjIyYCwNofMWQ2ehz ev8YZ9YhbF2Lj/gldkthN+y3hjOqo6ukNEvyhtOy0e8IWGC/oqK8LeKBHwuew/wmcf57 aFAw== X-Received: by 10.50.132.98 with SMTP id ot2mr10501545igb.38.1372221425866; Tue, 25 Jun 2013 21:37:05 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id l9sm6707847igt.5.2013.06.25.21.37.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 21:37:05 -0700 (PDT) Message-ID: <51CA6FEE.6030702@hookflash.com> Date: Wed, 26 Jun 2013 00:37:02 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------000508070608020804070603" X-Gm-Message-State: ALoCoQnQRE4tcgsvYoD6k291tlf+vN6ra2f85bz2F+1dFnwa/X0Re1MmEXN1hAA/m81UjizW7Go5 Subject: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 04:37:08 -0000 This is a multi-part message in MIME format. --------------000508070608020804070603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit * According to many, real adoption of WebRTC will not happen if we continue to force everyone to use this SDP Offer/Answer methodology. It is clearly blocking our way forward and the amount of specification documentation remaining needed for the browser vendors to produce a compatible SDP based WebRTC engine in a browser is much more daunting than most are willing to admit. The draft rationale behind a JavaScript Object API model: http://www.ietf.org/internet-drafts/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00.txt Whereas: The WebRTC JavaScript Object API & Shim document will be along shortly. We wanted to get this initial rationale draft informational document out right away. Everyone that has any interest should review the reasons and concepts and comment before we get too far along on the details of an actual API, the initial API will follow in the coming days. Best regards, Robin Raymond* --------------000508070608020804070603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

    According to many, real adoption of WebRTC will not happen if we continue to force everyone to use this SDP Offer/Answer methodology.  It is clearly blocking our way forward and the amount of specification documentation remaining needed for the browser vendors to produce a compatible SDP based WebRTC engine in a browser is much more daunting than most are willing to admit.


    The draft rationale behind a JavaScript Object API model:

    http://www.ietf.org/internet-drafts/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00.txt

    Whereas:

    The WebRTC JavaScript Object API & Shim document will be along shortly.


    We wanted to get this initial rationale draft informational document out right away. Everyone that has any interest should review the reasons and concepts and comment before we get too far along on the details of an actual API, the initial API will follow in the coming days.


    Best regards,

    Robin Raymond

    --------------000508070608020804070603-- From lars@netapp.com Wed Jun 26 08:35:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C670B11E80EF for ; Wed, 26 Jun 2013 08:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.466 X-Spam-Level: X-Spam-Status: No, score=-4.466 tagged_above=-999 required=5 tests=[AWL=-1.867, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75D4byfEngUD for ; Wed, 26 Jun 2013 08:35:10 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2817911E811B for ; Wed, 26 Jun 2013 08:35:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,945,1363158000"; d="scan'208";a="29697413" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 26 Jun 2013 08:35:09 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.35]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Wed, 26 Jun 2013 08:35:09 -0700 From: "Eggert, Lars" To: Harald Alvestrand Thread-Topic: [rtcweb] More H.264 vs VP8 tests Thread-Index: Ac5vQ4bE4hnmu5ERSv6YOg93i7vBVwCHVgWAAFcimAA= Date: Wed, 26 Jun 2013 15:35:08 +0000 Message-ID: <1FEDF573-E2BD-49D7-8AAF-8F9BDFF02EBB@netapp.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C3020B6@ESESSMB209.ericsson.se> <51C8C16B.4070405@alvestrand.no> In-Reply-To: <51C8C16B.4070405@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <84E26110768E2A4EA19E1C3A204B1EE6@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:35:15 -0000 Hi, On Jun 25, 2013, at 0:00, Harald Alvestrand wrote: > This would seem to me to be an argument for including the rate control...= . what we are looking for is the codec where people can demonstrate the bes= t performance for our specific situations, not the codec that is best able = to fulfil a set of conditions that are inappropriate for Real Life. I'd agree with this argument *if* we actually had some idea of what congest= ion control algorithm(s) RMCAT will propose. If we did, looking at congesti= on-controlled output quality would make a lot of sense. But, we don't know what RMCAT will recommend, and - with my RMCAT chair hat= on - progress is slow, because participation is not exactly stellar. RTCWE= B folks with an interest in this topic should start participating in RMCAT.= Pretty please. But, I digressed. Since we don't know what algorithm RMCAT will recommend, = comparing different codec/congestion-control pairs makes it very hard to fi= gure out whether quality differences are due to the codec, or due to the co= ngestion controller. So as a baseline, it would make sense to eliminate the congestion controlle= r from this comparison, at least initially. Once we have some candidate con= gestion controllers on the table in RMCAT, comparing encoder-controller pai= rs makes sense, e.g., VP8 with controller A against MPEG with controller A,= VP8 with controller B against MPEG with controller B, etc. Because in the end, as you say, congestion-controlled output quality is wha= t matters in the real world. So IMO any final decision on a codec needs to = wait until we know what the congestion controller is doing. Lars= From mzanaty@cisco.com Wed Jun 26 10:41:43 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A0121F9DBB for ; Wed, 26 Jun 2013 10:41:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGFkLYrbjryh for ; Wed, 26 Jun 2013 10:41:39 -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 E546421F99AC for ; Wed, 26 Jun 2013 10:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3017; q=dns/txt; s=iport; t=1372268499; x=1373478099; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tBIQ9hSC3mJKiVpRpb5Tt2zTyp3k7ZmMmBF4DTosY3M=; b=b9IDKu6dhiqaO9vE5Z9O60jKMZlZRCA9sJPDtD0hSJKb78/4eHaSlDmM MYVsjJ1BLMB5nPwE1w1Cpore6FtmtgGOhTir8I1hKMgTQgNBGDMR8JHoc /dNesnYCrpCqu7xQguJxN05yZdYzmGdH0Ls0mY0KJEQyLkdoXnAFOZUhG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAEgny1GtJV2d/2dsb2JhbABbgwkxv0aBAxZ0giMBAQEEAQEBNzQLEAIBCBgeECcLJQEBBA4FGYd1DLl/BI8YMweDAmEDl0WRRYMR X-IronPort-AV: E=Sophos;i="4.87,945,1363132800"; d="scan'208";a="227804959" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 26 Jun 2013 17:41:21 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5QHfLMA028196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 17:41:21 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 12:41:21 -0500 From: "Mo Zanaty (mzanaty)" To: "Eggert, Lars" Thread-Topic: [rtcweb] More H.264 vs VP8 tests Thread-Index: Ac5ylF52K8Kw3CTuSzmtIg91KzwPfw== Date: Wed, 26 Jun 2013 17:41:20 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1C3020B6@ESESSMB209.ericsson.se> <51C8C16B.4070405@alvestrand.no> <1FEDF573-E2BD-49D7-8AAF-8F9BDFF02EBB@netapp.com> In-Reply-To: <1FEDF573-E2BD-49D7-8AAF-8F9BDFF02EBB@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <6263F1313075D64DA90F4BBAFDBC4292@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 17:41:43 -0000 Rate control is typically a different beast from congestion control, and an= y coupling is typically very loose. Rate control is primarily adaptive quan= tization to optimize perceptual quality based on content statistics, with l= ittle or no coupling to transport statistics. Any such coupling is often lo= ose, like a target average bit rate over coarse timescales inappropriate fo= r congestion control like seconds or longer. Constraining rate control to a= lso perform congestion control over tight timescales like a frame time will= result in suboptimal video quality, because content statistics are inheren= tly uncorrelated with transport statistics, so forcing any coupling degrade= s perceptual quality. Hence why congestion control is often implemented as = a pacer/shaper outside the encoder rate control, with a slower feedback loo= p to adapt the target rate of the encoder rate control less frequently than= congestion controlled packet transmission. Anyone interested in congestion control or its coupling to rate control sho= uld participate in RMCAT. Mo On Jun 26, 2013, at 11:35 AM, "Eggert, Lars" wrote: Hi, On Jun 25, 2013, at 0:00, Harald Alvestrand wrote: > This would seem to me to be an argument for including the rate control...= . what we are looking for is the codec where people can demonstrate the bes= t performance for our specific situations, not the codec that is best able = to fulfil a set of conditions that are inappropriate for Real Life. I'd agree with this argument *if* we actually had some idea of what congest= ion control algorithm(s) RMCAT will propose. If we did, looking at congesti= on-controlled output quality would make a lot of sense. But, we don't know what RMCAT will recommend, and - with my RMCAT chair hat= on - progress is slow, because participation is not exactly stellar. RTCWE= B folks with an interest in this topic should start participating in RMCAT.= Pretty please. But, I digressed. Since we don't know what algorithm RMCAT will recommend, = comparing different codec/congestion-control pairs makes it very hard to fi= gure out whether quality differences are due to the codec, or due to the co= ngestion controller. So as a baseline, it would make sense to eliminate the congestion controlle= r from this comparison, at least initially. Once we have some candidate con= gestion controllers on the table in RMCAT, comparing encoder-controller pai= rs makes sense, e.g., VP8 with controller A against MPEG with controller A,= VP8 with controller B against MPEG with controller B, etc. Because in the end, as you say, congestion-controlled output quality is wha= t matters in the real world. So IMO any final decision on a codec needs to = wait until we know what the congestion controller is doing. Lars _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Wed Jun 26 10:51:01 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38B121F9F84 for ; Wed, 26 Jun 2013 10:51:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CO738re76hJ2 for ; Wed, 26 Jun 2013 10:50:54 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3691221F9F4C for ; Wed, 26 Jun 2013 10:50:54 -0700 (PDT) X-AuditID: c1b4fb30-b7fab6d00000040c-d9-51cb29fc5300 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C4.99.01036.CF92BC15; Wed, 26 Jun 2013 19:50:52 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 19:50:52 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "Eggert, Lars" Thread-Topic: [rtcweb] More H.264 vs VP8 tests Thread-Index: Ac5vQ4bE4hnmu5ERSv6YOg93i7vBVw== Date: Wed, 26 Jun 2013 17:50:51 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C304EDC@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C3020B6@ESESSMB209.ericsson.se> <51C8C16B.4070405@alvestrand.no> <1FEDF573-E2BD-49D7-8AAF-8F9BDFF02EBB@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre4fzdOBBjs/a1oc6+tis3jxuofF Yu2/dnYHZo8rE66weixZ8pPJY8anL2wBzFFcNimpOZllqUX6dglcGTdezmIumCRcsfk2TwPj U/4uRk4OCQETiZe321kgbDGJC/fWs3UxcnEICRxmlNj59wGUs4hRYvmcc0wgVWwCgRJb9y1g A7FFBFQkNs8/zQ5iMwuESqydsAIsLiygK9FwfA1UjZ7EwucvWGDs3fs/MoPYLAKqErN2bwSz eQV8Jc6ufgy1bD2TxLKzz8EaGIFO+n5qDRPEAnGJW0/mM0GcKiCxZM95ZghbVOLl43+sELaS xI8Nl1gg6vUkbkydwgZha0ssW/gaapmgxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsoqRPTcx Mye93HwTIzBCDm75bbCDcdN9sUOM0hwsSuK8n07tChQSSE8sSc1OTS1ILYovKs1JLT7EyMTB KdXAmLNd58U8/vPeX9TTVFy3uf9cGfNOR72y/s3pxM2ap+5XZcfe3ee349H6eL7AfSLzWBcf Mky9d7LQLlFCWov/cD9L/1PtI2tjRR06vX1ltetqElbaird8ynzC/TPj+w29yyUfer1MUrW5 g5NDHe8u5Ho466jeyz9JOsUV/RGzP73cvPjAdL1gJZbijERDLeai4kQA1QF23F4CAAA= Cc: "" Subject: Re: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 17:51:01 -0000 On 2013-06-26 17:35, Eggert, Lars wrote:=0A= > Hi,=0A= >=0A= > On Jun 25, 2013, at 0:00, Harald Alvestrand =0A= > wrote:=0A= >> This would seem to me to be an argument for including the rate=0A= >> control.... what we are looking for is the codec where people can=0A= >> demonstrate the best performance for our specific situations, not=0A= >> the codec that is best able to fulfil a set of conditions that are=0A= >> inappropriate for Real Life.=0A= >=0A= > I'd agree with this argument *if* we actually had some idea of what=0A= > congestion control algorithm(s) RMCAT will propose. If we did,=0A= > looking at congestion-controlled output quality would make a lot of=0A= > sense.=0A= >=0A= > But, we don't know what RMCAT will recommend, and - with my RMCAT=0A= > chair hat on - progress is slow, because participation is not exactly=0A= > stellar. RTCWEB folks with an interest in this topic should start=0A= > participating in RMCAT. Pretty please.=0A= >=0A= > But, I digressed. Since we don't know what algorithm RMCAT will=0A= > recommend, comparing different codec/congestion-control pairs makes=0A= > it very hard to figure out whether quality differences are due to the=0A= > codec, or due to the congestion controller.=0A= >=0A= > So as a baseline, it would make sense to eliminate the congestion=0A= > controller from this comparison, at least initially. Once we have=0A= > some candidate congestion controllers on the table in RMCAT,=0A= > comparing encoder-controller pairs makes sense, e.g., VP8 with=0A= > controller A against MPEG with controller A, VP8 with controller B=0A= > against MPEG with controller B, etc.=0A= >=0A= > Because in the end, as you say, congestion-controlled output quality=0A= > is what matters in the real world. So IMO any final decision on a=0A= > codec needs to wait until we know what the congestion controller is=0A= > doing.=0A= =0A= If this was only about video quality I would agree, but as things stand =0A= now I would say that the data we have available indicate that VP8 and =0A= h.264 baseline are comparable regarding video quality, and that possible = =0A= MTI selection would come down to other things (like licensing, current =0A= deployment etc.)=0A= =0A= >=0A= > Lars _______________________________________________ rtcweb mailing=0A= > list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From stefan.lk.hakansson@ericsson.com Wed Jun 26 14:24:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA9521F9B81 for ; Wed, 26 Jun 2013 14:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.124 X-Spam-Level: X-Spam-Status: No, score=-4.124 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Rzyy1ph8P5S for ; Wed, 26 Jun 2013 14:24:24 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3E37421F9ABD for ; Wed, 26 Jun 2013 14:24:22 -0700 (PDT) X-AuditID: c1b4fb38-b7f176d000001730-fb-51cb5c01291c Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 99.10.05936.10C5BC15; Wed, 26 Jun 2013 23:24:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 23:24:17 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: John Koleszar Thread-Topic: [rtcweb] More H.264 vs VP8 tests Thread-Index: Ac5vQ4bE4hnmu5ERSv6YOg93i7vBVw== Date: Wed, 26 Jun 2013 21:24:16 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3055CA@ESESSMB209.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvrS5jzOlAg7ePtCx+r9zIarH2Xzu7 A5PHgk2lHkuW/GQKYIrisklJzcksSy3St0vgyph35iJLwVGlimcrJ7A1MG6Q6WLk5JAQMJHY 9X0nI4QtJnHh3nq2LkYuDiGBo4wSf36eYQVJCAksYpR4cVoPxGYTCJTYum8BG4gtIqAh0bF9 IjOIzSzgLbG+ew4LiC0soCvRcHwNVI2exMLnL1hg7N37PwLVc3CwCKhKXL3CAxLmFfCV+D5r PTPE3imMEj1nHoL1MgId9P3UGiaI+eISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIWwlicYlT1gh 6vUkbkydwgZha0ssW/iaGWKZoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkaM4tTgpN93I YBMjMBYObvltsYPx8l+bQ4zSHCxK4ryfTu0KFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCY Y9tz8cGuh0vqzCcERYaFXVqZWtQpf4ib82VM7dxmfZ/E7RNnv7n7evPSzKXamXavjXfcLuNP vlJlYcQjrODDvXnrhM17FwUyTBCKFJ+5WeV8Ycj+V/Ok3RZOPaWUsbX9ypVn6qYPdorLtbDU ZYh9ux2qeLi0ofijxoN8qQxj3Zw7mQknjacosRRnJBpqMRcVJwIAvfP6VlMCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 21:24:30 -0000 On 2013-06-25 17:36, John Koleszar wrote:=0A= > On Sat, Jun 22, 2013 at 6:41 AM, Bo Burman =0A= > wrote:=0A= >> Hi all,=0A= >>=0A= >> We have had a look at Google's comparison between VP8 and H.264=0A= >> constrained baseline that was posted on April 3rd=0A= >> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg07028.html).=0A= >> This post contains, as the one mentioned above (and if the=0A= >> attachments make it to the list), information on the exact tools=0A= >> and options used for encoding and should thus be repeatable by=0A= >> anyone interested.=0A= >>=0A= >> As was already stated by others on this list, one major problem is=0A= >> that Google's test involves the rate control mechanism. Typically=0A= >> codecs are measured with rate control turned off, since it acts as=0A= >> a huge noise on the measurement. Instead we propose to compare the=0A= >> codecs using fixed qp-levels. The qp-level is the quantization=0A= >> parameter that affects the rate/distortion tradeoff. Comparing=0A= >> using fixed qp-levels is what has been used when benchmarking HEVC=0A= >> against H.264 in the JCT-VC standardization, for instance. We are=0A= >> going to select a codec (essentially bit stream format), not a rate=0A= >> control mechanism: Once the codec is selected you can choose=0A= >> whatever rate control mechanism you wish.=0A= >>=0A= >> We used Google's excellent framework as the baseline and changed=0A= >> the parameter settings in order to make it possible to measure=0A= >> using fixed qp. We used the same sequences, but limited them to the=0A= >> first 10 seconds since they varied from 10 seconds to minutes; this=0A= >> also eased computation time.=0A= >>=0A= >> We used two H.264 encoder implementations: X264, which is an=0A= >> open-source codec that can operate in everything from real-time to=0A= >> slow, and JM which is the reference implementation that was used to=0A= >> develop H.264. JM is very slow but attempts to be very efficient in=0A= >> terms of bits per quality. The results were as follows:=0A= >>=0A= >> X264 baseline vs VP8: H.264 wins with 1% JM baseline vs VP8: H.264=0A= >> wins with 4%=0A= >>=0A= >> Running times: X264: 1 hour 3 minutes VP8: 2 hours 0 minutes JM:=0A= >> order of magnitude slower=0A= >>=0A= >> It is interesting to note that the measurements are more stable in=0A= >> the new test; the variance of the percentages for the sequences is=0A= >> now around 70, down from around 700 in Google's test of April 3rd.=0A= >> We believe this is due to the removal of the rate controller, which=0A= >> acts like noise on the measurements.=0A= >>=0A= >> We also tried setting H.264 to constrained high (no interlace and=0A= >> no B-pictures, compared to high). The results were then:=0A= >>=0A= >> X264 constrained high vs VP8: H.264 wins with 25% JM constrained=0A= >> high vs VP8: H.264 wins with 24%=0A= >>=0A= > [...]=0A= >=0A= > At one point, running the libvpx implementation of VP8 in fixed qp=0A= > mode would effectively limit the encoder to only a single reference=0A= > frame. I don't recall if it's still the case.=0A= =0A= We have stepped through the decoding of the .webm files produced using =0A= our parameter settings and they indeed use several reference frames, so =0A= no, this seems not to be the case.=0A= =0A= > Another unexpected=0A= > behavior for people trying this mode is that making libvpx bump up=0A= > against the lower quantizer without setting an approximately correct=0A= > target bitrate can also put the encoder into its "over quant" mode,=0A= > where it'll throw away additional residual trying to hit the target=0A= > bitrate.=0A= =0A= We have not seen this happen either. The target bitrate we set is =0A= ridiculously high so we do not see why the encoder should throw away =0A= anything that would cost bits, rather it would do the opposite.=0A= =0A= > It doesn't have anything like the x264 ipratio (though I=0A= > see you set this to 1, but this is something that bites people=0A= > trying fixed-qp). This mode isn't really supported by libvpx, so I'd=0A= > be careful about taking these results as representative of the very=0A= > best VP8 can do. _______________________________________________=0A= > rtcweb mailing list rtcweb@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From ggb@tokbox.com Wed Jun 26 16:30:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65E311E814C for ; Wed, 26 Jun 2013 16:30: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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJH1cZa4CF4E for ; Wed, 26 Jun 2013 16:30:10 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with SMTP id 1132211E8111 for ; Wed, 26 Jun 2013 16:30:09 -0700 (PDT) Received: from mail-yh0-f49.google.com ([209.85.213.49]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKUct5gLO+vJ144ipQTeFjdcTuIaSO1w89@postini.com; Wed, 26 Jun 2013 16:30:10 PDT Received: by mail-yh0-f49.google.com with SMTP id v1so61975yhn.8 for ; Wed, 26 Jun 2013 16:30:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=mJEjrKB9iI6NpKxx2T0+uHoguO7lHzRVlmY40IbIuNo=; b=J5RF3JEpxSVhhrtzUm1hzI4/eaaczow9wVCSTorZZwA5fWefW0+ocyUWZrciZd09ng x7WmaWI8TG2o1N/jos8H1tUyetyc21rJbZHHlvdFKITmA5qQx0na2OD85GcyVzI9ZXRt f+FD60TakBvw7X+mzQUWqfSzAbdx/pKpWNWQIlCunmah/qFWBkgVgZirml0OdXStpUYM acAOScZgy8r4tb8cVX5MK+PEwTaFsNRU+J64Lh7YyRTxCie8Pt0Mjb2aDkuTXB3GTEDD 978Oa2lTpINjFPrhNDeB8YcYmv1WmLrRtz5RKmZpZuR/g5E3UTF0XuwpS/1xi9uxUo5b 97aA== X-Received: by 10.236.92.211 with SMTP id j59mr3292457yhf.204.1372289404457; Wed, 26 Jun 2013 16:30:04 -0700 (PDT) X-Received: by 10.236.92.211 with SMTP id j59mr3292452yhf.204.1372289404360; Wed, 26 Jun 2013 16:30:04 -0700 (PDT) Received: from [10.71.1.78] ([209.155.233.4]) by mx.google.com with ESMTPSA id v68sm228051yhn.22.2013.06.26.16.30.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 16:30:03 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) From: =?iso-8859-1?Q?Gustavo_Garc=EDa?= In-Reply-To: Date: Wed, 26 Jun 2013 19:29:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <782A8339-9A9D-49AE-85E6-9FAD55436807@tokbox.com> References: <5158F0FC.3070104@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02B56F@FR711WXCHMBA02.zeu.alcatel-lucent.com> <5165CF9D.6030302@jesup.org> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmQ+3/bX7M0y0IsJa6HgZbkU2+ABhV8RhaTa2Y0EBp+YNxbDpU5PS5ElY3F7DFYHNfdG99ua+wvd0CzimDny1yTSYbvhlmpt2RUJgdes1hbdXbSlZslDSC52wfpuWLJV63dL8M5EyjA+hacudlZz6tebopLYQ== Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 23:30:14 -0000 "We reject kings, presidents and voting. We believe in rough consensus = and running code". (IETF TAO) - Lot of developers building stuff beyond a PSTN interconnection demo = are having problems with the existing model. Complexity, limitations = and incompatibilities make us feel like fighting an API instead of using = it. - There are a lot of issues (bugs, incompatibilities, feature requests) = because of SDP and O/A. Take a look at webrtc issue tracker. - The actual experience of people using the API should be a stronger = argument than a voting done one year ago. Specially when most of = developers are not participating in IETF voting and after realizing the = implications of SDP and O/A model f.e. on all those endless Plan-XXX = discussions. - There is a much more simple solution (something like CU-RTC-Web) and = you can always write a SDP/O/A/PeerConnection API on top of it (I had a = prototype working in a couple of hours), but the other way around is = much more hard if not impossible.=20 In my opinion the only reasonable approaches are: - Change the API now - Change the API in one year +1 to I=F1aki's request too G. On 18/06/2013, at 15:19, Matthew Jordan wrote: >=20 > On Tue, Jun 18, 2013 at 1:22 PM, Adrian Georgescu = wrote: > +1 >=20 > While working with the specs, some may have realised that SDP is not = such a great idea to put in practice and may also want to come forward = to admit their mistake. >=20 > Regards, > Adrian >=20 >=20 > In the Asterisk project, we were able to use our legacy SIP stack to = enable very basic WebRTC communication with Chrome and FireFox. That = sounds nice, until you realize we have to continually preface that with = "sometimes". >=20 > Because the answer is, more often than not, something breaks. = Invariably, the breakages have been in the SDPs sent to Asterisk by the = browser. What SDP breaks us changes depending on the browser being used, = the version of said browser, and whether or not some new WebRTC SDP = feature has been put in the browser's latest release. And just when we = think we have to modify Asterisk to handle the new SDP sent by some = browser, the browser changes again. As a result, Asterisk 11 hasn't = changed a lot since we released; we've been trying to avoid coding to a = moving target. We always envisioned that things would quiet down and the = browsers would settle on an implementation of SDP that we could adapt to = - but it doesn't seem like things are quieting down as much as we'd = like. And sure, the SIP stack in Asterisk is crufty, and sure, sometimes = the fault is in our implementation, not the browser's - but I think we = on the Asterisk project can certainly say that relying on SDP hasn't = been a panacea for interoperability. >=20 > It feels like maintaining compatibility with "traditional" SDP = implementations is getting harder for the browsers to manage and holding = the entire process back. As one of those older "traditional" = implementations, I'd rather write an entirely new channel driver for = Asterisk than have to re-write our SDP handling. >=20 > So... +1 to Inaki's request. >=20 > Matt >=20 > --=20 > Matthew Jordan > Digium, Inc. | Engineering Manager > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at: http://digium.com & http://asterisk.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From pthatcher@google.com Wed Jun 26 16:46:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD1A21F994A for ; Wed, 26 Jun 2013 16:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWlLjB+6Ha9r for ; Wed, 26 Jun 2013 16:46:41 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD7221F93DA for ; Wed, 26 Jun 2013 16:46:41 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id t12so38661pdi.35 for ; Wed, 26 Jun 2013 16:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iRIlrRHselYUXxsPYW95U2iQ/3FbIbOBGiYxhf7Bur4=; b=RN5beGJK9lAg+X1Om2pdVIQUtOxHe5q1TZDWJmQY2UxdHHveuu2D1RgGyOfylIZf8S o7Ptl6yzlS01JH2FafWtSFzBFE7KtfpH9aousWWze4do5i7p9u4e717qUYzdbdWbFvH/ 7S7JzCCVNkFqrX+mnr81dK8+xY08XM6TWCKoQYRADOwQAR7eaW/CUwzI03yVaqpDwTjP izgraDOJD0fEF9i2vFfC7oJgdtON4Rc3vETbdiv1Tt7rvv2TnWjAWvSRun22xwBt8cPO ZOIrJ9Q5pE+rs4AfR+4tXunon2IxX1qBGNCizdr5g69442yja3RqDvsLJOEt8LZo5d0X r7wQ== 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=iRIlrRHselYUXxsPYW95U2iQ/3FbIbOBGiYxhf7Bur4=; b=SCj6mNHNpJALWUGO2V8dQS+wtlFWASLpdP51T6Gt5jOtNyVbx+xA4mqLm+OrK/GDhQ cwOiT+KrRfrCQKGJ4MGq790zZT2kLNfAoSljXfY8O2uB/mOnEHJumYgGYt0c53SBa31P netrcDzXyjoPyXxHBuWoU9IJbiSjd4VJJKq5mVn+lIe7A6u5dnnrCs3bihSJeWdFvo29 xELG/Zyvl0GRwSYxXw0MJGXiZi/B1+AQyyE6UW+G4D+w1yadh2ZZxPQR8li5nwKfIz1E 57YFDlyb9/1RhnZFlBgg0edfZtTHN9Z4SAcY9HtV4fXpOJMT2Q3ChHmAlBzbzlX9tKs5 tqfA== X-Received: by 10.66.246.194 with SMTP id xy2mr3121888pac.131.1372290400712; Wed, 26 Jun 2013 16:46:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.216.163 with HTTP; Wed, 26 Jun 2013 16:46:00 -0700 (PDT) In-Reply-To: <782A8339-9A9D-49AE-85E6-9FAD55436807@tokbox.com> References: <5158F0FC.3070104@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02B56F@FR711WXCHMBA02.zeu.alcatel-lucent.com> <5165CF9D.6030302@jesup.org> <782A8339-9A9D-49AE-85E6-9FAD55436807@tokbox.com> From: Peter Thatcher Date: Wed, 26 Jun 2013 16:46:00 -0700 Message-ID: To: =?UTF-8?Q?Gustavo_Garc=C3=ADa?= Content-Type: multipart/alternative; boundary=047d7b15ae49dd1c9e04e01741a4 X-Gm-Message-State: ALoCoQmIelsO/5HlVO/naK5XOgTeQdfTZpUTjD77ooI+bYg2+SkpLDlUjTffc2S35L+oY2OAeJXZGbsfMwJf4D3i8Q6szlyjsT+aYEq1dThtEGwiTHFSqZP/V4NjEL4UY/iBb3Mcku438O4nLFs8WQQBU55QTwCFyXwk1f4ZoR2U5bt9IUB5jiJZ6PlRsHPSXQxstHEpvChz Cc: "" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 23:46:51 -0000 --047d7b15ae49dd1c9e04e01741a4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 26, 2013 at 4:29 PM, Gustavo Garc=C3=ADa wrote= : > "We reject kings, presidents and voting. We believe in rough consensus an= d > running code". (IETF TAO) > > - Lot of developers building stuff beyond a PSTN interconnection demo are > having problems with the existing model. Complexity, limitations and > incompatibilities make us feel like fighting an API instead of using it. > - There are a lot of issues (bugs, incompatibilities, feature requests) > because of SDP and O/A. Take a look at webrtc issue tracker. > - The actual experience of people using the API should be a stronger > argument than a voting done one year ago. Specially when most of > developers are not participating in IETF voting and after realizing the > implications of SDP and O/A model f.e. on all those endless Plan-XXX > discussions. > If there's a great "silent majority" out there, I think it would help the WG a lot for them to come on the forum and give clear, concrete examples (not ranty, please) of what they're trying to do and what their pain points are. I think that's much more helpful than just remaining silently in pain. On the flip side, if app developers love using the current API and think SDP O/A is great, they should express that as well. > - There is a much more simple solution (something like CU-RTC-Web) and yo= u > can always write a SDP/O/A/PeerConnection API on top of it (I had a > prototype working in a couple of hours), but the other way around is much > more hard if not impossible. > You know you're in trouble when CU-RTC-Web is considered "much more simple" :). I think your "bulid RtcPeerConnection on top in JS" is a great idea, but you had a prototype in a couple of hours? I have a hard time you could implement much of SDP O/A correctly in a couple of ours. And how could you test such a thing, without a working implementation of CU-RTC-Web? > In my opinion the only reasonable approaches are: > - Change the API now > - Change the API in one year > > You could add: - Change the API every couple weeks by changing what SDP is generated/supported. :) +1 to I=C3=B1aki's request too > > G. > > On 18/06/2013, at 15:19, Matthew Jordan wrote: > > > > > On Tue, Jun 18, 2013 at 1:22 PM, Adrian Georgescu > wrote: > > +1 > > > > While working with the specs, some may have realised that SDP is not > such a great idea to put in practice and may also want to come forward to > admit their mistake. > > > > Regards, > > Adrian > > > > > > In the Asterisk project, we were able to use our legacy SIP stack to > enable very basic WebRTC communication with Chrome and FireFox. That soun= ds > nice, until you realize we have to continually preface that with > "sometimes". > > > > Because the answer is, more often than not, something breaks. > Invariably, the breakages have been in the SDPs sent to Asterisk by the > browser. What SDP breaks us changes depending on the browser being used, > the version of said browser, and whether or not some new WebRTC SDP featu= re > has been put in the browser's latest release. And just when we think we > have to modify Asterisk to handle the new SDP sent by some browser, the > browser changes again. As a result, Asterisk 11 hasn't changed a lot sinc= e > we released; we've been trying to avoid coding to a moving target. We > always envisioned that things would quiet down and the browsers would > settle on an implementation of SDP that we could adapt to - but it doesn'= t > seem like things are quieting down as much as we'd like. And sure, the SI= P > stack in Asterisk is crufty, and sure, sometimes the fault is in our > implementation, not the browser's - but I think we on the Asterisk projec= t > can certainly say that relying on SDP hasn't been a panacea for > interoperability. > > > > It feels like maintaining compatibility with "traditional" SDP > implementations is getting harder for the browsers to manage and holding > the entire process back. As one of those older "traditional" > implementations, I'd rather write an entirely new channel driver for > Asterisk than have to re-write our SDP handling. > > > > So... +1 to Inaki's request. > > > > Matt > > > > -- > > Matthew Jordan > > Digium, Inc. | Engineering Manager > > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > > Check us out at: http://digium.com & http://asterisk.org > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b15ae49dd1c9e04e01741a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    = On Wed, Jun 26, 2013 at 4:29 PM, Gustavo Garc=C3=ADa <= ggb@tokbox.com><= /span> wrote:
    "We reject kings, presidents and voting= . We believe in rough consensus and running code". (IETF TAO)

    - Lot of developers building stuff beyond a PSTN interconnection demo are h= aving problems with the existing model. =C2=A0 Complexity, limitations and = incompatibilities make us feel like fighting an API instead of using it. - There are a lot of issues (bugs, incompatibilities, feature requests) bec= ause of SDP and O/A. =C2=A0Take a look at webrtc issue tracker.
    - The actual experience of people using the API should be a stronger argume= nt than a voting done one year ago. =C2=A0Specially when most of developers= are not participating in IETF voting and after realizing the implications = of SDP and O/A model f.e. on all those endless Plan-XXX =C2=A0discussions.<= br>

    If there's a great "silent majori= ty" out there, I think it would help the WG a lot for them to come on = the forum and give clear, concrete examples (not ranty, please) of what the= y're trying to do and what their pain points are. =C2=A0 I think that&#= 39;s much more helpful than just remaining silently in pain. =C2=A0On the f= lip side, if app developers love using the current API and think SDP O/A is= great, they should express that as well.
    =C2=A0 =C2=A0
    - There is a much more simple solution (something like CU-RTC-Web) and you = can always write a SDP/O/A/PeerConnection API on top of it (I had a prototy= pe working in a couple of hours), but the other way around is much more har= d if not impossible.

    You know you're in trouble when CU-RTC= -Web is considered "much more simple" :).

    I think your "bulid RtcPeerConnection on top in JS" is a great = idea, but you had a prototype in a couple of hours? =C2=A0I have a hard tim= e you could implement much of SDP O/A correctly in a couple of ours. =C2=A0= And how could you test such a thing, without a working implementation of CU= -RTC-Web?
    =C2=A0
    In my opinion the only reasonable approaches are:
    - Change the API now
    - Change the API in one year


    You could add:

    - Change the API every couple weeks by changing what SDP is generated/sup= ported.
    =C2=A0

    :)

    +1 to I=C3=B1aki's request too

    G.

    On 18/06/2013, at 15:19, Matthew Jordan wrote:

    >
    > On Tue, Jun 18, 2013 at 1:22 PM, Adrian Georgescu <ag@ag-projects.com> wrote:
    > +1
    >
    > While working with the specs, some may have realised that SDP is not s= uch a great idea to put in practice and may also want to come forward to ad= mit their mistake.
    >
    > Regards,
    > Adrian
    >
    >
    > In the Asterisk project, we were able to use our legacy SIP stack to e= nable very basic WebRTC communication with Chrome and FireFox. That sounds = nice, until you realize we have to continually preface that with "some= times".
    >
    > Because the answer is, more often than not, something breaks. Invariab= ly, the breakages have been in the SDPs sent to Asterisk by the browser. Wh= at SDP breaks us changes depending on the browser being used, the version o= f said browser, and whether or not some new WebRTC SDP feature has been put= in the browser's latest release. And just when we think we have to mod= ify Asterisk to handle the new SDP sent by some browser, the browser change= s again. As a result, Asterisk 11 hasn't changed a lot since we release= d; we've been trying to avoid coding to a moving target. We always envi= sioned that things would quiet down and the browsers would settle on an imp= lementation of SDP that we could adapt to - but it doesn't seem like th= ings are quieting down as much as we'd like. And sure, the SIP stack in= Asterisk is crufty, and sure, sometimes the fault is in our implementation= , not the browser's - but I think we on the Asterisk project can certai= nly say that relying on SDP hasn't been a panacea for interoperability.=
    >
    > It feels like maintaining compatibility with "traditional" S= DP implementations is getting harder for the browsers to manage and holding= the entire process back. As one of those older "traditional" imp= lementations, I'd rather write an entirely new channel driver for Aster= isk than have to re-write our SDP handling.
    >
    > So... +1 to Inaki's request.
    >
    > Matt
    >
    > --
    > Matthew Jordan
    > Digium, Inc. | Engineering Manager
    > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
    > Check us out at: http:= //digium.com & ht= tp://asterisk.org
    > __________________= _____________________________
    > rtcweb mailing list
    > rtcweb@ietf.org
    > https://www.ietf.org/mailman/listinfo/rtcweb

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

    --047d7b15ae49dd1c9e04e01741a4-- From martin.thomson@gmail.com Wed Jun 26 16:54:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6172211E8167 for ; Wed, 26 Jun 2013 16:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eQhyNhZGzIf for ; Wed, 26 Jun 2013 16:54:07 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1535511E8155 for ; Wed, 26 Jun 2013 16:54:06 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq4so2546784wib.12 for ; Wed, 26 Jun 2013 16:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I1bzBJ7vMwIh5UG59whqJ60oHrTEnU1XL+3ylsU3viY=; b=C6WDYEydnXQpigar1jOwwH074l7K69QxUxTtScR0VNCT2cDxliH0sj5oY/dELuzQvV UyZ201y7cg8i1e7ycyy6pXqlufLCtExC5rpzSVpdpSTunHcvlPf19D4hABd/B0Rm0CRv SvQc0MUgwH3SXDf+O5r9ZTQkfHA9/NQfW4yZLkSNn5b0baG4DGZ664k/Zp7v9Iw1IzUk m2NU43po/Enyc3B9v81ZL5ui86pd4fowbZl1uzLbFR4FcL0eqLwEVd92BW4w9uTobZhH 46sF/pmUWyj/Nj/J/TuDXmMc+ALK8yrBxKacoeHULEZ8zxYs5FmFOWon6TV94A/DxnVc rLiw== MIME-Version: 1.0 X-Received: by 10.194.78.110 with SMTP id a14mr4364517wjx.84.1372290844707; Wed, 26 Jun 2013 16:54:04 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 26 Jun 2013 16:54:04 -0700 (PDT) In-Reply-To: References: <5158F0FC.3070104@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02B56F@FR711WXCHMBA02.zeu.alcatel-lucent.com> <5165CF9D.6030302@jesup.org> <782A8339-9A9D-49AE-85E6-9FAD55436807@tokbox.com> Date: Wed, 26 Jun 2013 16:54:04 -0700 Message-ID: From: Martin Thomson To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 23:54:08 -0000 On 26 June 2013 16:46, Peter Thatcher wrote: > You know you're in trouble when CU-RTC-Web is considered "much more simple" > :). When you are comparing to SDP O/A, pigs start looking like princesses. > how could you test such a thing, without a working implementation of CU-RTC-Web? http://html5labs.interoperabilitybridges.com/prototypes/cu-rtc-web-roaming/cu-rtc-web-roaming/info Surely that's enough to build a proof of concept application. I'm not claiming that it's glamorous, far from it, there's some atrocious code in there, but it's not a complete vacuum. From ggb@tid.es Wed Jun 26 16:58:46 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD8A21F9A5C for ; Wed, 26 Jun 2013 16:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gv+kb2igJyy for ; Wed, 26 Jun 2013 16:58:38 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id D2A4121F9A52 for ; Wed, 26 Jun 2013 16:58:36 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MP000C5EYLN16@tid.hi.inet> for rtcweb@ietf.org; Thu, 27 Jun 2013 01:58:35 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id F2.21.02911.B208BC15; Thu, 27 Jun 2013 01:58:35 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MP000C59YLM16@tid.hi.inet> for rtcweb@ietf.org; Thu, 27 Jun 2013 01:58:35 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 01:57:31 +0200 Date: Wed, 26 Jun 2013 23:57:31 +0000 From: Gustavo Garcia Bernardo In-reply-to: To: "pthatcher@google.com" , "ggb@tokbox.com" Message-id: <6dylyuxdj0v9xctq6nv1tpyy.1372290845930@email.android.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_V6ZZJSgIEjy7/9AQ98vLpg)" Content-language: en-US Accept-Language: en-US, es-ES Thread-topic: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Thread-index: AQHObFEKDQ1B0y4wlEq3/uPYuSNPJJk7t0YAgAzYtoCAAAR6AIAAJQrQ X-AuditID: 0a5f4e69-b7f118e000000b5f-09-51cb802bc4dd X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42Lhivcz1NVuOB1o8PWIiMXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKWHvUqeBIdsWMNXtZGhifR3QxcnBICJhING5j72LkBDLFJC7c W8/WxcjFISSwnVFiz5HFUM4vRol7rQcZIZxpjBKvrk9kBWlhEVCVeNhzG6ydTUBL4l/vNRYQ W1jAQ6Jz4UVmEJtTIFhi3e5XbCC2iECYxP39j8HizALqEksnN4DFhQT0JO7cmwI2k1fATeLB 2/dQtqDEj8n3WCDqsyQWdt1jg7DFJZpbb4LFGQVkJd7Nn88KMd9T4mTLA0YI201i9o4nzBCv CUgs2XMeyhaVePn4HyvEM5OZJba1TGOcwCg2C8m+WUj2zUKyD8LWk7gxdQpUXFti2cLXzBC2 rsSMf4dYkMUXMLKvYhQrTirKTM8oyU3MzEk3MNLLyNTLzEst2cQIibvMHYzLd6ocYhTgYFTi 4f3AeDpQiDWxrLgy9xCjBAezkghvaA5QiDclsbIqtSg/vqg0J7X4ECMTB6dUA6NsYYx+ee7V 49b758qvb323kM/851y+jnrDQzsmOqp8+/sw5sShCMbFxi+P/Vx9VD/YccWzqnP+SpZe+tZ7 utvvxFz8xbF7769MH+2EbX0K+YoXVM5d235n/yPpZ40FT9Zn9CXNusFqpl0R21b47c3fHZ9L Xt1zMe2WlTbJZZ/EzqOVKjytzlCJpTgj0VCLuag4EQDAWifMmQIAAA== References: <5158F0FC.3070104@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02B56F@FR711WXCHMBA02.zeu.alcatel-lucent.com> <5165CF9D.6030302@jesup.org> <782A8339-9A9D-49AE-85E6-9FAD55436807@tokbox.com> Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Gustavo Garcia Bernardo List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 23:58:46 -0000 --Boundary_(ID_V6ZZJSgIEjy7/9AQ98vLpg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Getting the feeling of that silent mayority is what we are doing in this th= read. Hope we can put something together as Robin volunteered to lead. There is a working implementation of cu-web-rtc, look for it in Microsoft h= tml labs page. Obviously my prototype is quick and dirty but you get my po= int on what you can do. Sent from mobile Peter Thatcher wrote: On Wed, Jun 26, 2013 at 4:29 PM, Gustavo Garc=EDa > wrote: "We reject kings, presidents and voting. We believe in rough consensus and = running code". (IETF TAO) - Lot of developers building stuff beyond a PSTN interconnection demo are h= aving problems with the existing model. Complexity, limitations and incom= patibilities make us feel like fighting an API instead of using it. - There are a lot of issues (bugs, incompatibilities, feature requests) bec= ause of SDP and O/A. Take a look at webrtc issue tracker. - The actual experience of people using the API should be a stronger argume= nt than a voting done one year ago. Specially when most of developers are = not participating in IETF voting and after realizing the implications of SD= P and O/A model f.e. on all those endless Plan-XXX discussions. If there's a great "silent majority" out there, I think it would help the W= G a lot for them to come on the forum and give clear, concrete examples (no= t ranty, please) of what they're trying to do and what their pain points ar= e. I think that's much more helpful than just remaining silently in pain.= On the flip side, if app developers love using the current API and think = SDP O/A is great, they should express that as well. - There is a much more simple solution (something like CU-RTC-Web) and you = can always write a SDP/O/A/PeerConnection API on top of it (I had a prototy= pe working in a couple of hours), but the other way around is much more har= d if not impossible. You know you're in trouble when CU-RTC-Web is considered "much more simple"= :). I think your "bulid RtcPeerConnection on top in JS" is a great idea, but yo= u had a prototype in a couple of hours? I have a hard time you could imple= ment much of SDP O/A correctly in a couple of ours. And how could you test= such a thing, without a working implementation of CU-RTC-Web? In my opinion the only reasonable approaches are: - Change the API now - Change the API in one year You could add: - Change the API every couple weeks by changing what SDP is generated/suppo= rted. :) +1 to I=F1aki's request too G. On 18/06/2013, at 15:19, Matthew Jordan wrote: > > On Tue, Jun 18, 2013 at 1:22 PM, Adrian Georgescu > wrote: > +1 > > While working with the specs, some may have realised that SDP is not such= a great idea to put in practice and may also want to come forward to admit= their mistake. > > Regards, > Adrian > > > In the Asterisk project, we were able to use our legacy SIP stack to enab= le very basic WebRTC communication with Chrome and FireFox. That sounds nic= e, until you realize we have to continually preface that with "sometimes". > > Because the answer is, more often than not, something breaks. Invariably,= the breakages have been in the SDPs sent to Asterisk by the browser. What = SDP breaks us changes depending on the browser being used, the version of s= aid browser, and whether or not some new WebRTC SDP feature has been put in= the browser's latest release. And just when we think we have to modify Ast= erisk to handle the new SDP sent by some browser, the browser changes again= . As a result, Asterisk 11 hasn't changed a lot since we released; we've be= en trying to avoid coding to a moving target. We always envisioned that thi= ngs would quiet down and the browsers would settle on an implementation of = SDP that we could adapt to - but it doesn't seem like things are quieting d= own as much as we'd like. And sure, the SIP stack in Asterisk is crufty, an= d sure, sometimes the fault is in our implementation, not the browser's - b= ut I think we on the Asterisk project can certainly say that relying on SDP= hasn't been a panacea for interoperability. > > It feels like maintaining compatibility with "traditional" SDP implementa= tions is getting harder for the browsers to manage and holding the entire p= rocess back. As one of those older "traditional" implementations, I'd rathe= r write an entirely new channel driver for Asterisk than have to re-write o= ur SDP handling. > > So... +1 to Inaki's request. > > Matt > > -- > Matthew Jordan > Digium, Inc. | Engineering Manager > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at: http://digium.com & http://asterisk.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_V6ZZJSgIEjy7/9AQ98vLpg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
    Getting the feeling of that silent mayority is what we are doing in th= is thread.  Hope we can put something together as Robin volunteered to= lead.

    There is a working implementation of cu-web-rtc, look for it in Micros= oft html labs page.  Obviously my prototype is quick and dirty but you= get my point on what you can do.


    Sent from mobile

    Peter Thatcher <pthatcher@google.com> wrote:

    On Wed, Jun 26, 2013 at 4:29 PM, Gustavo Garc=ED= a <ggb@tokbox.com&= gt; wrote:
    "We reject kings, presidents and voting. We believe in rough consensus= and running code". (IETF TAO)

    - Lot of developers building stuff beyond a PSTN interconnection demo are h= aving problems with the existing model.   Complexity, limitations and = incompatibilities make us feel like fighting an API instead of using it. - There are a lot of issues (bugs, incompatibilities, feature requests) bec= ause of SDP and O/A.  Take a look at webrtc issue tracker.
    - The actual experience of people using the API should be a stronger argume= nt than a voting done one year ago.  Specially when most of developers= are not participating in IETF voting and after realizing the implications = of SDP and O/A model f.e. on all those endless Plan-XXX  discussions.

    If there's a great "silent majority" out there, I think it w= ould help the WG a lot for them to come on the forum and give clear, concre= te examples (not ranty, please) of what they're trying to do and what their= pain points are.   I think that's much more helpful than just remaining silently in pain.  On the flip side, if a= pp developers love using the current API and think SDP O/A is great, they s= hould express that as well.
       
    - There is a much more simple solution (something like CU-RTC-Web) and you = can always write a SDP/O/A/PeerConnection API on top of it (I had a prototy= pe working in a couple of hours), but the other way around is much more har= d if not impossible.

    You know you're in trouble when CU-RTC-Web is considered "much mo= re simple" :).

    I think your "bulid RtcPeerConnection on top in JS" is a gre= at idea, but you had a prototype in a couple of hours?  I have a hard = time you could implement much of SDP O/A correctly in a couple of ours. &nb= sp;And how could you test such a thing, without a working implementation of CU-RTC-Web?
     
    In my opinion the only reasonable approaches are:
    - Change the API now
    - Change the API in one year


    You could add:

    - Change the API every couple weeks by changing what SDP is generated/= supported.
     

    :)

    +1 to I=F1aki's request too

    G.

    On 18/06/2013, at 15:19, Matthew Jordan wrote:

    >
    > On Tue, Jun 18, 2013 at 1:22 PM, Adrian Georgescu <ag@ag-projects.com> wrote:
    > +1
    >
    > While working with the specs, some may have realised that SDP is not s= uch a great idea to put in practice and may also want to come forward to ad= mit their mistake.
    >
    > Regards,
    > Adrian
    >
    >
    > In the Asterisk project, we were able to use our legacy SIP stack to e= nable very basic WebRTC communication with Chrome and FireFox. That sounds = nice, until you realize we have to continually preface that with "some= times".
    >
    > Because the answer is, more often than not, something breaks. Invariab= ly, the breakages have been in the SDPs sent to Asterisk by the browser. Wh= at SDP breaks us changes depending on the browser being used, the version o= f said browser, and whether or not some new WebRTC SDP feature has been put in the browser's latest release. = And just when we think we have to modify Asterisk to handle the new SDP sen= t by some browser, the browser changes again. As a result, Asterisk 11 hasn= 't changed a lot since we released; we've been trying to avoid coding to a moving target. We always envisioned= that things would quiet down and the browsers would settle on an implement= ation of SDP that we could adapt to - but it doesn't seem like things are q= uieting down as much as we'd like. And sure, the SIP stack in Asterisk is crufty, and sure, sometimes the fau= lt is in our implementation, not the browser's - but I think we on the Aste= risk project can certainly say that relying on SDP hasn't been a panacea fo= r interoperability.
    >
    > It feels like maintaining compatibility with "traditional" S= DP implementations is getting harder for the browsers to manage and holding= the entire process back. As one of those older "traditional" imp= lementations, I'd rather write an entirely new channel driver for Asterisk than have to re-write our SDP handling.
    >
    > So... +1 to Inaki's request.
    >
    > Matt
    >
    > --
    > Matthew Jordan
    > Digium, Inc. | Engineering Manager
    > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
    > Check us out at: http:= //digium.com & http://asterisk.org
    > _______________________________________________
    > rtcweb mailing list
    > rtcweb@ietf.org
    > https://www.ietf.org/mailman/listinfo/rtcweb

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



    Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
    This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
    http://www.tid.es/ES/PAGINAS/disclaimer.aspx
     --Boundary_(ID_V6ZZJSgIEjy7/9AQ98vLpg)-- From pthatcher@google.com Wed Jun 26 17:03:05 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FDD11E814D for ; Wed, 26 Jun 2013 17:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tajDKzX2P-KH for ; Wed, 26 Jun 2013 17:03:04 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 629D521F9A8F for ; Wed, 26 Jun 2013 17:03:04 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so112115pbc.7 for ; Wed, 26 Jun 2013 17:03: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; bh=VU77oS9qlnqqsHnamYEZWTfZTiJTAbKF3u0xXTZg+fc=; b=PV1Ou2ufJiPbjK/5Ny5XVcZOJb7RycRzRgryb8+9XnVVLXpS5FSgJvzvL9dpokIglU ncBsZ/6MGiuI25r5t35bDcrPlvLlt+ELWWCfT6QKiPEtiBRwNNihLilACfqrR444U9Yb 338EOBP5l8YDcYUJrinMFJY4N+ekSSzFSVWQU2RP55lVWq8egCr/5wAqcqv3xw+4bnK7 UxRGRWEQH+Xo2ye8qvngvwAi8NoF1S1om2aBeaH2saM6WhlbcLK+GqHzNNyw1oDZwbeT umlOr5H80dYsm0sGkymm6AO+Pjj/5thiv2qxsUrSJKMtAa9FaUFqLZUqJ7cNtwMp1GPq 5Ikw== 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=VU77oS9qlnqqsHnamYEZWTfZTiJTAbKF3u0xXTZg+fc=; b=ThVq53JFQkulnEOOOIfBjruBkmtX4GFWb3B/r4WaWKmgz3+4t1PG3zU8OpEZ/YzGYy 1/0m58yalF2bPvgRur9Rx+LAAxro7bVnL4dE4AuzShmyi2uIZ7YTNsMr+TeyunwHNN/A OB44nJni8nfl/BmiZdMS3TxjkCGqLOAR5RQs+SEsW13l/O26/vuquPzln9IiUOhpvRS1 kpyuzmtVgMSX36KBmcuEAMpsd1VZ4R3o+drCW9VojF4ZCpiIFlGYTbnX9Rr7QBkZFDzd mSczPPrD6hxjJmSpJBPhjcycUvWjp47krFcdLXpDqISrhtjTRXLfkyFxtFJ0yhIIdOWZ EMrg== X-Received: by 10.68.238.9 with SMTP id vg9mr3161654pbc.66.1372291384097; Wed, 26 Jun 2013 17:03:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.216.163 with HTTP; Wed, 26 Jun 2013 17:02:23 -0700 (PDT) In-Reply-To: References: <5158F0FC.3070104@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02B56F@FR711WXCHMBA02.zeu.alcatel-lucent.com> <5165CF9D.6030302@jesup.org> <782A8339-9A9D-49AE-85E6-9FAD55436807@tokbox.com> From: Peter Thatcher Date: Wed, 26 Jun 2013 17:02:23 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=e89a8ff1ca1a7a578e04e0177cc7 X-Gm-Message-State: ALoCoQmrGUQexssVR9PUeyX4hni1Sz4RNm+s10Vvj7XRJvcOU0Ih2LstYRxBV3we/p23p4sXGMDlrHLbSbm1P75RkibSJJJ1JTCl7iAO2cPrIppR0H6/+jhzdhUJO4Wu5jUHBAcR8jWR9alDxdTE+zcjvbOYOxr8xuJcfZIUwzG2fiL8oFkMR9vud1dY8fSNzgUIayTfoQUD Cc: "" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 00:03:05 -0000 --e89a8ff1ca1a7a578e04e0177cc7 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 26, 2013 at 4:54 PM, Martin Thomson wrote: > On 26 June 2013 16:46, Peter Thatcher wrote: > > You know you're in trouble when CU-RTC-Web is considered "much more > simple" > > :). > > When you are comparing to SDP O/A, pigs start looking like princesses. > Nice. > > > how could you test such a thing, without a working implementation of > CU-RTC-Web? > > > http://html5labs.interoperabilitybridges.com/prototypes/cu-rtc-web-roaming/cu-rtc-web-roaming/info > > Surely that's enough to build a proof of concept application. I'm not > claiming that it's glamorous, far from it, there's some atrocious code > in there, but it's not a complete vacuum. > I didn't realize you had that out there. Thanks for letting me know. --e89a8ff1ca1a7a578e04e0177cc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Wed, Jun 26, 2013 at 4:54 PM, Martin Thomson &= lt;martin.tho= mson@gmail.com> wrote:
    On 26 June 2013 16:46, Pet= er Thatcher <pthatcher@google.co= m> wrote:
    > You know you're in trouble when CU-RTC-Web is considered "muc= h more simple"
    > :).

    When you are comparing to SDP O/A, pigs start looking like princesses= .

    Nice.
    =C2=A0

    > how could you test such a thing, without a working implementation of C= U-RTC-Web?

    http://html5lab= s.interoperabilitybridges.com/prototypes/cu-rtc-web-roaming/cu-rtc-web-roam= ing/info

    Surely that's enough to build a proof of concept application. =C2=A0I&#= 39;m not
    claiming that it's glamorous, far from it, there's some atrocious c= ode
    in there, but it's not a complete vacuum.

    I didn't realize you had that out there. =C2=A0Thanks for lettin= g me know.=C2=A0

    --e89a8ff1ca1a7a578e04e0177cc7-- From martin.thomson@gmail.com Wed Jun 26 17:05:35 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749A521F9A9B for ; Wed, 26 Jun 2013 17:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4WES7iOOqgJ for ; Wed, 26 Jun 2013 17:05:34 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 74FE521F9A97 for ; Wed, 26 Jun 2013 17:05:34 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so64778wes.31 for ; Wed, 26 Jun 2013 17:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LaTYnrJRzAqDxuKlcYi0zvCTDEB0p4BQ0YS4a29gTIc=; b=kf34zKImPupKr+HvPB+X/RXSZERpSYveJgF1T/voNRqB6oLudZZCqivHgIJJZaCuhR vD3CenI2PGzbb9xzDxYhOkI74/7z9jZzjMx7KpawL+bzk1bSD4Q8WSvUekO3KVsj5RIk a3kRW3MYBNTeYjjh4F6dNeVlNydTQXtjlarRyRHNFOfBC1+rZ3qtcmdfAQd5ihGqx7vY lD+ojWc17tvrW112ntmKYNx4d8xAu1a/MafpcxkTpULHDf8+qtZoIQSxASdl1I96x5XG Fnw3GkNlrC8Tsf/X7SS9l7jGIfbLsHmiFOJIalkUj5mERl04ylINrzcmrYGhtkb4t7YH awgw== MIME-Version: 1.0 X-Received: by 10.180.187.235 with SMTP id fv11mr3915929wic.65.1372291533633; Wed, 26 Jun 2013 17:05:33 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 26 Jun 2013 17:05:33 -0700 (PDT) In-Reply-To: References: <5158F0FC.3070104@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02B56F@FR711WXCHMBA02.zeu.alcatel-lucent.com> <5165CF9D.6030302@jesup.org> <782A8339-9A9D-49AE-85E6-9FAD55436807@tokbox.com> Date: Wed, 26 Jun 2013 17:05:33 -0700 Message-ID: From: Martin Thomson To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 00:05:35 -0000 On 26 June 2013 17:02, Peter Thatcher wrote: > I didn't realize you had that out there. Thanks for letting me know. The older version has different demos, I think: http://html5labs.interopbridges.com/prototypes/cu-rtc-web/cu-rtc-web/info From pthatcher@google.com Wed Jun 26 17:12:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1494A11E814D for ; Wed, 26 Jun 2013 17:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeIE6OnZ9oUe for ; Wed, 26 Jun 2013 17:12:57 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C7BFA11E8111 for ; Wed, 26 Jun 2013 17:12:57 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id uo1so122589pbc.3 for ; Wed, 26 Jun 2013 17:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=f70yLduLuYfhyvq+BWDhm9niX7CdzB+S7DD60abqvCw=; b=S17Yq9aaBkruahvqOQsNXjhMn9T/SjwopXy+3HjDhf6ppr3FguUx1/7uRDO7mhTu0m dr4WdFx8yk7hn4p0ItKlgM8+y2mTPQUQNJL+f2fjL3Pw1foRvJOK9v185AqHF6GCZ/4r IYLixjXeE7DEejs5TQ4TY8P/Y3ShzdD4xoKrCvu75+Oz+z5KbWrFAhx1xgqkKqP/4+Dd OFvZpuctdwzY3lAsjshzmwoYvvYUuEsyEWEy0G6uinnYW8U4gr3FCW+duVV57jHJndjP gKZb545K00EPca4NzQzC/xiEgvWL+jMsYyHNihppEX1RFZ2tzVdIHXv/HoaiRLphKwS9 0LLQ== 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=f70yLduLuYfhyvq+BWDhm9niX7CdzB+S7DD60abqvCw=; b=ONRQ3QQg3jidYl1HFwH5qe0XeCfiiA9zG85eg9O6ibO0n7qYtDTYwefzLzb2iwZGzo 6KN6UnJM4V8qTu2t+CotBI56eEGVo1FeC6NtmSGkQeQOwD5iXyU35+dJjUcj3cc5dF6j jyan7C/yJJxBv74kELBEECILnqyTPrvy15QuVyTLNj0F6/fyXYIhp3/rFGJm5txDPPPo Sr29qy0+Sn3kEhPDHuCPVHoRtBidBZrRUYTah0oGn12oz/XfK7zjrkNUBg6FdyfgrdXj 9A8YGmJfwevHzvU95JkNPPM5e8ZBkIuiE73y9+wAVaQ/Mcio5pP7/mwtMulNYgav/Xw4 K1Cw== X-Received: by 10.68.134.103 with SMTP id pj7mr3176317pbb.171.1372291977456; Wed, 26 Jun 2013 17:12:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.216.163 with HTTP; Wed, 26 Jun 2013 17:12:17 -0700 (PDT) In-Reply-To: <6dylyuxdj0v9xctq6nv1tpyy.1372290845930@email.android.com> References: <5158F0FC.3070104@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02B56F@FR711WXCHMBA02.zeu.alcatel-lucent.com> <5165CF9D.6030302@jesup.org> <782A8339-9A9D-49AE-85E6-9FAD55436807@tokbox.com> <6dylyuxdj0v9xctq6nv1tpyy.1372290845930@email.android.com> From: Peter Thatcher Date: Wed, 26 Jun 2013 17:12:17 -0700 Message-ID: To: Gustavo Garcia Bernardo Content-Type: multipart/alternative; boundary=047d7b10cb23d8497804e0179fec X-Gm-Message-State: ALoCoQkwTPVuczPIJAOToIdL8V5GvjrA+pvRnY0aBWdsGEIZhJhQFdgTDCIc2xnEZDMf+8VzOrzMw0GVxEw33gSRsiDd9xZvVDcVeq+1T6rRJdlQB/HtjCDl3m4PfMS1ofabN50tauTEeuncrhXylkRxSt7aLrFia7/U49Wo7CstguY1JngVMgmWaJHMLvUj0dfKIRNwdLPk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 00:12:59 -0000 --047d7b10cb23d8497804e0179fec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 26, 2013 at 4:57 PM, Gustavo Garcia Bernardo wrote= : > Getting the feeling of that silent mayority is what we are doing in this > thread. Hope we can put something together as Robin volunteered to lead. > > Even the "SDP rebellion" aside (by the way, you guys need some Star Wars jokes), it would very useful to have a good idea of who is working on what and how well the API is working for them, and what things could be added or changed to help. Most of the WG does seem to have any real experience actually using the API, and I think that limits are ability to design the right API. More input from people actually using the API could only help, and I look forward to hearing more. There is a working implementation of cu-web-rtc, look for it in Microsoft > html labs page. Obviously my prototype is quick and dirty but you get my > point on what you can do. > > I apologize if I missed the link to your prototype. I'd like to see it. Can you repost the link? > > Sent from mobile > > Peter Thatcher wrote: > > On Wed, Jun 26, 2013 at 4:29 PM, Gustavo Garc=C3=ADa wr= ote: > >> "We reject kings, presidents and voting. We believe in rough consensus >> and running code". (IETF TAO) >> >> - Lot of developers building stuff beyond a PSTN interconnection demo ar= e >> having problems with the existing model. Complexity, limitations and >> incompatibilities make us feel like fighting an API instead of using it. >> - There are a lot of issues (bugs, incompatibilities, feature requests) >> because of SDP and O/A. Take a look at webrtc issue tracker. >> - The actual experience of people using the API should be a stronger >> argument than a voting done one year ago. Specially when most of >> developers are not participating in IETF voting and after realizing the >> implications of SDP and O/A model f.e. on all those endless Plan-XXX >> discussions. >> > > If there's a great "silent majority" out there, I think it would help > the WG a lot for them to come on the forum and give clear, concrete > examples (not ranty, please) of what they're trying to do and what their > pain points are. I think that's much more helpful than just remaining > silently in pain. On the flip side, if app developers love using the > current API and think SDP O/A is great, they should express that as well. > > >> - There is a much more simple solution (something like CU-RTC-Web) and >> you can always write a SDP/O/A/PeerConnection API on top of it (I had a >> prototype working in a couple of hours), but the other way around is muc= h >> more hard if not impossible. >> > > You know you're in trouble when CU-RTC-Web is considered "much more > simple" :). > > I think your "bulid RtcPeerConnection on top in JS" is a great idea, but > you had a prototype in a couple of hours? I have a hard time you could > implement much of SDP O/A correctly in a couple of ours. And how could y= ou > test such a thing, without a working implementation of CU-RTC-Web? > > >> In my opinion the only reasonable approaches are: >> - Change the API now >> - Change the API in one year >> >> > You could add: > > - Change the API every couple weeks by changing what SDP is > generated/supported. > > > :) > > +1 to I=C3=B1aki's request too >> >> G. >> >> On 18/06/2013, at 15:19, Matthew Jordan wrote: >> >> > >> > On Tue, Jun 18, 2013 at 1:22 PM, Adrian Georgescu >> wrote: >> > +1 >> > >> > While working with the specs, some may have realised that SDP is not >> such a great idea to put in practice and may also want to come forward t= o >> admit their mistake. >> > >> > Regards, >> > Adrian >> > >> > >> > In the Asterisk project, we were able to use our legacy SIP stack to >> enable very basic WebRTC communication with Chrome and FireFox. That sou= nds >> nice, until you realize we have to continually preface that with >> "sometimes". >> > >> > Because the answer is, more often than not, something breaks. >> Invariably, the breakages have been in the SDPs sent to Asterisk by the >> browser. What SDP breaks us changes depending on the browser being used, >> the version of said browser, and whether or not some new WebRTC SDP feat= ure >> has been put in the browser's latest release. And just when we think we >> have to modify Asterisk to handle the new SDP sent by some browser, the >> browser changes again. As a result, Asterisk 11 hasn't changed a lot sin= ce >> we released; we've been trying to avoid coding to a moving target. We >> always envisioned that things would quiet down and the browsers would >> settle on an implementation of SDP that we could adapt to - but it doesn= 't >> seem like things are quieting down as much as we'd like. And sure, the S= IP >> stack in Asterisk is crufty, and sure, sometimes the fault is in our >> implementation, not the browser's - but I think we on the Asterisk proje= ct >> can certainly say that relying on SDP hasn't been a panacea for >> interoperability. >> > >> > It feels like maintaining compatibility with "traditional" SDP >> implementations is getting harder for the browsers to manage and holding >> the entire process back. As one of those older "traditional" >> implementations, I'd rather write an entirely new channel driver for >> Asterisk than have to re-write our SDP handling. >> > >> > So... +1 to Inaki's request. >> > >> > Matt >> > >> > -- >> > Matthew Jordan >> > Digium, Inc. | Engineering Manager >> > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> > Check us out at: http://digium.com & http://asterisk.org >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > ------------------------------ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n de correo electr=C3= =B3nico en el enlace > situado m=C3=A1s abajo. > This message is intended exclusively for its addressee. We only send and > receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > --047d7b10cb23d8497804e0179fec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On Wed, Jun 26, 2013 at 4:57 PM, Gustavo Garcia Bernardo <= span dir=3D"ltr"><ggb@ti= d.es> wrote:
    Getting the feeling of that silent mayority is what we are doing in th= is thread. =C2=A0Hope we can put something together as Robin volunteered to= lead.


    Even the "SDP re= bellion" aside (by the way, you guys need some Star Wars jokes), it wo= uld very useful to have a good idea of who is working on what and how well = the API is working for them, and what things could be added or changed to h= elp. =C2=A0 Most of the WG does seem to have any real experience actually u= sing the API, and I think that limits are ability to design the right API. = =C2=A0More input from people actually using the API could only help, and I = look forward to hearing more. =C2=A0

    There is a working implementation of cu-web-rtc, look for it in Micros= oft html labs page. =C2=A0Obviously my prototype is quick and dirty but you= get my point on what you can do.


    I apologize if I miss= ed the link to your prototype. =C2=A0I'd like to see it. =C2=A0Can you = repost the link?
    =C2=A0

    Sent from mobile

    Peter Thatcher <pthatcher@google.com> wrote:

    On Wed, Jun 26, 2013 at 4:29 PM, Gustavo Garc=C3= =ADa <ggb@tokbox.com&= gt; wrote:
    "We reject kings, presidents and voting. We believe in rough consensus= and running code". (IETF TAO)

    - Lot of developers building stuff beyond a PSTN interconnection demo are h= aving problems with the existing model. =C2=A0 Complexity, limitations and = incompatibilities make us feel like fighting an API instead of using it. - There are a lot of issues (bugs, incompatibilities, feature requests) bec= ause of SDP and O/A. =C2=A0Take a look at webrtc issue tracker.
    - The actual experience of people using the API should be a stronger argume= nt than a voting done one year ago. =C2=A0Specially when most of developers= are not participating in IETF voting and after realizing the implications = of SDP and O/A model f.e. on all those endless Plan-XXX =C2=A0discussions.

    If there's a great "silent majority" out there, I think = it would help the WG a lot for them to come on the forum and give clear, co= ncrete examples (not ranty, please) of what they're trying to do and wh= at their pain points are. =C2=A0 I think that's much more helpful than just remaining silently in pain. =C2=A0On the flip side, if a= pp developers love using the current API and think SDP O/A is great, they s= hould express that as well.
    =C2=A0 =C2=A0
    - There is a much more simple solution (something like CU-RTC-Web) and you = can always write a SDP/O/A/PeerConnection API on top of it (I had a prototy= pe working in a couple of hours), but the other way around is much more har= d if not impossible.

    You know you're in trouble when CU-RTC-Web is considered "muc= h more simple" :).

    I think your "bulid RtcPeerConnection on top in JS" is a gre= at idea, but you had a prototype in a couple of hours? =C2=A0I have a hard = time you could implement much of SDP O/A correctly in a couple of ours. =C2= =A0And how could you test such a thing, without a working implementation of CU-RTC-Web?
    =C2=A0
    In my opinion the only reasonable approaches are:
    - Change the API now
    - Change the API in one year


    You could add:

    - Change the API every couple weeks by changing what SDP is generated/= supported.
    =C2=A0

    :)

    +1 to I=C3=B1aki's request too

    G.

    On 18/06/2013, at 15:19, Matthew Jordan wrote:

    >
    > On Tue, Jun 18, 2013 at 1:22 PM, Adrian Georgescu <ag@ag-projects.com> wrote: > +1
    >
    > While working with the specs, some may have realised that SDP is not s= uch a great idea to put in practice and may also want to come forward to ad= mit their mistake.
    >
    > Regards,
    > Adrian
    >
    >
    > In the Asterisk project, we were able to use our legacy SIP stack to e= nable very basic WebRTC communication with Chrome and FireFox. That sounds = nice, until you realize we have to continually preface that with "some= times".
    >
    > Because the answer is, more often than not, something breaks. Invariab= ly, the breakages have been in the SDPs sent to Asterisk by the browser. Wh= at SDP breaks us changes depending on the browser being used, the version o= f said browser, and whether or not some new WebRTC SDP feature has been put in the browser's latest relea= se. And just when we think we have to modify Asterisk to handle the new SDP= sent by some browser, the browser changes again. As a result, Asterisk 11 = hasn't changed a lot since we released; we've been trying to avoid coding to a moving target. We always envisi= oned that things would quiet down and the browsers would settle on an imple= mentation of SDP that we could adapt to - but it doesn't seem like thin= gs are quieting down as much as we'd like. And sure, the SIP stack in Asterisk is crufty, and sure, sometimes the fau= lt is in our implementation, not the browser's - but I think we on the = Asterisk project can certainly say that relying on SDP hasn't been a pa= nacea for interoperability.
    >
    > It feels like maintaining compatibility with "traditional" S= DP implementations is getting harder for the browsers to manage and holding= the entire process back. As one of those older "traditional" imp= lementations, I'd rather write an entirely new channel driver for Asterisk than have to re-write our SDP handling.
    >
    > So... +1 to Inaki's request.
    >
    > Matt
    >
    > --
    > Matthew Jordan
    > Digium, Inc. | Engineering Manager
    > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
    > Check us out at: http:= //digium.com & http://asterisk.org
    > _______________________________________________
    > rtcweb mailing list
    > rtcweb@ietf.org
    >     https://www.ietf.org/mailman/listinfo/rtcweb

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



    Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n de correo electr=C3=B3ni= co en el enlace situado m=C3=A1s abajo.
    This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
    = http://www.tid.es/ES/PAGINAS/disclaimer.aspx

    --047d7b10cb23d8497804e0179fec-- From bernard_aboba@hotmail.com Wed Jun 26 17:19:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94CA11E816D for ; Wed, 26 Jun 2013 17:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tM7MUH+ARuM for ; Wed, 26 Jun 2013 17:19:49 -0700 (PDT) Received: from blu0-omc1-s27.blu0.hotmail.com (blu0-omc1-s27.blu0.hotmail.com [65.55.116.38]) by ietfa.amsl.com (Postfix) with ESMTP id 207D011E814D for ; Wed, 26 Jun 2013 17:19:49 -0700 (PDT) Received: from BLU403-EAS148 ([65.55.116.7]) by blu0-omc1-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jun 2013 17:19:46 -0700 X-TMN: [BmfGB+qEs9StH3s303vYdYObAH2dAXZQ] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail-67A4D29A-9B6A-45F8-987D-1F665A39AAB8" Content-Transfer-Encoding: 7bit References: <51BF5F00.90705@jitsi.org> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Wed, 26 Jun 2013 17:19:41 -0700 To: Peter Thatcher X-OriginalArrivalTime: 27 Jun 2013 00:19:46.0305 (UTC) FILETIME=[07618710:01CE72CC] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 00:19:54 -0000 --Apple-Mail-67A4D29A-9B6A-45F8-987D-1F665A39AAB8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do think No Plan represents progress toward containing the SDP monster in W= ebRTC 1.0, particularly for video scenarios. However, I also agree with Robi= n's arguments against SDP and O/ A, particularly for a server-side API (e.g.= Node.js modules) where the current API makes no sense at all. So my perspec= tive is to contain the monster in 1.0, then go with 2.0 first on server, the= n on the browser.=20 On Jun 17, 2013, at 10:34 PM, "Peter Thatcher" wrote:= > I like your comparison to the data channels. As I just pointed out in ano= ther email, I think it was good that we "contained the SDP monster", as you p= ut it, with createDataChannel. One of the purposes of createLocalStream/cre= ateRemoteStream is to allow a JS app, if it chooses, to "contain the SDP mon= ster" when adding media streams. It would still be needed for setting up th= e PeerConnection's transport (a monster container for a future day perhaps),= but that's still significant progress in my book, and it does so with simpl= e additions to the PeerConnection that don't attempt to blow up the WG. >=20 >=20 > On Mon, Jun 17, 2013 at 5:14 PM, Bernard Aboba = wrote: >> =20 >> =20 >> 2) Dissadvantages of using SDP in WebRTC. >>=20 >> Roman said: >> "An unmanageable monster was created which currently stays in the way of d= eveloping new functionality (bundle), building applications (does not provid= e obvious ways to implement obvious tasks, like adding an extra stream witho= ut re-negotiating all the existing ones) and even interop with existing SIP e= ndpoints (which was the original but now is complicated since it would requi= re a non trivial set of constraints and subsequent SDP manipulation)." >> =20 >> [BA] Hard to argue with this, but I would point out that by far the uglie= st part of the monster is the video hindquarters. While one could argue tha= t we have been living with the warts of SDP for audio and therefore know the= workarounds, with video there are substantial interoperability issues, *eve= n among vendors who utilize the same codec*, sometimes even in relatively ba= sic scenarios (e.g. P2P video call with H.264/SVC). So the "multivendor leg= acy of interop" just doesn't exist yet (at least, based on standards). >> =20 >> So as I see it, it does represent progress that we have contained the SDP= monster's impact on the the data channel, and I welcome Peter's effort to e= nable applications who don't care about SDP to minimize its usage even if it= is not eliminated entirely. =20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 --Apple-Mail-67A4D29A-9B6A-45F8-987D-1F665A39AAB8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+SSBkbyB0 aGluayBObyBQbGFuIHJlcHJlc2VudHMgcHJvZ3Jlc3MgdG93YXJkIGNvbnRhaW5pbmcgdGhlIFNE UCBtb25zdGVyIGluIFdlYlJUQyAxLjAsIHBhcnRpY3VsYXJseSBmb3IgdmlkZW8gc2NlbmFyaW9z LiBIb3dldmVyLCBJIGFsc28gYWdyZWUgd2l0aCBSb2JpbidzIGFyZ3VtZW50cyBhZ2FpbnN0IFNE UCBhbmQgTy8gQSwgcGFydGljdWxhcmx5IGZvciBhIHNlcnZlci1zaWRlIEFQSSAoZS5nLiBOb2Rl LmpzIG1vZHVsZXMpIHdoZXJlIHRoZSBjdXJyZW50IEFQSSBtYWtlcyBubyBzZW5zZSBhdCBhbGwu IFNvIG15IHBlcnNwZWN0aXZlIGlzIHRvIGNvbnRhaW4gdGhlIG1vbnN0ZXIgaW4gMS4wLCB0aGVu IGdvIHdpdGggMi4wIGZpcnN0IG9uIHNlcnZlciwgdGhlbiBvbiB0aGUgYnJvd3Nlci4mbmJzcDs8 L2Rpdj48ZGl2Pjxicj5PbiBKdW4gMTcsIDIwMTMsIGF0IDEwOjM0IFBNLCAiUGV0ZXIgVGhhdGNo ZXIiICZsdDs8YSBocmVmPSJtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20iPnB0aGF0Y2hlckBn b29nbGUuY29tPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48ZGl2PjxkaXYgZGlyPSJsdHIiPkkgbGlrZSB5b3VyIGNvbXBhcmlzb24gdG8gdGhlIGRh dGEgY2hhbm5lbHMuICZuYnNwO0FzIEkganVzdCBwb2ludGVkIG91dCBpbiBhbm90aGVyIGVtYWls LCBJIHRoaW5rIGl0IHdhcyBnb29kIHRoYXQgd2UgImNvbnRhaW5lZCB0aGUgU0RQIG1vbnN0ZXIi LCBhcyB5b3UgcHV0IGl0LCB3aXRoIGNyZWF0ZURhdGFDaGFubmVsLiAmbmJzcDtPbmUgb2YgdGhl IHB1cnBvc2VzIG9mIGNyZWF0ZUxvY2FsU3RyZWFtL2NyZWF0ZVJlbW90ZVN0cmVhbSBpcyB0byBh bGxvdyBhIEpTIGFwcCwgaWYgaXQgY2hvb3NlcywgdG8gImNvbnRhaW4gdGhlIFNEUCBtb25zdGVy IiB3aGVuIGFkZGluZyBtZWRpYSBzdHJlYW1zLiAmbmJzcDtJdCB3b3VsZCBzdGlsbCBiZSBuZWVk ZWQgZm9yIHNldHRpbmcgdXAgdGhlIFBlZXJDb25uZWN0aW9uJ3MgdHJhbnNwb3J0IChhIG1vbnN0 ZXIgY29udGFpbmVyIGZvciBhIGZ1dHVyZSBkYXkgcGVyaGFwcyksIGJ1dCB0aGF0J3Mgc3RpbGwg c2lnbmlmaWNhbnQgcHJvZ3Jlc3MgaW4gbXkgYm9vaywgYW5kIGl0IGRvZXMgc28gd2l0aCBzaW1w bGUgYWRkaXRpb25zIHRvIHRoZSBQZWVyQ29ubmVjdGlvbiB0aGF0IGRvbid0IGF0dGVtcHQgdG8g YmxvdyB1cCB0aGUgV0cuPC9kaXY+DQoNCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGJy PjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBNb24sIEp1biAxNywgMjAxMyBhdCA1OjE0IFBN LCBCZXJuYXJkIEFib2JhIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmJlcm5h cmRfYWJvYmFAaG90bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5iZXJuYXJkX2Fib2JhQGhvdG1h aWwuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCg0KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mg c29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQoNCg0KPGRpdj48ZGl2IGRpcj0ibHRyIj4mbmJzcDs8 YnI+PGRpdj48ZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9InBhZGRpbmct bGVmdDoxZXg7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTtib3JkZXItbGVmdC13 aWR0aDoxcHg7Ym9yZGVyLWxlZnQtc3R5bGU6c29saWQiPg0KMikgRGlzc2FkdmFudGFnZXMgb2Yg dXNpbmcgU0RQIGluIFdlYlJUQy48L2Jsb2NrcXVvdGU+PGRpdiBjbGFzcz0iaW0iPjxkaXY+PGJy PjwvZGl2PjxkaXY+Um9tYW4gc2FpZDo8L2Rpdj48ZGl2PiJBbiB1bm1hbmFnZWFibGUgbW9uc3Rl ciB3YXMgY3JlYXRlZCB3aGljaCBjdXJyZW50bHkgc3RheXMgaW4gdGhlIHdheSBvZiBkZXZlbG9w aW5nIG5ldyBmdW5jdGlvbmFsaXR5IChidW5kbGUpLCBidWlsZGluZyBhcHBsaWNhdGlvbnMgKGRv ZXMgbm90IHByb3ZpZGUgb2J2aW91cyB3YXlzIHRvIGltcGxlbWVudCBvYnZpb3VzIHRhc2tzLCBs aWtlIGFkZGluZyBhbiBleHRyYSBzdHJlYW0gd2l0aG91dCByZS1uZWdvdGlhdGluZyBhbGwgdGhl IGV4aXN0aW5nIG9uZXMpIGFuZCBldmVuIGludGVyb3Agd2l0aCBleGlzdGluZyBTSVAgZW5kcG9p bnRzICh3aGljaCB3YXMgdGhlIG9yaWdpbmFsIGJ1dCBub3cgaXMgY29tcGxpY2F0ZWQgc2luY2Ug aXQgd291bGQgcmVxdWlyZSBhIG5vbiB0cml2aWFsIHNldCBvZiBjb25zdHJhaW50cyBhbmQgc3Vi c2VxdWVudCBTRFAgbWFuaXB1bGF0aW9uKS4iPC9kaXY+DQoNCjxkaXY+Jm5ic3A7PC9kaXY+PC9k aXY+PGRpdj5bQkFdIEhhcmQgdG8gYXJndWUgd2l0aCB0aGlzLCBidXQgSSB3b3VsZCBwb2ludCBv dXQgdGhhdCBieSBmYXIgdGhlIHVnbGllc3QgcGFydCBvZiB0aGUgbW9uc3RlciBpcyB0aGUgdmlk ZW8gaGluZHF1YXJ0ZXJzLiZuYnNwOyBXaGlsZSBvbmUgY291bGQgYXJndWUgdGhhdCB3ZSBoYXZl IGJlZW4gbGl2aW5nIHdpdGggdGhlIHdhcnRzIG9mIFNEUCBmb3IgYXVkaW8gYW5kIHRoZXJlZm9y ZSBrbm93IHRoZSB3b3JrYXJvdW5kcywgd2l0aCB2aWRlbyB0aGVyZSBhcmUgc3Vic3RhbnRpYWwg aW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMsICpldmVuIGFtb25nIHZlbmRvcnMgd2hvIHV0aWxpemUg dGhlIHNhbWUgY29kZWMqLCZuYnNwO3NvbWV0aW1lcyBldmVuIGluIHJlbGF0aXZlbHkgYmFzaWMg c2NlbmFyaW9zIChlLmcuIFAyUCB2aWRlbyBjYWxsIHdpdGggSC4yNjQvU1ZDKS4mbmJzcDsgU28g dGhlICJtdWx0aXZlbmRvciBsZWdhY3kgb2YgaW50ZXJvcCIganVzdCBkb2Vzbid0IGV4aXN0IHll dCAoYXQgbGVhc3QsIGJhc2VkIG9uIHN0YW5kYXJkcykuIDwvZGl2Pg0KDQo8ZGl2PiZuYnNwOzwv ZGl2PjxkaXY+U28gYXMgSSBzZWUgaXQsIGl0IGRvZXMgcmVwcmVzZW50IHByb2dyZXNzIHRoYXQg d2UgaGF2ZSZuYnNwO2NvbnRhaW5lZCB0aGUgU0RQIG1vbnN0ZXIncyZuYnNwO2ltcGFjdCBvbiB0 aGUmbmJzcDsgdGhlIGRhdGEgY2hhbm5lbCwgYW5kIEkgd2VsY29tZSBQZXRlcidzIGVmZm9ydCB0 byBlbmFibGUgYXBwbGljYXRpb25zIHdobyBkb24ndCBjYXJlIGFib3V0IFNEUCB0byBtaW5pbWl6 ZSBpdHMgdXNhZ2UgZXZlbiBpZiBpdCBpcyBub3QgZWxpbWluYXRlZCBlbnRpcmVseS4mbmJzcDsg Jm5ic3A7PC9kaXY+DQoNCjwvZGl2PjwvZGl2PiAJCSAJICAgCQkgIDwvZGl2PjwvZGl2Pg0KPGJy Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRj d2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0 Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxicj4NCjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+ PGJyPjwvZGl2Pg0KPC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --Apple-Mail-67A4D29A-9B6A-45F8-987D-1F665A39AAB8-- From marc@mocet.com Wed Jun 26 20:05:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D03B11E818D for ; Wed, 26 Jun 2013 20:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xwm3LJGAofdY for ; Wed, 26 Jun 2013 20:05:15 -0700 (PDT) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5124811E80F0 for ; Wed, 26 Jun 2013 20:05:15 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id md12so279378pbc.16 for ; Wed, 26 Jun 2013 20:05:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=QgpFXVSItvMmRZHyqpEdOfEin20Xq9aLchpd13Ya3DM=; b=O4WCIWJ8D8/8Fs0k7NZi0mlWV8uqQ8sz/q/S19skC5/jREEF0Yv6okn8Uo0ZeiQzdk J+OBTRHXJiV4WcLwobcrXi8yCNo/BXKrBbCmZJWAi6Il6en3Qx2wbhiYAfRe+UI7hsav Xk3XxLFQsra7hDTWLXpQpv7YQtXdlbiBqruZPjFv4R1f71aONnR8t83ooN4gafpOVmw3 96l3EPD11nNYovgZ7HgNwVlxXoe+IZtkUcQu1MozQeEvURWpKuhMG9owklFSu5kuWbc0 Job6S2K4M92pjI8tL86Sp9gWXBLl3GfDy39ojx19J+t/GwCP5uwQ43+/tnZRRwRW2yfP k0Vg== X-Received: by 10.67.2.7 with SMTP id bk7mr3677340pad.50.1372302314855; Wed, 26 Jun 2013 20:05:14 -0700 (PDT) Received: from [10.0.1.18] (cpe-76-90-18-226.socal.res.rr.com. [76.90.18.226]) by mx.google.com with ESMTPSA id xu10sm1466652pab.3.2013.06.26.20.05.12 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 20:05:13 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_EDFEA9CD-A5B0-4B2E-B7B8-DD2843A2AAE2" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1780.1\)) From: Marc Abrams In-Reply-To: Date: Wed, 26 Jun 2013 20:05:12 -0700 Message-Id: References: <5158F0FC.3070104@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02B56F@FR711WXCHMBA02.zeu.alcatel-lucent.com> <5165CF9D.6030302@jesup.org> <782A8339-9A9D-49AE-85E6-9FAD55436807@tokbox.com> <6dylyuxdj0v9xctq6nv1tpyy.1372290845930@email.android.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1780.1) X-Gm-Message-State: ALoCoQnp8bdHa0PbVLGrzpKocOZi50w6RVQmhsDdy1hGWA0JOzwIsOiXxgfBWmCwABuxkZmj5tZl Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 03:05:31 -0000 --Apple-Mail=_EDFEA9CD-A5B0-4B2E-B7B8-DD2843A2AAE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It=92s pretty telling when you have Digium and others making statements = like =93...that relying on SDP hasn't been a panacea for = interoperability, =93 or =93... [they would] rather write an entirely = new channel driver for Asterisk than have to re-write [their] SDP = handling, =93 you know that it=92s not =93just=94 an SDB Rebellion. It=92s= a problem. And waving your hands and claiming it=92s necessary does not = make SDP the solution.=20 We should punt on SDP for v1.0 and move on.=20 Thanks. marc. __________________ +1-949-270-0935 On Jun 26, 2013, at 5:12 PM, Peter Thatcher = wrote: > On Wed, Jun 26, 2013 at 4:57 PM, Gustavo Garcia Bernardo = wrote: > Getting the feeling of that silent mayority is what we are doing in = this thread. Hope we can put something together as Robin volunteered to = lead. >=20 >=20 > Even the "SDP rebellion" aside (by the way, you guys need some Star = Wars jokes), it would very useful to have a good idea of who is working = on what and how well the API is working for them, and what things could = be added or changed to help. Most of the WG does seem to have any real = experience actually using the API, and I think that limits are ability = to design the right API. More input from people actually using the API = could only help, and I look forward to hearing more. =20 >=20 > There is a working implementation of cu-web-rtc, look for it in = Microsoft html labs page. Obviously my prototype is quick and dirty but = you get my point on what you can do. >=20 >=20 > I apologize if I missed the link to your prototype. I'd like to see = it. Can you repost the link? > =20 >=20 > Sent from mobile >=20 > Peter Thatcher wrote: >=20 > On Wed, Jun 26, 2013 at 4:29 PM, Gustavo Garc=EDa = wrote: > "We reject kings, presidents and voting. We believe in rough consensus = and running code". (IETF TAO) >=20 > - Lot of developers building stuff beyond a PSTN interconnection demo = are having problems with the existing model. Complexity, limitations = and incompatibilities make us feel like fighting an API instead of using = it. > - There are a lot of issues (bugs, incompatibilities, feature = requests) because of SDP and O/A. Take a look at webrtc issue tracker. > - The actual experience of people using the API should be a stronger = argument than a voting done one year ago. Specially when most of = developers are not participating in IETF voting and after realizing the = implications of SDP and O/A model f.e. on all those endless Plan-XXX = discussions. >=20 > If there's a great "silent majority" out there, I think it would help = the WG a lot for them to come on the forum and give clear, concrete = examples (not ranty, please) of what they're trying to do and what their = pain points are. I think that's much more helpful than just remaining = silently in pain. On the flip side, if app developers love using the = current API and think SDP O/A is great, they should express that as = well. > =20 > - There is a much more simple solution (something like CU-RTC-Web) and = you can always write a SDP/O/A/PeerConnection API on top of it (I had a = prototype working in a couple of hours), but the other way around is = much more hard if not impossible. >=20 > You know you're in trouble when CU-RTC-Web is considered "much more = simple" :). >=20 > I think your "bulid RtcPeerConnection on top in JS" is a great idea, = but you had a prototype in a couple of hours? I have a hard time you = could implement much of SDP O/A correctly in a couple of ours. And how = could you test such a thing, without a working implementation of = CU-RTC-Web? > =20 > In my opinion the only reasonable approaches are: > - Change the API now > - Change the API in one year >=20 >=20 > You could add: >=20 > - Change the API every couple weeks by changing what SDP is = generated/supported. > =20 >=20 > :) >=20 > +1 to I=F1aki's request too >=20 > G. >=20 > On 18/06/2013, at 15:19, Matthew Jordan wrote: >=20 > > > > On Tue, Jun 18, 2013 at 1:22 PM, Adrian Georgescu = wrote: > > +1 > > > > While working with the specs, some may have realised that SDP is not = such a great idea to put in practice and may also want to come forward = to admit their mistake. > > > > Regards, > > Adrian > > > > > > In the Asterisk project, we were able to use our legacy SIP stack to = enable very basic WebRTC communication with Chrome and FireFox. That = sounds nice, until you realize we have to continually preface that with = "sometimes". > > > > Because the answer is, more often than not, something breaks. = Invariably, the breakages have been in the SDPs sent to Asterisk by the = browser. What SDP breaks us changes depending on the browser being used, = the version of said browser, and whether or not some new WebRTC SDP = feature has been put in the browser's latest release. And just when we = think we have to modify Asterisk to handle the new SDP sent by some = browser, the browser changes again. As a result, Asterisk 11 hasn't = changed a lot since we released; we've been trying to avoid coding to a = moving target. We always envisioned that things would quiet down and the = browsers would settle on an implementation of SDP that we could adapt to = - but it doesn't seem like things are quieting down as much as we'd = like. And sure, the SIP stack in Asterisk is crufty, and sure, sometimes = the fault is in our implementation, not the browser's - but I think we = on the Asterisk project can certainly say that relying on SDP hasn't = been a panacea for interoperability. > > > > It feels like maintaining compatibility with "traditional" SDP = implementations is getting harder for the browsers to manage and holding = the entire process back. As one of those older "traditional" = implementations, I'd rather write an entirely new channel driver for = Asterisk than have to re-write our SDP handling. > > > > So... +1 to Inaki's request. > > > > Matt > > > > -- > > Matthew Jordan > > Digium, Inc. | Engineering Manager > > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > > Check us out at: http://digium.com & http://asterisk.org > > _______________________________________________ > > 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 > Este mensaje se dirige exclusivamente a su destinatario. Puede = consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo = electr=F3nico en el enlace situado m=E1s abajo. > This message is intended exclusively for its addressee. We only send = and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_EDFEA9CD-A5B0-4B2E-B7B8-DD2843A2AAE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 It=92s = pretty telling when you have Digium and others making statements like = =93...that relying on SDP hasn't been a panacea for interoperability, =93 = or =93... [they would] rather write an entirely new channel driver for = Asterisk than have to re-write [their] SDP handling, =93 you know that = it=92s not =93just=94 an SDB Rebellion. It=92s a problem. And waving = your hands and claiming it=92s necessary does not make SDP the = solution. 

    We should punt on SDP for v1.0 and = move = on. 

    Thanks.

    marc.
    <= div>
    pthatcher@google.com> = wrote:

    On Wed, Jun 26, 2013 at 4:57 PM, Gustavo Garcia = Bernardo <ggb@tid.es> wrote:
    Getting the feeling = of that silent mayority is what we are doing in this thread.  Hope = we can put something together as Robin volunteered to = lead.


    Even the "SDP = rebellion" aside (by the way, you guys need some Star Wars jokes), it = would very useful to have a good idea of who is working on what and how = well the API is working for them, and what things could be added or = changed to help.   Most of the WG does seem to have any real = experience actually using the API, and I think that limits are ability = to design the right API.  More input from people actually using the = API could only help, and I look forward to hearing more. =  

    There is a working implementation of = cu-web-rtc, look for it in Microsoft html labs page.  Obviously my = prototype is quick and dirty but you get my point on what you can = do.


    I apologize if = I missed the link to your prototype.  I'd like to see it.  Can = you repost the link?
     

    Sent from mobile

    Peter Thatcher <pthatcher@google.com> wrote:

    On = Wed, Jun 26, 2013 at 4:29 PM, Gustavo Garc=EDa <ggb@tokbox.com> wrote:
    "We reject kings, = presidents and voting. We believe in rough consensus and running code". = (IETF TAO)

    - Lot of developers building stuff beyond a PSTN = interconnection demo are having problems with the existing model.   = Complexity, limitations and incompatibilities make us feel like fighting = an API instead of using it.
    - There are a lot of issues (bugs, = incompatibilities, feature requests) because of SDP and O/A.  Take = a look at webrtc issue tracker.
    - The actual experience of people = using the API should be a stronger argument than a voting done one year = ago.  Specially when most of developers are not participating in = IETF voting and after realizing the implications of SDP and O/A model = f.e. on all those endless Plan-XXX =  discussions.

    If there's a = great "silent majority" out there, I think it would help the WG a lot = for them to come on the forum and give clear, concrete examples (not = ranty, please) of what they're trying to do and what their pain points = are.   I think that's much more helpful than just remaining = silently in pain.  On the flip side, if app developers love using = the current API and think SDP O/A is great, they should express that as = well.
       
    - There is a much more simple solution (something = like CU-RTC-Web) and you can always write a SDP/O/A/PeerConnection API = on top of it (I had a prototype working in a couple of hours), but the = other way around is much more hard if not = impossible.

    You know you're in = trouble when CU-RTC-Web is considered "much more simple" = :).

    I think your "bulid RtcPeerConnection on = top in JS" is a great idea, but you had a prototype in a couple of = hours?  I have a hard time you could implement much of SDP O/A = correctly in a couple of ours.  And how could you test such a = thing, without a working implementation of = CU-RTC-Web?
     
    In my opinion the only reasonable approaches = are:
    - Change the API now
    - Change the API in one = year


    You could = add:

    - Change the API every couple weeks by = changing what SDP is = generated/supported.
     

    :)

    +1 to I=F1aki's request too

    G.

    On 18/06/2013, at = 15:19, Matthew Jordan wrote:

    >
    > On Tue, Jun 18, 2013 at = 1:22 PM, Adrian Georgescu <ag@ag-projects.com> wrote:
    > = +1
    >
    > While working with the specs, some may have realised = that SDP is not such a great idea to put in practice and may also want = to come forward to admit their mistake.
    >
    > Regards,
    > = Adrian
    >
    >
    > In the Asterisk project, we were able to = use our legacy SIP stack to enable very basic WebRTC communication with = Chrome and FireFox. That sounds nice, until you realize we have to = continually preface that with "sometimes".
    >
    > Because the = answer is, more often than not, something breaks. Invariably, the = breakages have been in the SDPs sent to Asterisk by the browser. What = SDP breaks us changes depending on the browser being used, the version = of said browser, and whether or not some new WebRTC SDP feature has been = put in the browser's latest release. And just when we think we have to = modify Asterisk to handle the new SDP sent by some browser, the browser = changes again. As a result, Asterisk 11 hasn't changed a lot since we = released; we've been trying to avoid coding to a moving target. We = always envisioned that things would quiet down and the browsers would = settle on an implementation of SDP that we could adapt to - but it = doesn't seem like things are quieting down as much as we'd like. And = sure, the SIP stack in Asterisk is crufty, and sure, sometimes the fault = is in our implementation, not the browser's - but I think we on the = Asterisk project can certainly say that relying on SDP hasn't been a = panacea for interoperability.
    >
    > It feels like maintaining = compatibility with "traditional" SDP implementations is getting harder = for the browsers to manage and holding the entire process back. As one = of those older "traditional" implementations, I'd rather write an = entirely new channel driver for Asterisk than have to re-write our SDP = handling.
    >
    > So... +1 to Inaki's request.
    >
    > = Matt
    >
    > --
    > Matthew Jordan
    > Digium, Inc. | = Engineering Manager
    > 445 Jan Davis Drive NW - Huntsville, AL = 35806 - USA
    > Check us out at: http://digium.com & http://asterisk.org
    > = _______________________________________________
    > rtcweb mailing = list
    > rtcweb@ietf.org
    > https://www.ietf.org/mailman/listinfo/rtcweb

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



    Este mensaje se dirige = exclusivamente a su destinatario. Puede consultar nuestra pol=EDtica de = env=EDo y recepci=F3n de correo electr=F3nico en el enlace situado m=E1s = abajo.
    This message is intended exclusively for its addressee. We = only send and receive email on the basis of the terms set out at:
    http://www.tid.es/ES/PAGINAS/disclaimer.aspx

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

    <= /html>= --Apple-Mail=_EDFEA9CD-A5B0-4B2E-B7B8-DD2843A2AAE2-- From bernard_aboba@hotmail.com Wed Jun 26 20:08:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4DB11E80E9 for ; Wed, 26 Jun 2013 20:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.651 X-Spam-Level: X-Spam-Status: No, score=-101.651 tagged_above=-999 required=5 tests=[AWL=-0.448, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFsbM57Ga-7W for ; Wed, 26 Jun 2013 20:08:09 -0700 (PDT) Received: from blu0-omc1-s14.blu0.hotmail.com (blu0-omc1-s14.blu0.hotmail.com [65.55.116.25]) by ietfa.amsl.com (Postfix) with ESMTP id D961F11E80F3 for ; Wed, 26 Jun 2013 20:08:07 -0700 (PDT) Received: from BLU404-EAS396 ([65.55.116.7]) by blu0-omc1-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jun 2013 20:08:06 -0700 X-TMN: [fhsb7D0YB6xJETDyIXHwDqNPKXOWx4iy] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Wed, 26 Jun 2013 17:29:12 -0700 To: Peter Thatcher X-OriginalArrivalTime: 27 Jun 2013 03:08:06.0280 (UTC) FILETIME=[8B6F6880:01CE72E3] Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 03:08:15 -0000 On Jun 19, 2013, at 8:16 AM, "Peter Thatcher" wrote: Unfortunately, Microsoft's input seems to be "our way or the highway"=20 [BA] this isn't about Microsoft any more (if it ever was). This is about ena= bling developers, and not just on the browser. For example, WebRTC needs a s= tory on the server and that surely isn't JSEP.=20= From bernard_aboba@hotmail.com Wed Jun 26 21:14:16 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3D921F99C3 for ; Wed, 26 Jun 2013 21:14:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elVKFyHLJnee for ; Wed, 26 Jun 2013 21:14:10 -0700 (PDT) Received: from blu0-omc2-s38.blu0.hotmail.com (blu0-omc2-s38.blu0.hotmail.com [65.55.111.113]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB6821F99BE for ; Wed, 26 Jun 2013 21:14:08 -0700 (PDT) Received: from BLU169-W22 ([65.55.111.72]) by blu0-omc2-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jun 2013 21:14:07 -0700 X-TMN: [xm0nDIA8bYmVDpHmoIoz+5G9ObT7UnW2] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_f07f1269-9fea-4249-9707-4d309582bb7d_" From: Bernard Aboba To: Robin Raymond Date: Wed, 26 Jun 2013 21:14:06 -0700 Importance: Normal In-Reply-To: <51C1D55D.6040905@hookflash.com> References: , , , <51C1D55D.6040905@hookflash.com> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jun 2013 04:14:07.0101 (UTC) FILETIME=[C444BAD0:01CE72EC] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 04:14:16 -0000 --_f07f1269-9fea-4249-9707-4d309582bb7d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Robin said:=20 "If provided a lower level API that works without SDP where the =0A= individual network/media component wiring/attributes can be controlled=2C = =0A= we could create the same WebRTC API that exists today' [BA] I wouldn't require a shim to provide "the same WebRTC API that exists = today" because that API is very underspecified=2C so that it is not possibl= e to produce a set of conformance tests for it without reverse engineering.= And of course=2C that reverse engineered specification would only remain = valid until the next set of SDP hacks invalidated it.=20 So while the shim might provide a "similar high level WebRTC API"=2C holdin= g WebRTC API 2.0 to a "bug for bug" compatibility standard is neither feasi= ble nor desirable. The goal of WebRTC API 2.0 should be to deprecate 1.0= =2C not to increase the WebRTC API implementation barriers even further. = =0A= = --_f07f1269-9fea-4249-9707-4d309582bb7d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Robin said: =3B

    = "If provided a lower level API that work= s without SDP where the =0A= individual network/media component wiring/attributes can be controlled=2C = =0A= we could create the same WebRTC API that exists today'

    [BA] I wouldn't requi= re a shim to provide "the same WebRTC API that exists today" because that A= PI is very underspecified=2C so that it is not possible to produce a set of= conformance tests for it without reverse engineering.  =3BAnd of cours= e=2C that reverse engineered specification would only remain valid until th= e next set of SDP hacks invalidated it. =3B

    So= while the shim might provide a "similar high level WebRTC API"=2C holding = WebRTC API 2.0 to a "bug for bug" compatibility standard is neither feasibl= e nor desirable.  =3B The goal of WebRTC API 2.0 should be to deprecate= 1.0=2C not to increase the WebRTC API implementation barriers even further= . =3B
    =0A=

    = --_f07f1269-9fea-4249-9707-4d309582bb7d_-- From pthatcher@google.com Wed Jun 26 22:02:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B2221F9B41 for ; Wed, 26 Jun 2013 22:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sotLpgHO60rg for ; Wed, 26 Jun 2013 22:02:13 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 789CF21F9B40 for ; Wed, 26 Jun 2013 22:02:13 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un1so396139pbc.1 for ; Wed, 26 Jun 2013 22:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=q9yyBKx9UGxG/WaB/QUXp/c6SjeE9H2nw/0zOs6sgpM=; b=iAjY44d1uG/QvbCp08Ff3pmAwa74FULCfjO4w4NWvcIqmGhaCoG1vIQsaheFHnL/NM u+DTAVLaODR/RC3QeeTikHGQ26rrEp7DmIlVqSF0Lf/XinnesRgFBziEiZjmtkDbFEVI 9ade8CrD/kJLESjYEqHNBB1LrMqvTUx1Z2tJTZxbSLCn2wP8T3IwlwSQh+I43aO34Tse bfIAEo9aVsjux7GXQ71xiPEwE/QZxL8Kuziuc2urcGFvvakULWZBWMEmbyfUXSRjA25G SBaOrcNLJ3lCWV85nLyT2vovzCjyVeLPq56wQuFnyy09iSeUox0r2bDsHZlPT8o8EP7F 9nnQ== 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=q9yyBKx9UGxG/WaB/QUXp/c6SjeE9H2nw/0zOs6sgpM=; b=B3sm4YkDYwOj4vZ6mIdILViauY2usRc/0VYcS98DCAFnlV5w77FpSS76xb+SB/PXlM uUyM/wth7Ny6eyd+2MfEiN/JEa9gOtg5UjrAY+qhK0tIpcervRfBzJ36HSLlTsYqka/M u+IlS0jaKBJ+b9UBjyQzC76fIY3aMcrnv3An3iS9LZxigwN6aMfNUvc6469/lMlmb6X0 OMy88vCSi9AILDYQ4kiYiamMNsqWFccB7ZcGcqAPbQHcxngJJlhNgqLqe3Zj8+wR8K5S suSrUxbxnsC/0k6X/ZVWs5tzFraLC75oThZrTz1iwF9FkT6FUMozS9FetvDBvg4I1jBc 3HxA== X-Received: by 10.68.134.103 with SMTP id pj7mr4109539pbb.171.1372309333151; Wed, 26 Jun 2013 22:02:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.216.163 with HTTP; Wed, 26 Jun 2013 22:01:33 -0700 (PDT) In-Reply-To: References: <51BF5F00.90705@jitsi.org> From: Peter Thatcher Date: Wed, 26 Jun 2013 22:01:33 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=047d7b10cb235344cd04e01baa4d X-Gm-Message-State: ALoCoQlyTyUEkrkBJrQUAfnI7zco1D+8+pcet3tbb13wdeY+0NwHec7xAo354Y9cK7Ye/Q060ytjmX5jLH8Z0+QlFmMKnfmeQIFtN+z597cBMd6hp+/dSA8TxgJurQOqgeppWI8GdOI3LbMQhS/0r2GwiiyLlYMkkPWjl9evAWO9POVCCUsEuF0GYqxqYaJV8BQ2ViSI/vB0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:02:14 -0000 --047d7b10cb235344cd04e01baa4d Content-Type: text/plain; charset=UTF-8 If Node.js wants a cleaner API, it's can certainly create one. It's not at all constrained by what goes in the browser or what the WGs decide. In fact, that would be an interesting way to explore a cleaner API to see how well it works. On Wed, Jun 26, 2013 at 5:19 PM, Bernard Aboba wrote: > I do think No Plan represents progress toward containing the SDP monster > in WebRTC 1.0, particularly for video scenarios. However, I also agree with > Robin's arguments against SDP and O/ A, particularly for a server-side API > (e.g. Node.js modules) where the current API makes no sense at all. So my > perspective is to contain the monster in 1.0, then go with 2.0 first on > server, then on the browser. > > On Jun 17, 2013, at 10:34 PM, "Peter Thatcher" > wrote: > > I like your comparison to the data channels. As I just pointed out in > another email, I think it was good that we "contained the SDP monster", as > you put it, with createDataChannel. One of the purposes of > createLocalStream/createRemoteStream is to allow a JS app, if it chooses, > to "contain the SDP monster" when adding media streams. It would still be > needed for setting up the PeerConnection's transport (a monster container > for a future day perhaps), but that's still significant progress in my > book, and it does so with simple additions to the PeerConnection that don't > attempt to blow up the WG. > > > On Mon, Jun 17, 2013 at 5:14 PM, Bernard Aboba wrote: > >> >> >> >> 2) Dissadvantages of using SDP in WebRTC. >> >> >> Roman said: >> "An unmanageable monster was created which currently stays in the way of >> developing new functionality (bundle), building applications (does not >> provide obvious ways to implement obvious tasks, like adding an extra >> stream without re-negotiating all the existing ones) and even interop with >> existing SIP endpoints (which was the original but now is complicated since >> it would require a non trivial set of constraints and subsequent SDP >> manipulation)." >> >> [BA] Hard to argue with this, but I would point out that by far the >> ugliest part of the monster is the video hindquarters. While one could >> argue that we have been living with the warts of SDP for audio and >> therefore know the workarounds, with video there are substantial >> interoperability issues, *even among vendors who utilize the same >> codec*, sometimes even in relatively basic scenarios (e.g. P2P video call >> with H.264/SVC). So the "multivendor legacy of interop" just doesn't exist >> yet (at least, based on standards). >> >> So as I see it, it does represent progress that we have contained the SDP >> monster's impact on the the data channel, and I welcome Peter's effort to >> enable applications who don't care about SDP to minimize its usage even if >> it is not eliminated entirely. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --047d7b10cb235344cd04e01baa4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    If Node.js wants a cleaner API, it's can certainly cre= ate one. =C2=A0It's not at all constrained by what goes in the browser = or what the WGs decide. =C2=A0In fact, that would be an interesting way to = explore a cleaner API to see how well it works.


    On Wed, Jun 2= 6, 2013 at 5:19 PM, Bernard Aboba <bernard_aboba@hotmail.com&g= t; wrote:
    I do think No Plan re= presents progress toward containing the SDP monster in WebRTC 1.0, particul= arly for video scenarios. However, I also agree with Robin's arguments = against SDP and O/ A, particularly for a server-side API (e.g. Node.js modu= les) where the current API makes no sense at all. So my perspective is to c= ontain the monster in 1.0, then go with 2.0 first on server, then on the br= owser.=C2=A0

    On Jun 17, 2013, at 10:34 PM, "Peter T= hatcher" <pthatcher@google.com> wrote:

    I like your comparison to the data channels. =C2=A0As I ju= st pointed out in another email, I think it was good that we "containe= d the SDP monster", as you put it, with createDataChannel. =C2=A0One o= f the purposes of createLocalStream/createRemoteStream is to allow a JS app= , if it chooses, to "contain the SDP monster" when adding media s= treams. =C2=A0It would still be needed for setting up the PeerConnection= 9;s transport (a monster container for a future day perhaps), but that'= s still significant progress in my book, and it does so with simple additio= ns to the PeerConnection that don't attempt to blow up the WG.


    On Mon, Jun 1= 7, 2013 at 5:14 PM, Bernard Aboba <bernard_aboba@hotmail.com&g= t; wrote:
    =C2=A0
    =C2=A0
    2) Dissadvantages of using SDP in WebRTC.

    <= div>Roman said:
    "An unmanageable monster was created which c= urrently stays in the way of developing new functionality (bundle), buildin= g applications (does not provide obvious ways to implement obvious tasks, l= ike adding an extra stream without re-negotiating all the existing ones) an= d even interop with existing SIP endpoints (which was the original but now = is complicated since it would require a non trivial set of constraints and = subsequent SDP manipulation)."
    =C2=A0
    [BA] Hard to argue with this, but I would point= out that by far the ugliest part of the monster is the video hindquarters.= =C2=A0 While one could argue that we have been living with the warts of SDP= for audio and therefore know the workarounds, with video there are substan= tial interoperability issues, *even among vendors who utilize the same code= c*,=C2=A0sometimes even in relatively basic scenarios (e.g. P2P video call = with H.264/SVC).=C2=A0 So the "multivendor legacy of interop" jus= t doesn't exist yet (at least, based on standards).
    =C2=A0
    So as I see it, it does represent progress that we ha= ve=C2=A0contained the SDP monster's=C2=A0impact on the=C2=A0 the data c= hannel, and I welcome Peter's effort to enable applications who don'= ;t care about SDP to minimize its usage even if it is not eliminated entire= ly.=C2=A0 =C2=A0

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



    --047d7b10cb235344cd04e01baa4d-- From pthatcher@google.com Wed Jun 26 22:09:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A2D21F9B8C for ; Wed, 26 Jun 2013 22:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5v0mwe5NJJjH for ; Wed, 26 Jun 2013 22:09:04 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1963321F9B8B for ; Wed, 26 Jun 2013 22:09:04 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so531879pab.13 for ; Wed, 26 Jun 2013 22:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qX6djXeWtYOAujqy3YBYyYwl6WngDT4lw0NyF9Fl6tQ=; b=dhboBQty9YQrTtwKdaYMblO06RF3dBehfzXYgjwLYtkN1aDduOCPB2Mke436mZaMED 17o1m2guAE3sdPTdATpFrJlpYrf7YM0QmOl1JYahx3VCHMdUuxUrYK7cU52ZR2eKMWFJ pGvLjUIOBrnyxa0BfC/XxOCAlRGJOLvm0MhznsubuaJ9sHCE2rX2wjIwCXr0O3GuuGFA bnAgIN8DNyUaAhRL6NGMwvGLnhwm3HlIgVGUOkmPw/7vi7/ssvUqg/k3MEmtO6kDRQ1G be5xeqo/b7sPuw09jc567wSb1DRvN1A0kLzggyq0MmSwXVEpqTAc6BN7GgEh8DXYEmIu 3YAA== 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=qX6djXeWtYOAujqy3YBYyYwl6WngDT4lw0NyF9Fl6tQ=; b=ljVHGWk2TukhoNvXagnvyfX7C+ytlPrnY5vwzI6q4iB1ReAdelKtLO5UA9UM6MZ16Y b2hHLjO1t2N0NwZDi4sydMCA8AbrSWV0JzcheCADOjrgAMspWzzWT5ttZT1PxJVYCbNL UmVYQsJUDEz1Y54TBM1VDQpDRXdPXOgoSlOxW/76vBS6nWt6tguV4YvXe+aB1+3j4IGY GR6YMWpVcvLDZl6TczvhBezgZKii6BzKgHbWsubT50b1H7y6eHQFyxF9DnY16HIQ+AVt F3uvUlc4fez7M/z9/lUbMt1IyQ8yCs9mm3FTl5IL28+s1qneFLxoLKfUhfuZcIK118K/ 8Drg== X-Received: by 10.66.246.194 with SMTP id xy2mr4165538pac.131.1372309743801; Wed, 26 Jun 2013 22:09:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.216.163 with HTTP; Wed, 26 Jun 2013 22:08:23 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Wed, 26 Jun 2013 22:08:23 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=047d7b15ae49cd40ea04e01bc297 X-Gm-Message-State: ALoCoQkUQKLXJiB6aOvCPPljHwGxXSQQlvYDqaPIjSQxqRtdwTU+et7K2BwGpsANXi1wXp+EnSjrZZ/MmIAhostJJpIjCT+5kGebhO222znnjEdOg2HsNhjd31jAnQS0BwnTVATkAuLxe92OsCAlMH4TDO9uD30JoAUBWJsGmPuFDz93sQwcD9+vuCTRZbROQol20AbW6pQO Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:09:04 -0000 --047d7b15ae49cd40ea04e01bc297 Content-Type: text/plain; charset=UTF-8 FYI, after some further discussion with Martin and Matthew from Microsoft, I came to a better understanding of their position. I don't represent them, but I understand it better to be "No SDP and no O/A in the API". So I was being a big too negative with my "highway" comment. I apologize, again, to my friends at Microsoft. Also, I agree entirely that the goal should be to make the best API possible, and that includes enabling developers. But the server isn't at all constrained by JSEP. You can take the code from webrtc.org and build use the lower-level pieces and ignore SDP and O/A altogether. There's nothing stopping you. In fact, I'd be delighted if someone did just that and made an open source WebRTC server implementation. WebRTC (and libjingle, as subset) are open source and patches are welcome :). On Wed, Jun 26, 2013 at 5:29 PM, Bernard Aboba wrote: > > > On Jun 19, 2013, at 8:16 AM, "Peter Thatcher" > wrote: > > Unfortunately, Microsoft's input seems to be "our way or the highway" > > [BA] this isn't about Microsoft any more (if it ever was). This is about > enabling developers, and not just on the browser. For example, WebRTC needs > a story on the server and that surely isn't JSEP. --047d7b15ae49cd40ea04e01bc297 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    FYI, after some further discussion with Martin and Matthew= from Microsoft, I came to a better understanding of their position. =C2=A0= I don't represent them, but I understand it better to be "No SDP a= nd no O/A in the API". =C2=A0 So I was being a big too negative with m= y "highway" comment. =C2=A0I apologize, again, to my friends at M= icrosoft.

    Also, I agree entirely that the goal should be to make the b= est API possible, and that includes enabling developers. =C2=A0But the serv= er isn't at all constrained by JSEP. =C2=A0You can take the code from <= a href=3D"http://webrtc.org">webrtc.org and build use the lower-level p= ieces and ignore SDP and O/A altogether. =C2=A0There's nothing stopping= you. =C2=A0In fact, I'd be delighted if someone did just that and made= an open source WebRTC server implementation. =C2=A0WebRTC (and libjingle, = as subset) are open source and patches are welcome :).


    On Wed,= Jun 26, 2013 at 5:29 PM, Bernard Aboba <bernard_aboba@hotmail.com= > wrote:


    On Jun 19, 2013, at 8:16 AM, "Peter Thatcher" <pthatcher@google.com> wrote:

    Unfortunately, Microsoft's input seems to be "our way or the highw= ay"

    [BA] this isn't about Microsoft any more (if it ever was). This i= s about enabling developers, and not just on the browser. For example, WebR= TC needs a story on the server and that surely isn't JSEP.

    --047d7b15ae49cd40ea04e01bc297-- From robin@hookflash.com Wed Jun 26 22:09:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8079F21F9B8F for ; Wed, 26 Jun 2013 22:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPat7cj7o-Ss for ; Wed, 26 Jun 2013 22:09:50 -0700 (PDT) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id D9F7F21F9B57 for ; Wed, 26 Jun 2013 22:09:49 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 9so691370iec.33 for ; Wed, 26 Jun 2013 22:09:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=WgC8tM3CuYIMlH1yY0FR8xM58E5SXZocGYdi25xqfpU=; b=Midh/DCOo8oVste9XM7WIVDWAeUzbcos/FYcqP9+uSkebEAKwdVa8gwL7JjcplA5eP 9ZuQXtEwoqQS83bZkGl8OeXDoZWvpFTmD+FkxELdsK7dKebfMkffvnucQY4MyvOGyh5P 9hz0JtaVQW3HaAxk3CajmJQcsjAd+8FHwSarf5jcg/7z3K3QzApG8wAp2YLk/nGFdcCw bzf+7hGPaVx0BeixKkt4fDRH5DKD3e16jPJpW9jY4FHYWAlv7FZTqx2gONInNUYRwA6L dOupiIMv+4XdsFmCFKfgMrOg3qWHYBHqDdtyOnzQlCzHdWOSsZmdu7Muk34YPpCBl2TM z34A== X-Received: by 10.50.44.17 with SMTP id a17mr1953109igm.1.1372309789391; Wed, 26 Jun 2013 22:09:49 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id n8sm11547446igk.7.2013.06.26.22.09.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 22:09:48 -0700 (PDT) Message-ID: <51CBC919.1070805@hookflash.com> Date: Thu, 27 Jun 2013 01:09:45 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Bernard Aboba References: , , , <51C1D55D.6040905@hookflash.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000706060007060908040609" X-Gm-Message-State: ALoCoQlWciwuYl/QLGliphKiflVZhN1AvbyRUJLNnAn7tzGcMI9KQ6prjtEmwrujCPlGJsgQLuu6 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:09:54 -0000 This is a multi-part message in MIME format. --------------000706060007060908040609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit You are absolutely correct, that it is an unobtainable goal to produce a shim 1-for-1 compatible without reverse engineering. In the draft: http://tools.ietf.org/id/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00.txt We declare in section 5.4.8 "SIP/SDP and current WebRTC API shim compatibility statement" that it would not be the goal of this shim to do that. I think we have to work towards producing a shim that follows the spirit of the current WebRTC API rather than emulating the exact letter of every feature (and bug), especially since the feature definitions are vague. As any JS shim could be forked and modified, if a particular "feature/bug" needed to be emulated by someone it could be done by the developer needing the specialized behavior. Every JavaScript developer will have full control over the shim's code or which shim(s) to use. -Robin > Bernard Aboba > 27 June, 2013 12:14 AM > Robin said: > > "If provided a lower level API that works without SDP where the > individual network/media component wiring/attributes can be > controlled, we could create the same WebRTC API that exists today' > > [BA] I wouldn't require a shim to provide "the same WebRTC API that > exists today" because that API is very underspecified, so that it is > not possible to produce a set of conformance tests for it without > reverse engineering. And of course, that reverse engineered > specification would only remain valid until the next set of SDP hacks > invalidated it. > > So while the shim might provide a "similar high level WebRTC API", > holding WebRTC API 2.0 to a "bug for bug" compatibility standard is > neither feasible nor desirable. The goal of WebRTC API 2.0 should be > to deprecate 1.0, not to increase the WebRTC API implementation > barriers even further. --------------000706060007060908040609 Content-Type: multipart/related; boundary="------------030000000303060208050908" --------------030000000303060208050908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    You are absolutely correct, that it is an unobtainable goal to produce a shim 1-for-1 compatible without reverse engineering.

    In the draft:
    http://tools.ietf.org/id/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00.txt

    We declare in section 5.4.8 "SIP/SDP and current WebRTC API shim compatibility statement" that it would not be the goal of this shim to do that. I think we have to work towards producing a shim that follows the spirit of the current WebRTC API rather than emulating the exact letter of every feature (and bug), especially since the feature definitions are vague. As any JS shim could be forked and modified, if a particular "feature/bug" needed to be emulated by someone it could be done by the developer needing the specialized behavior. Every JavaScript developer will have full control over the shim's code or which shim(s) to use.

    -Robin

     
    27 June, 2013 12:14 AM
    Robin said: 

    "If provided a lower level API that works without SDP where the individual network/media component wiring/attributes can be controlled, we could create the same WebRTC API that exists today'

    [BA] I wouldn't require a shim to provide "the same WebRTC API that exists today" because that API is very underspecified, so that it is not possible to produce a set of conformance tests for it without reverse engineering.  And of course, that reverse engineered specification would only remain valid until the next set of SDP hacks invalidated it. 

    So while the shim might provide a "similar high level WebRTC API", holding WebRTC API 2.0 to a "bug for bug" compatibility standard is neither feasible nor desirable.   The goal of WebRTC API 2.0 should be to deprecate 1.0, not to increase the WebRTC API implementation barriers even further. 
    --------------030000000303060208050908 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------030000000303060208050908-- --------------000706060007060908040609-- From robin@hookflash.com Wed Jun 26 22:17:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B97D21F9BE9 for ; Wed, 26 Jun 2013 22:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aDrjrtgCt2V for ; Wed, 26 Jun 2013 22:17:03 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id F22B421F9446 for ; Wed, 26 Jun 2013 22:17:02 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id a13so708567iee.34 for ; Wed, 26 Jun 2013 22:17:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=1xL1YeOYGBW8vuLJvXNF16QRbDENz4WxNtJEDUAMcF4=; b=CsD5qaNCWYcsS1u4ZKwAU2v4rlN0i5S28XT52niT5JNvJaM0jEKPa+SsWdgM/jF+2N JPnyYSPPtKQzghzASDazgsp1NVcdxG8yPoUSplThfZ/wes3B3ytFPBno5LkMjmgxN0+Z KAvYNmRWkklMlO2FBft+BwCAe5O24PNWDXs4TGfuTF0McbqIaNWN3Ke6N79TawQhElxS eXXXJF61sEW1yQjPcmtSlJxn21FOJ6EDrIF4ec2BKqzoHoA3w0JuaBb2QUuBeyOtp7OZ abcfKuJGJ0OEf8a0Gv5ZKAdCLwomzV7JriKx5wdKFWfTPKmJjMENivVJlpXvky7PnJ+5 F6Kw== X-Received: by 10.50.117.72 with SMTP id kc8mr11918842igb.44.1372310221491; Wed, 26 Jun 2013 22:17:01 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id ri10sm11628115igc.1.2013.06.26.22.16.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 22:17:00 -0700 (PDT) Message-ID: <51CBCAC8.7070107@hookflash.com> Date: Thu, 27 Jun 2013 01:16:56 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Peter Thatcher References: <51BF5F00.90705@jitsi.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090008060204030808050901" X-Gm-Message-State: ALoCoQmEDUpjZSUaQkoh39Flw4DXPHwo8FaOjhkPMhLOGn3p8jDX8XFVbywY/0wwT78AMzxtRYY/ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:17:07 -0000 This is a multi-part message in MIME format. --------------090008060204030808050901 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit True, node.js doesn't have to use the same code in their implementation and they are free to deviate from the WebRTC path. But it would be highly desirable if they could use the same API as it would ensure a greater level of compatibility between client and servers where common JS libraries can be used. Plus node JS can be used to produce not just server apps but HTML5 based applications, so having a compatible library for those kind of applications is valuable too. -Robin > Peter Thatcher > 27 June, 2013 1:01 AM > If Node.js wants a cleaner API, it's can certainly create one. It's > not at all constrained by what goes in the browser or what the WGs > decide. In fact, that would be an interesting way to explore a > cleaner API to see how well it works. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Bernard Aboba > 26 June, 2013 8:19 PM > I do think No Plan represents progress toward containing the SDP > monster in WebRTC 1.0, particularly for video scenarios. However, I > also agree with Robin's arguments against SDP and O/ A, particularly > for a server-side API (e.g. Node.js modules) where the current API > makes no sense at all. So my perspective is to contain the monster in > 1.0, then go with 2.0 first on server, then on the browser. > > On Jun 17, 2013, at 10:34 PM, "Peter Thatcher" > wrote: --------------090008060204030808050901 Content-Type: multipart/related; boundary="------------020500000401000509040101" --------------020500000401000509040101 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
    True, node.js doesn't have to use the same code in their implementation and they are free to deviate from the WebRTC path. But it would be highly desirable if they could use the same API as it would ensure a greater level of compatibility between client and servers where common JS libraries can be used. Plus node JS can be used to produce not just server apps but HTML5 based applications, so having a compatible library for those kind of applications is valuable too.

    -Robin

    27 June, 2013 1:01 AM
    If Node.js wants a cleaner API, it's can certainly create one.  It's not at all constrained by what goes in the browser or what the WGs decide.  In fact, that would be an interesting way to explore a cleaner API to see how well it works.



    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    26 June, 2013 8:19 PM
    I do think No Plan represents progress toward containing the SDP monster in WebRTC 1.0, particularly for video scenarios. However, I also agree with Robin's arguments against SDP and O/ A, particularly for a server-side API (e.g. Node.js modules) where the current API makes no sense at all. So my perspective is to contain the monster in 1.0, then go with 2.0 first on server, then on the browser. 

    On Jun 17, 2013, at 10:34 PM, "Peter Thatcher" <pthatcher@google.com> wrote:
    --------------020500000401000509040101 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------020500000401000509040101-- --------------090008060204030808050901-- From pthatcher@google.com Wed Jun 26 22:22:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A67C21F9A85 for ; Wed, 26 Jun 2013 22:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_URI_CONS7=0.306] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zJKo02vSAVn for ; Wed, 26 Jun 2013 22:22:37 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A2A8A21F9A19 for ; Wed, 26 Jun 2013 22:22:37 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl14so545677pab.6 for ; Wed, 26 Jun 2013 22:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BAWTwIzjUtCKRxVCKrQRn3TmAFw6OmcLN4+KmI+nnBg=; b=iM9ovcst30QUhVhTyvXRpUA3ilgDW3YemCK6jOwJe24ww0z7+JxdPY17cuu2Y1hnW+ IlmmUN+MqIo9pW4TCXF1vSi5Jkl1GMirLbzsgkUCLr3gQWV56CSYKJltPPoDZv07MjG1 RwCeTgb/Rz78WQuCUMeCBxma7JJ/pkr/qEaPioSumONjXud5OmKe+no4hdJhRAfrlczS R4DSNZFp3aYNtpBTlr4uMhOFwdguUPnTMjD7zx1ywGTgO+eTWcu3Xd9jQXCABEzzp7x0 kmpkRYJ1NQqKq/+MmtVFSWLqxa2RN3cN0QzMoE+2FFNCGWCePeKngq67rPprFNYjiS3r Uoiw== 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=BAWTwIzjUtCKRxVCKrQRn3TmAFw6OmcLN4+KmI+nnBg=; b=Bpid8TdDegcVuultdM2NTWtu52CTMRcr0sB5HH6WLx5EU/ej2MWvkWvAyoHSje19Zq iWz6rNFkZLJ8bWSt/NMchfnmvxAM4AsWKgt2dTROkzILmQgYE1PWMgnnM6ARtzKCaxiE O+gawUkR7TAQVmRJUCt6mOUpOajIm6PjphU8vx7+GOY2XsGI5nktUZiC0G/5svX71Oik GtH/PKKRQjlMDnem5kRwf4Pgt1Y8j5eYWqyEHRRIBsdkt+z5DwyVSG6oQ9yhE7viMFsc 5bo2TM1VkUioZlXWVf5TaE/nLxZ+OKO1Ox4ivHkGJjru3oUNPemWZkrEB1ckhMuc1K/u W13Q== X-Received: by 10.68.184.100 with SMTP id et4mr4227645pbc.48.1372310557346; Wed, 26 Jun 2013 22:22:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.216.163 with HTTP; Wed, 26 Jun 2013 22:21:57 -0700 (PDT) In-Reply-To: References: <51C1D55D.6040905@hookflash.com> From: Peter Thatcher Date: Wed, 26 Jun 2013 22:21:57 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=047d7bd76aba4af97004e01bf3e4 X-Gm-Message-State: ALoCoQlizMw2Hv+jg1kmpZt3Pt6VkzfV+mJMcLSS/63Diswexj9b6/vX89yXmnClxvXt5FRzmjOwy9fwntJk+yt9stdiLnVzAa8jvgEJoFQEP7kY4PhH818rUF0rSafx9vwOjB/oELBYyd6CIpA12fIBFN+xr1+hEJxTffQSwQzM3Tu+qawUw7nkYue2kR3txFAxjGVb3+Iq Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:22:38 -0000 --047d7bd76aba4af97004e01bf3e4 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 26, 2013 at 9:14 PM, Bernard Aboba wrote: > Robin said: > > "If provided a lower level API that works without SDP where the individual > network/media component wiring/attributes can be controlled, we could > create the same WebRTC API that exists today' > > [BA] I wouldn't require a shim to provide "the same WebRTC API that exists > today" because that API is very underspecified, so that it is not possible > to produce a set of conformance tests for it without reverse engineering. > And of course, that reverse engineered specification would only remain > valid until the next set of SDP hacks invalidated it. > Once thing you *could* do (I'm not saying this is a good idea) is take an open source browser (let's pick Chrome) implement a "WebRTC 2.0" API, and then build the WebRTC 1.0 on top of it. You could then port the WebRTC 1.0 SDP code (for reference, it's here: https://code.google.com/p/libjingle/source/browse/trunk/talk/app/webrtc/webrtcsdp.cc) on to the WebRTC 2.0 API. At that point, you would have an "1.0 on 2.0" API that is the same as the "original 1.0" API, or at least as close as could possibly be done. And at the same time, you'd have the 2.0 available to JS to use. Repeat that process for all (2) browsers that have implemented the WebRTC 1.0 API. What could go wrong :)? > > So while the shim might provide a "similar high level WebRTC API", holding > WebRTC API 2.0 to a "bug for bug" compatibility standard is neither > feasible nor desirable. The goal of WebRTC API 2.0 should be to deprecate > 1.0, not to increase the WebRTC API implementation barriers even further. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7bd76aba4af97004e01bf3e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Wed, Jun 26, 2013 at 9:14 PM, Bernard Aboba &l= t;bernard_ab= oba@hotmail.com> wrote:
    Robin said:=C2=A0

    "If provided a lower level API that works without SDP where th= e=20 individual network/media component wiring/attributes can be controlled,=20 we could create the same WebRTC API that exists today'

    [BA] I wouldn't r= equire a shim to provide "the same WebRTC API that exists today" = because that API is very underspecified, so that it is not possible to prod= uce a set of conformance tests for it without reverse engineering. =C2=A0An= d of course, that reverse engineered specification would only remain valid = until the next set of SDP hacks invalidated it.=C2=A0

    Once thing you *could* do (I&#= 39;m not saying this is a good idea) is take an open source browser (let= 9;s pick Chrome) implement a "WebRTC 2.0" API, and then build the= WebRTC 1.0 on top of it. =C2=A0You could then port the WebRTC 1.0 SDP code= (for reference, it's here: https://code.google.c= om/p/libjingle/source/browse/trunk/talk/app/webrtc/webrtcsdp.cc) on to = the WebRTC 2.0 API. =C2=A0At that point, you would have an "1.0 on 2.0= " API that is the same as the "original 1.0" API, or at leas= t as close as could possibly be done. =C2=A0And at the same time, you'd= have the 2.0 available to JS to use. =C2=A0

    Repeat that process for all (2) browsers that have impl= emented the WebRTC 1.0 API. =C2=A0What could go wrong :)?

    =C2=A0

    So while the shim might provide a= "similar high level WebRTC API", holding WebRTC API 2.0 to a &qu= ot;bug for bug" compatibility standard is neither feasible nor desirab= le. =C2=A0 The goal of WebRTC API 2.0 should be to deprecate 1.0, not to in= crease the WebRTC API implementation barriers even further.=C2=A0



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


    --047d7bd76aba4af97004e01bf3e4-- From pthatcher@google.com Wed Jun 26 22:24:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AD021F9B4D for ; Wed, 26 Jun 2013 22:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_URI_CONS7=0.306] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOQ6hbGjewqP for ; Wed, 26 Jun 2013 22:24:06 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id AEA0121F9BFF for ; Wed, 26 Jun 2013 22:24:06 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id xb12so401967pbc.40 for ; Wed, 26 Jun 2013 22:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Mb5VJhlq9ynZrb0glGXRQQMbdERBnKagJD/f8QnuZ8E=; b=GMScMwKHEx5Kb991WaanGaiGnSd9S/w2hJVu05L9CacXzRKAmTiOdht/eHvMZJAMDP PQTabuLPf/GTG5A6vsWNMtUWpg8tlm1RRrWoAs/mEFSxhcOHwcmy3S5yvdVA8S8VcLAp 7vNfEk/Rk4TLOSAblSND7/yB1vfxTX8YOQU4AcwQrfMFhYntCMibE/2H2OJnP8R8UG/F wtjgO5nw+ixbF8XPZ4iZmzEkwQVU1IKwte8BJFX97prvYiSw6siSruloolAjXVVOIoIv gaSDQEMX6Gpw2lPWGDB86KEoQ8BPEYvLTbel3oH2kkhn0n4s0CbGBHi4V1bYm1TfnYnz d9lQ== 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=Mb5VJhlq9ynZrb0glGXRQQMbdERBnKagJD/f8QnuZ8E=; b=MP9BAIqnxD0gY6tYZajaF0dgoPm/eAO17jJRGgqWRrCQg/7N1swMBspx2jCMCLQaNK Mswrhv2e1zy0NjdQl/Wm3gypiwGu94UkFciUlI6rzTVTRB9H74rJ/WzwHSe/PgZaD9kG Iomt/mcmu9kwTjKTBsq/svbFXdR6DuTLr/Sg9m7Cp0nxueNws/McX0L5yirFQYCZt+p+ P/CEC8K9P7VzCbsATuQ98ReU5oTwXiY6ENAhTZ0/I+AqwZtKaBnWfsahiCTMRXxYKG8+ oV8U/1ayrIfJ66a53uHplr6e5/TA3nmuLZ5ZIX5a2/K/jpmxAD0PVGrYjdt1xdJZ4nFk 1MdA== X-Received: by 10.66.165.97 with SMTP id yx1mr4152611pab.82.1372310646362; Wed, 26 Jun 2013 22:24:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.216.163 with HTTP; Wed, 26 Jun 2013 22:23:26 -0700 (PDT) In-Reply-To: References: <51C1D55D.6040905@hookflash.com> From: Peter Thatcher Date: Wed, 26 Jun 2013 22:23:26 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=047d7b86c5289948ba04e01bf844 X-Gm-Message-State: ALoCoQkVGBwEx6n1C9saX6Lg495NYikGn8OyadZEJgz1clln6SFFqwykb60YD/rZgjEmPrytEDh5UGKZvRNjqEKshQ8EmsOIIFxjUpgqUSlKOnQmAhbqLQHVPpPdKSIkepe235Y49Sc6Paj95ASYeGnjoqZ5AIq6a3r9/MIEd8y6XaJkP3f6C9bVm4B/FC6GtaIxMmjSodZG Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:24:07 -0000 --047d7b86c5289948ba04e01bf844 Content-Type: text/plain; charset=UTF-8 Sorry. I meant to say " implement a "WebRTC 2.0" API, and then build the WebRTC 1.0 on top of it by porting" rather than "implement a "WebRTC 2.0" API, and then build the WebRTC 1.0 on top of it. You could then port". On Wed, Jun 26, 2013 at 10:21 PM, Peter Thatcher wrote: > > > > On Wed, Jun 26, 2013 at 9:14 PM, Bernard Aboba wrote: > >> Robin said: >> >> "If provided a lower level API that works without SDP where the >> individual network/media component wiring/attributes can be controlled, we >> could create the same WebRTC API that exists today' >> >> [BA] I wouldn't require a shim to provide "the same WebRTC API that >> exists today" because that API is very underspecified, so that it is not >> possible to produce a set of conformance tests for it without reverse >> engineering. And of course, that reverse engineered specification would >> only remain valid until the next set of SDP hacks invalidated it. >> > > Once thing you *could* do (I'm not saying this is a good idea) is take an > open source browser (let's pick Chrome) implement a "WebRTC 2.0" API, and > then build the WebRTC 1.0 on top of it. You could then port the WebRTC 1.0 > SDP code (for reference, it's here: > https://code.google.com/p/libjingle/source/browse/trunk/talk/app/webrtc/webrtcsdp.cc) > on to the WebRTC 2.0 API. At that point, you would have an "1.0 on 2.0" > API that is the same as the "original 1.0" API, or at least as close as > could possibly be done. And at the same time, you'd have the 2.0 available > to JS to use. > > Repeat that process for all (2) browsers that have implemented the WebRTC > 1.0 API. What could go wrong :)? > > > >> >> So while the shim might provide a "similar high level WebRTC API", >> holding WebRTC API 2.0 to a "bug for bug" compatibility standard is neither >> feasible nor desirable. The goal of WebRTC API 2.0 should be to deprecate >> 1.0, not to increase the WebRTC API implementation barriers even further. >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --047d7b86c5289948ba04e01bf844 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Sorry. =C2=A0I meant to say "=C2=A0implement a "= ;WebRTC 2.0" API, and then build the WebRTC 1.0 on top of it by portin= g" rather than "implement a "WebRTC 2.0" API, a= nd then build the WebRTC 1.0 on top of it. =C2=A0You could then port= ".


    On Wed, Jun 2= 6, 2013 at 10:21 PM, Peter Thatcher <pthatcher@google.com> wrote:



    On Wed, Jun 26, 20= 13 at 9:14 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
    Robin said:=C2=A0

    "If provided a lower level API that works without SDP where th= e=20 individual network/media component wiring/attributes can be controlled,=20 we could create the same WebRTC API that exists today'

    [BA] I wouldn't r= equire a shim to provide "the same WebRTC API that exists today" = because that API is very underspecified, so that it is not possible to prod= uce a set of conformance tests for it without reverse engineering. =C2=A0An= d of course, that reverse engineered specification would only remain valid = until the next set of SDP hacks invalidated it.=C2=A0

    Once thing you *could* d= o (I'm not saying this is a good idea) is take an open source browser (= let's pick Chrome) implement a "WebRTC 2.0" API, and then bui= ld the WebRTC 1.0 on top of it. =C2=A0You could then port the WebRTC 1.0 SD= P code (for reference, it's here: https://code.google.com/p/libjingle/source/browse/trunk/talk/app/webrtc/= webrtcsdp.cc) on to the WebRTC 2.0 API. =C2=A0At that point, you would = have an "1.0 on 2.0" API that is the same as the "original 1= .0" API, or at least as close as could possibly be done. =C2=A0And at = the same time, you'd have the 2.0 available to JS to use. =C2=A0

    Repeat that process for all (2) browsers that have impl= emented the WebRTC 1.0 API. =C2=A0What could go wrong :)?

    =C2=A0

    So while the shim might provide a= "similar high level WebRTC API", holding WebRTC API 2.0 to a &qu= ot;bug for bug" compatibility standard is neither feasible nor desirab= le. =C2=A0 The goal of WebRTC API 2.0 should be to deprecate 1.0, not to in= crease the WebRTC API implementation barriers even further.=C2=A0



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



    --047d7b86c5289948ba04e01bf844-- From pthatcher@google.com Wed Jun 26 22:26:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6139A21F9C00 for ; Wed, 26 Jun 2013 22:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQEvUb8XLHQt for ; Wed, 26 Jun 2013 22:26:10 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id A092A21F9BFF for ; Wed, 26 Jun 2013 22:26:10 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id 10so171486pdi.11 for ; Wed, 26 Jun 2013 22:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XJ7RtCaau7e9lp4iEfIZYWTbzzp8zrZdnLJgZIVAYpE=; b=DkAXc8BC8gWzLlxq5faw5tK8jCE57IG4vut9e3NIRkTvcWlerjWvZhgOGthWUSEPT4 OuhRZHDuE/h95ZlbTLVYLOFSnrltlR8+5Lo9GudFLRLVPp9GtP9BkBQ9n/gwpFN70cL4 nbJ3EvumVlIPKDlp4r81bmcw1+fNZ9ayP7w/9Te4fNymYEEXqRHx33ODSRd3vNc9FOso egqaYKaLP6NS4gw4Q0xEQuRC4+3Q+NOrv01uFv1w79W31nEp+qoAom2fleoEFkO203lo zGAN9/Gs6EMQCUmSt76Z/c/PZDyqnBfBnIOGCYirYnal1tqvfGtMDJdMJdGjWwDBe6Dh XRdA== 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=XJ7RtCaau7e9lp4iEfIZYWTbzzp8zrZdnLJgZIVAYpE=; b=F8a3p363o0ZTH544+Gf+6XIrSRMDM8njKjUXKwFBEzgwKNH85tQTDf2Kye74wt91qy h5zlWV+QYkYDBkZItjJ/rO8hGzYwTqA3od3tc7OAR8dPFb4e+iSjQwyAguCkWwbz/1fL 51Ihb9bJBJYt9QdS+hYXOGAODkTq8HWT2t09aSlbCh9SCp4XqrXA5uupOn0ihNjtexgj 13Cy/ODi34MJmTcHaJlapBBFbjHzSBwuvqvmT53Gbtqh428/omjLkENZmDxmAGS0R2/c GFmjRUFyDk3yGyEhVdQ0ZT/cpS/U31keQj2zd5YiP5BqnwW7JthzMoquoB+eU4YJsmjs Jn9w== X-Received: by 10.68.13.42 with SMTP id e10mr4181729pbc.23.1372310767612; Wed, 26 Jun 2013 22:26:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.216.163 with HTTP; Wed, 26 Jun 2013 22:25:27 -0700 (PDT) In-Reply-To: <51CBCAC8.7070107@hookflash.com> References: <51BF5F00.90705@jitsi.org> <51CBCAC8.7070107@hookflash.com> From: Peter Thatcher Date: Wed, 26 Jun 2013 22:25:27 -0700 Message-ID: To: Robin Raymond Content-Type: multipart/related; boundary=bcaec51f9083d3634504e01bffde X-Gm-Message-State: ALoCoQlgPBG/6ivQdFUOZH31GY287d5n39BJiM9+ngRdZ2mMyE35TcpN6gd6d6uN1NEqDxz3ZFnryGmK3Qzuq042rdYC5oS+GoUO10Si3wibl1A/4WYVKtqcY8Fgv9Jzy28GlCtFABO7BReyRAvNUqAPViiCL+TmUd/35Zfc9zKjWfmHrzYwCmrBVyQm55bWn4XB1yBskyl0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:26:11 -0000 --bcaec51f9083d3634504e01bffde Content-Type: multipart/alternative; boundary=bcaec51f9083d3634304e01bffdd --bcaec51f9083d3634304e01bffdd Content-Type: text/plain; charset=UTF-8 That's a good point about porting code from browser to node.js. I hadn't thought of that. More great feedback from the JS developers! On Wed, Jun 26, 2013 at 10:16 PM, Robin Raymond wrote: > > True, node.js doesn't have to use the same code in their implementation > and they are free to deviate from the WebRTC path. But it would be highly > desirable if they could use the same API as it would ensure a greater level > of compatibility between client and servers where common JS libraries can > be used. Plus node JS can be used to produce not just server apps but HTML5 > based applications, so having a compatible library for those kind of > applications is valuable too. > > -Robin > > Peter Thatcher > 27 June, 2013 1:01 AM > If Node.js wants a cleaner API, it's can certainly create one. It's not > at all constrained by what goes in the browser or what the WGs decide. In > fact, that would be an interesting way to explore a cleaner API to see how > well it works. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Bernard Aboba > 26 June, 2013 8:19 PM > I do think No Plan represents progress toward containing the SDP monster > in WebRTC 1.0, particularly for video scenarios. However, I also agree with > Robin's arguments against SDP and O/ A, particularly for a server-side API > (e.g. Node.js modules) where the current API makes no sense at all. So my > perspective is to contain the monster in 1.0, then go with 2.0 first on > server, then on the browser. > > On Jun 17, 2013, at 10:34 PM, "Peter Thatcher" > wrote: > > --bcaec51f9083d3634304e01bffdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    That's a good point about porting code from browser to= node.js. =C2=A0I hadn't thought of that. =C2=A0

    Mor= e great feedback from the JS developers! =C2=A0


    On Wed, Jun 26, 2013 at 10:16 PM, Robin Raymond = <robin@hookflash.com> wrote:

    True, node.js doesn't have to use the same code in their implementation= =20 and they are free to deviate from the WebRTC path. But it would be=20 highly desirable if they could use the same API as it would ensure a=20 greater level of compatibility between client and servers where common=20 JS libraries can be used. Plus node JS can be used to produce not just=20 server apps but HTML5 based applications, so having a compatible library for those kind of applications is valuable too.

    -Robin

    =20 27 June, 2013=20 1:01 AM
    If Node.js wants a cleaner API, it's can certainly create one. =C2=A0It's not at al= l=20 constrained by what goes in the browser or what the WGs decide. =C2=A0In=20 fact, that would be an interesting way to explore a cleaner API to see=20 how well it works.



    ______________________________________________= _
    rtcweb mailing=20 list
    rtcweb@ietf.or= g
    https://www.ietf.org/mailman/listinfo/rtcweb
    =20 26 June, 2013=20 8:19 PM
    I do= think No Plan=20 represents progress toward containing the SDP monster in WebRTC 1.0,=20 particularly for video scenarios. However, I also agree with Robin's=20 arguments against SDP and O/ A, particularly for a server-side API (e.g. Node.js modules) where the current API makes no sense at all. So my=20 perspective is to contain the monster in 1.0, then go with 2.0 first on=20 server, then on the browser.=C2=A0

    On Jun 17, 2013, at 10:34= =20 PM, "Peter Thatcher" <pthatcher@google.com> wrote:

    --bcaec51f9083d3634304e01bffdd-- --bcaec51f9083d3634504e01bffde Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 12b1a06293724f8_0.1.1 /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQECAQEB AQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAARCAAZABkDAREA AhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUKBwAAAAAAAAACAQME BQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAAAAAAAAAAAAADAAEEAv/E ACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oADAMBAAIRAxEAPwDuEt+gW/UL et6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJVIl7eXLCaZIGwBl3TY8epPx2+jy2 ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJ Ew/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx+a69/JSf9alIlste0VzaNpeFrcT9KKymotyi aZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mRUfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRD nu5azS8miKqjOTVkKqS/psG37fo1Fbabeg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GA cpOwBeN+U8/IkGbsiS8b7ryogmbzhbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH 4hPOI0DkjZtaJtFxuVEbIUUiyeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJ nYn9dnAQWl722p4ot37yzqnlfp6FrqbwawG8/9k= --bcaec51f9083d3634504e01bffde-- From matthew.kaufman@skype.net Wed Jun 26 22:27:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68FD521F9BD5 for ; Wed, 26 Jun 2013 22:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9l9fHuPODlQ for ; Wed, 26 Jun 2013 22:27:49 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 3565C21F8F87 for ; Wed, 26 Jun 2013 22:27:48 -0700 (PDT) Received: from BL2FFO11FD021.protection.gbl (10.173.161.202) by BL2FFO11HUB052.protection.gbl (10.173.161.128) with Microsoft SMTP Server (TLS) id 15.0.717.3; Thu, 27 Jun 2013 05:27:48 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD021.mail.protection.outlook.com (10.173.161.100) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Thu, 27 Jun 2013 05:27:47 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.171]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0136.001; Thu, 27 Jun 2013 05:26:38 +0000 From: "Matthew Kaufman (SKYPE)" To: Robin Raymond , Bernard Aboba Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) Thread-Index: AQHOa1pL3f2CtN2bTEydXd59L0Jyj5k6p8cAgAKBMYCAAAxEgIALzZYAgAAPjYCAAAHm4A== Date: Thu, 27 Jun 2013 05:26:37 +0000 Message-ID: References: , , , <51C1D55D.6040905@hookflash.com> <51CBC919.1070805@hookflash.com> In-Reply-To: <51CBC919.1070805@hookflash.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2E9DE2TK5EX14MBXC273r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454003)(189002)(199002)(69226001)(81542001)(16406001)(71186001)(79102001)(81342001)(74502001)(74706001)(77982001)(31966008)(47446002)(55846006)(74662001)(76482001)(74366001)(51856001)(54356001)(46102001)(44976004)(74876001)(77096001)(59766001)(19300405004)(76786001)(76796001)(54316002)(15202345003)(56816003)(53806001)(56776001)(6806003)(47976001)(20776003)(47736001)(4396001)(512954002)(63696002)(50986001)(33656001)(49866001)(80022001)(66066001)(561944002)(16236675002)(65816001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB052; H:TK5EX14HUBC101.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 08902E536D Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:27:54 -0000 --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2E9DE2TK5EX14MBXC273r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the current API course is followed, it is mandatory that it be possible = to produce a 1-for-1 compatible shim without reference to anything but the = W3C documentation and its normative references. Otherwise it cannot be a W3= C specification. Matthew Kaufman From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Robin Raymond Sent: Wednesday, June 26, 2013 10:10 PM To: Bernard Aboba Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sou= rces without encoding them in SDP) You are absolutely correct, that it is an unobtainable goal to produce a sh= im 1-for-1 compatible without reverse engineering. In the draft: http://tools.ietf.org/id/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-0= 0.txt We declare in section 5.4.8 "SIP/SDP and current WebRTC API shim compatibil= ity statement" that it would not be the goal of this shim to do that. I thi= nk we have to work towards producing a shim that follows the spirit of the = current WebRTC API rather than emulating the exact letter of every feature = (and bug), especially since the feature definitions are vague. As any JS sh= im could be forked and modified, if a particular "feature/bug" needed to be= emulated by someone it could be done by the developer needing the speciali= zed behavior. Every JavaScript developer will have full control over the sh= im's code or which shim(s) to use. -Robin --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2E9DE2TK5EX14MBXC273r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    If the current API course is followed, it is mandatory that it be possib= le to produce a 1-for-1 compatible shim without reference to anything but the W3C documentation and its normative references. Otherw= ise it cannot be a W3C specification.

     <= /p>

    Matthew Kaufman

     <= /p>

    From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@= ietf.org] On Behalf Of Robin Raymond
    Sent: Wednesday, June 26, 2013 10:10 PM
    To: Bernard Aboba
    Cc: rtcweb@ietf.org
    Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multi= ple sources without encoding them in SDP)

     


    You are absolutely correct, that it is an unobtainable goal to produce a sh= im 1-for-1 compatible without reverse engineering.

    In the draft:
    http://tools.ietf.org/id/draft-raymond-rtcweb-webrtc-js-o= bj-api-rationale-00.txt

    We declare in section 5.4.8 "SIP/SDP and current WebRTC API shim compa= tibility statement" that it would not be the goal of this shim to do t= hat. I think we have to work towards producing a shim that follows the spir= it of the current WebRTC API rather than emulating the exact letter of every feature (and bug), especially since the feature = definitions are vague. As any JS shim could be forked and modified, if a pa= rticular "feature/bug" needed to be emulated by someone it could = be done by the developer needing the specialized behavior. Every JavaScript developer will have full control over the shim'= s code or which shim(s) to use.

    -Robin

     

    --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2E9DE2TK5EX14MBXC273r_-- From pthatcher@google.com Wed Jun 26 23:37:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F96221F9A1A for ; Wed, 26 Jun 2013 23:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdsOOhYB0-Vg for ; Wed, 26 Jun 2013 23:37:27 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5795821F9C29 for ; Wed, 26 Jun 2013 23:37:27 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl14so618707pab.34 for ; Wed, 26 Jun 2013 23:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=3YtQbhvyI+ko1akFZLmT45TUzx0guXvouiQhgTrtfOs=; b=XBKUuigVpL0u7bzmqXTmwFd3OpMEk+EpBHeF2qDhhtynZtASGl8Pgig2SwTeVb7sJp SOHvwNSuXV5eNvh0IPBrJxK5g72Dj2URzhif4nNPbsybZQA6baWwaaz5EMbLGSQ8o9W9 MiFCS1U7cA1HyW5c61KXzU9pWOltvyefmIuXxe39rfkh6IMIUdsJEHYSHLX7iMXjUssW /haXliaaAPMKdGCQyNqDxMM7kSmGAXGUUYIkPa7jrU5HotrK2r32qXjN8Jedhy2znD6p wcesRNib2FgBQRtK+1sraA0MWPVYbwou0/ewhPuc2fD/v+K76MSybgtLRXYOyH5lzOhb XmkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=3YtQbhvyI+ko1akFZLmT45TUzx0guXvouiQhgTrtfOs=; b=MwZrl+okZ2x+WtY+tWqSS3fmdq9rhakD+MVU0GfkUvvM6Uu16J8o5tyyRQcuxorVI2 5PZn++Z81f3Es8XxWZ+Ri+2wY1tYff6Snn9ld2KkQEthhrTHL4aApFyrsEqwxvIe8pbe cAtOUqqxY47jbuGW0w23nCELg8Bi2+SSxBMVHSZmkSQmzdo3PS8GcrGexR/n03sc2gQG oS/Bbf54oWngJUk0wO0x4Phk4YND34Ns6cBdaEMNtr9MORjXUQp7Ebvjj+F71sNRqwNh 6QdKmuIgLAiB49hpIZuzFfnkIbZ5vxS0DR7kN8g+/WwQGPqWFQVnMex+CenTHjmEqqNk xofg== X-Received: by 10.69.1.69 with SMTP id be5mr4460080pbd.138.1372315046933; Wed, 26 Jun 2013 23:37:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.216.163 with HTTP; Wed, 26 Jun 2013 23:36:45 -0700 (PDT) From: Peter Thatcher Date: Wed, 26 Jun 2013 23:36:45 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary=047d7b160503e492a004e01cfe3a X-Gm-Message-State: ALoCoQlRzDfj5zdwyVHrjeANLyFdZrQvXqJVUXy1WEIabZT9XUV/OYJZSvd7nc76HGKxxAfWU+jml77UtjAUWWoKHLryTfCKLak1Bfkdu8DlccqOfIvt49dkLqoG7xcmFuylXAhH56U3kA8cK5Phx329EdASXuGmXTNT9m3Udmsr7tabi41xxjQ+on/Xo2XlM9GseyeNQAIB Subject: [rtcweb] Request for input from WebRTC JS (web app) developers (please respond if you are *using* the 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, 27 Jun 2013 06:37:28 -0000 --047d7b160503e492a004e01cfe3a Content-Type: text/plain; charset=UTF-8 I don't know if this has been done already, but I think that the WG could really use come good feedback from the JS developers out there actually using the WebRTC API. What are you making? What's working well? What's not working well? Do you like SDP? (Try to be constructive with that last one). So, I made a little spreadsheet where you can leave feedback: https://docs.google.com/spreadsheet/ccc?key=0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=0 If you are a JS developer using the WebRTC API, would you please fill in some feedback? If you can't give details about what you're working on, I can understand that. But please give us a sense of what is working well and what isn't. I think it would help the WG a lot. But please do remember that the WG is focusing on getting 1.0 out the door and probably wants to hear something more constructive than "I hate it; start over", so try to be constructive, especially when talking about SDP. Speaking of SDP, I read through 190+ recent emails about SDP (yeah... hot topic!) and collected quotes from some of you and put them in the spreadsheet. If you don't like that, I apologize; please let me know, or just remove yourself from the doc. I wanted to do the same for the other questions, but found it too hard. So I hope you'll help me :). (I didn't include anyone from Google, Mozilla, or Microsoft; I wanted this to be feedback for developers, not implementors, even if the implementors are also developers; And I didn't include myself :) Thank you so much for your feedback! PS: if anyone is interested, my quick tally of opinions of SDP indicate: Like: 3 Strongly Dislike: 6 Would like something else, or at least discussion of something else: 5 I may have gotten some wrong, so please give feedback to help it be more accurate. Thanks again! --047d7b160503e492a004e01cfe3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I don't know if this has been done already, but I thin= k that the WG could really use come good feedback from the JS developers ou= t there actually using the WebRTC API. =C2=A0What are you making? =C2=A0Wha= t's working well? What's not working well? =C2=A0Do you like SDP? = =C2=A0(Try to be constructive with that last one).

    So, I made a little spreadsheet where you can leave feedback= :


    If you are a JS developer using the WebRTC API, w= ould you please fill in some feedback? =C2=A0If you can't give details = about what you're working on, I can understand that. =C2=A0But please g= ive us a sense of what is working well and what isn't. =C2=A0I think it= would help the WG a lot. =C2=A0But please do remember =C2=A0that the WG is= focusing on getting 1.0 out the door and probably wants to hear something = more constructive than "I hate it; start over", so try to be cons= tructive, especially when talking about SDP.

    Speaking of SDP, I read through 190+ recent emails abou= t SDP (yeah... hot topic!) and collected quotes from some of you and put th= em in the spreadsheet. =C2=A0If you don't like that, I apologize; pleas= e let me know, or just remove yourself from the doc. =C2=A0I wanted to do t= he same for the other questions, but found it too hard. =C2=A0So I hope you= 'll help me :).

    (I didn't include anyone from Google, Mozilla, or M= icrosoft; =C2=A0I wanted this to be feedback for developers, not implemento= rs, even if the implementors are also developers; =C2=A0And I didn't in= clude myself :)

    Thank you so much for your feedback!=C2=A0
    <= div>



    PS: if anyo= ne is interested, my quick tally of opinions of SDP indicate:

    Like: 3
    Strongly Dislike: 6
    Would like s= omething else, or at least discussion of something else: 5

    I may have gotten some wrong, so please give feedback to help it b= e more accurate.

    Thanks again!


    --047d7b160503e492a004e01cfe3a-- From internet-drafts@ietf.org Thu Jun 27 01:40:25 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAAA21F9C83; Thu, 27 Jun 2013 01:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lai58kDM8qYV; Thu, 27 Jun 2013 01:40:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BC421F9C7C; Thu, 27 Jun 2013 01:39:59 -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.51.p2 Message-ID: <20130627083959.19251.46476.idtracker@ietfa.amsl.com> Date: Thu, 27 Jun 2013 01:39:59 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-11.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: Thu, 27 Jun 2013 08:40:25 -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 Use-cases and Requirements Author(s) : Christer Holmberg Stefan Hakansson Goran AP Eriksson Filename : draft-ietf-rtcweb-use-cases-and-requirements-11.txt Pages : 30 Date : 2013-06-27 Abstract: This document describes web based real-time communication use-cases. Requirements on the browser functionality are derived from use-cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requiremen= ts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-use-cases-and-requirem= ents-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stefan.lk.hakansson@ericsson.com Thu Jun 27 01:49:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D82821F9C97 for ; Thu, 27 Jun 2013 01:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.037 X-Spam-Level: X-Spam-Status: No, score=-5.037 tagged_above=-999 required=5 tests=[AWL=0.913, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5P7lDnsbDbJN for ; Thu, 27 Jun 2013 01:49:45 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C297521F9C93 for ; Thu, 27 Jun 2013 01:49:44 -0700 (PDT) X-AuditID: c1b4fb25-b7f1e6d00000274b-c1-51cbfca77bf2 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 57.3A.10059.7ACFBC15; Thu, 27 Jun 2013 10:49:43 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 10:49:43 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "rt >> \"rtcweb@ietf.org\"" Thread-Topic: New Version Notification for draft-ietf-rtcweb-use-cases-and-requirements-11.txt Thread-Index: AQHOcxH6LsByzdb3v06Hk4dVDiPxEA== Date: Thu, 27 Jun 2013 08:49:43 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C306ECD@ESESSMB209.ericsson.se> References: <20130627084022.19251.22430.idtracker@ietfa.amsl.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+Jvre7yP6cDDY7fMbFY+6+d3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGS/e7WYtmKJacW9lJ2sD40PZLkZODgkBE4lPE18zQthiEhfu rWfrYuTiEBI4zCjx+sVjJghnEaPE0s/9TCBVbAKBElv3LWADsUUEDCW+3WxlAbGFBRIkvrWu gIonSJza0sjaxcgBZOtJzGtlBwmzCKhK9M+aAGbzCvhKfFz3DaxVSMBRYlrfPLAjGIGO+H5q DdgqZgFxiVtP5jNBHCcgsWTPeWYIW1Ti5eN/rBC2osTOs+3MEPV6EjemTmGDsLUlli18zQyx S1Di5MwnLBMYRWYhGTsLScssJC2zkLQsYGRZxciem5iZk15utIkRGN4Ht/xW3cF455zIIUZp DhYlcd6Pp3YFCgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCcY2cduOWZRvs+zTWeAWqmj94a ee88dfCa9a77qwos/v/bP/3iC9m3s+KmsFiFR/EcPPX6TbnNui2rdhnmuK24zL112alaXgHZ 9eYN2lPe+2Ww2j0o5Dko/EFnV2FR4Zl1M9P6H3JpiHFaX3t983NTh20/s1LahX+bSltjF01e Gq+Xav/O7dhpJZbijERDLeai4kQAVJAy7z0CAAA= Subject: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-use-cases-and-requirements-11.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: Thu, 27 Jun 2013 08:49:50 -0000 From the change log:=0A= =0A= o Described that the API requirements are really from a W3C=0A= perspective and are supplied as an appendix in the introduction.=0A= Moved API requirements to an Appendix.=0A= =0A= o Removed the "Conventions" section with the key-words and reference= =0A= to RFC2119. Also changed uppercase MUST's/SHOULD's to lowercase.=0A= =0A= o Added a note on the proposed use of the document to the=0A= introduction.=0A= =0A= o Removed the note talking about WS from the "FW that only allows=0A= http" use-case.=0A= =0A= o Removed the word "Skype" that was used as example in one of the=0A= use-cases.=0A= =0A= o Clarified F3 (the req saying the everything the browser sends must= =0A= be rate controlled).=0A= =0A= o Removed the TBD saying we need to define reasonable levels from=0A= the requirement saying that quality must be good even in presence=0A= of packet losses (F5), and changed "must" to "should" (Based on a=0A= list discussion involving Bernard).=0A= =0A= o Removed F6 ("The browser must be able to handle high loss and=0A= jitter levels in a graceful way."), also after a list discussion.=0A= =0A= o Clarified F7 (used to say that the browser must support fast=0A= stream switches, now says that reference frames must be inserted=0A= when requested).=0A= o Removed the questions from F9 (echo cancellation), F10=0A= (syncronization), F21 (telephony codec).=0A= =0A= o Exchanged "restrictive firewalls" for "limited middleboxes" in F19= =0A= (as proposed by Martin).=0A= =0A= o Expanded DTMF and IVR in F22 (proposed by Martin)=0A= =0A= o Added ref to RFC5405 in F23 (proposed by Lars Eggert).=0A= =0A= o Exchanged "service provided" for "web application" in F32.=0A= =0A= o Changed the text in 3.2.1 that motivates F36 (new text "It is=0A= essential that media and data be encrypted, authenticated ...=0A= bound to the user identity."); and rewrote F36, included a ref to=0A= RFC5479.=0A= =0A= o Changed "quality of service" to "quality of experience" in F38.=0A= =0A= o Added F39.=0A= =0A= o Used new formulation of A17 (proposed by Martin).=0A= =0A= o Updated A20.=0A= =0A= o Updated A25.=0A= =0A= Things that have not been done:=0A= =0A= - No use-case on emergency services added (as said already in =0A= http://www.ietf.org/mail-archive/web/rtcweb/current/msg07253.html)=0A= =0A= - No use-case on real-time text added (as said already in=0A= http://www.ietf.org/mail-archive/web/rtcweb/current/msg07254.html)=0A= =0A= - No clarification on what solution(s) related to multiple resolutions =0A= of the same content added (discussed in =0A= http://www.ietf.org/mail-archive/web/rtcweb/current/msg07256.html but no = =0A= input received).=0A= =0A= - The order of the requirements (Fn) is still a mess - but I kept it as =0A= is for this version to make diffing simpler. To be fixed in an upcoming =0A= version.=0A= =0A= Stefan=0A= =0A= =0A= -------- Original Message --------=0A= Subject: New Version Notification for =0A= draft-ietf-rtcweb-use-cases-and-requirements-11.txt=0A= Date: 10:40=0A= From: internet-drafts@ietf.org =0A= To: Christer Holmberg , G=F6ran =0A= Eriksson AP , Stefan H=E5kansson LK =0A= , G=F6ran Eriksson AP =0A= =0A= =0A= =0A= A new version of I-D, draft-ietf-rtcweb-use-cases-and-requirements-11.txt= =0A= has been successfully submitted by Christer Holmberg and posted to the=0A= IETF repository.=0A= =0A= Filename: draft-ietf-rtcweb-use-cases-and-requirements=0A= Revision: 11=0A= Title: Web Real-Time Communication Use-cases and Requirements=0A= Creation date: 2013-06-27=0A= Group: rtcweb=0A= Number of pages: 30=0A= URL: =0A= http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-require= ments-11.txt=0A= Status: =0A= http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirement= s=0A= Htmlized: =0A= http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-11= =0A= Diff: =0A= http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-use-cases-and-requirem= ents-11=0A= =0A= Abstract:=0A= This document describes web based real-time communication use-cases.=0A= Requirements on the browser functionality are derived from use-cases.= =0A= =0A= =0A= =0A= =0A= =0A= The IETF Secretariat=0A= =0A= =0A= =0A= =0A= From stefan.lk.hakansson@ericsson.com Thu Jun 27 04:55:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F8E21F9A92 for ; Thu, 27 Jun 2013 04:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1mngSOSJsA1 for ; Thu, 27 Jun 2013 04:55:46 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4E321F9A83 for ; Thu, 27 Jun 2013 04:55:46 -0700 (PDT) X-AuditID: c1b4fb38-b7fc16d000004a21-e3-51cc28408204 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 5B.E2.18977.0482CC15; Thu, 27 Jun 2013 13:55:45 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 13:55:45 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: John Koleszar Thread-Topic: [rtcweb] More H.264 vs VP8 tests Thread-Index: Ac5vQ4bE4hnmu5ERSv6YOg93i7vBVw== Date: Thu, 27 Jun 2013 11:55:44 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C30766B@ESESSMB209.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+Jvra6jxplAg+MPeC1+r9zIarH2Xzu7 A5PHgk2lHkuW/GQKYIrisklJzcksSy3St0vgypi3exFzwXquitnnXrE1MG7m6GLk5JAQMJE4 1HyYDcIWk7hwbz2QzcUhJHCUUWL+5YksEM4iRol/HYsYQarYBAIltu5bANYhIqAh0bF9IjOI zSzgLbG+ew4LiC0soCvRcHwNVI2exMLnL1hg7N37P4LVswioSsy/1A0W5xXwlXh5ZS0zxLIp jBI9Zx6CNTMCnfT91BomiAXiEreezGeCOFVAYsme88wQtqjEy8f/WCFsRYmdZ9uhDtKTuDF1 ChuErS2xbOFrZohlghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRo7i1OKk3HQjg02MwHg4 uOW3xQ7Gy39tDjFKc7AoifPyAONESCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6Ppt4Muz3ad uHF8Gu8ZMc4ma/uOJTO0V/PH31y9ZIl6S2SB3T9mlztNj+7UuwgvXhyY8rzjxw6BsguSDOb6 zIpHdOUeXGZk73LolbVzXLXzB9fmwLTnt/fzRyjMVajTZRU3Phx+wKvyYtHho9Y75obnnN6b eaYubHbU4dcXOO9+VH27KGdHZ4wSS3FGoqEWc1FxIgAvS7clVQIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 11:55:53 -0000 On 2013-06-25 17:36, John Koleszar wrote:=0A= > On Sat, Jun 22, 2013 at 6:41 AM, Bo Burman =0A= > wrote:=0A= >> Hi all,=0A= ...=0A= >>=0A= > [...]=0A= >=0A= > Another unexpected=0A= > behavior for people trying this mode is that making libvpx bump up=0A= > against the lower quantizer without setting an approximately correct=0A= > target bitrate can also put the encoder into its "over quant" mode,=0A= > where it'll throw away additional residual trying to hit the target=0A= > bitrate.=0A= =0A= To make sure that this is not an issue we checked the bit rate for a =0A= sequence compressed with our settings. Then we encoded the same sequence = =0A= three times; once with --target-bitrate set to well below this bit rate, = =0A= once with --target-bitrate set to this bit rate, and once with =0A= --target-bitrate set to well above this bit rate. In all three cases we =0A= ended up with exactly the same bit rate and PSNR. In fact the resulting =0A= .webm files were bit-identical. So I think we can rule out the =0A= possibility that setting the target bitrate incorrectly can affect the =0A= results.=0A= =0A= Again, we have put a lot of effort into selecting these parameters and =0A= those for X264/JM, but since this is a complex issue we welcome feedback.= =0A= From partha@parthasarathi.co.in Thu Jun 27 10:04:58 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70DC721F9E77 for ; Thu, 27 Jun 2013 10:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.666 X-Spam-Level: X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_111=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzjZ3WzQUYm1 for ; Thu, 27 Jun 2013 10:04:54 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.230]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBEE21F9E4D for ; Thu, 27 Jun 2013 10:04:54 -0700 (PDT) Received: from userPC (unknown [122.178.223.166]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id E13F7190810D; Thu, 27 Jun 2013 16:56:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1372352174; bh=T7lCRsysuAhPPF45eqcjQmStI2Og8B0Cqxaq3Xw9LPc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=UPCmpXCtLi8+e9APU9tNTm3KlWsDFdFeUIVnhsh47yxLiDrw8tuEcwQKw68ZaM2Ph awtgKtEsTdcEmDP5Uzu03Wlip3HBY7+5MYtA53hnHqpSNAA+5BIBBGkx1GizakXxyJ fHmUY832CINAhlINBjZ9upVP3c6MKnPPB4ZpG/90= From: "Parthasarathi R" To: "'Dan Wing'" , "'Hadriel Kaplan'" References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> <529DCF4E-2A8B-475F-8CCE-7E2ABC72EFB1@oracle.com> <2C6DDF0C-201D-4CA3-8EB0-F14B! 8A2D5758@cisco.com> < CA2956C0-56B7-47E9-9EF4-9D639F8B8AD6@oracle.com> <12C17BE5-2302-48E9-A745-5B7265E83E8E@cisco.com> In-Reply-To: <12C17BE5-2302-48E9-A745-5B7265E83E8E@cisco.com> Date: Thu, 27 Jun 2013 22:26:03 +0530 Message-ID: <012d01ce7357$39226ef0$ab674cd0$@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: Ac5uqSwtMb2RvJARTOiy4gR3UHmvDQEqYinw Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0202.51CC6EAE.0154, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 17:04:58 -0000 Dan, I'm wondering whether any identity is mandatory all for WebRTC session. I'm asking this query as lot of WebRTC demo works well without any identity. For example: it is possible to pass URL like https://apprtc.appspot.com/?r=06095338 and ask the participant to join the session. Thanks Partha > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Dan Wing > Sent: Friday, June 21, 2013 11:30 PM > To: Hadriel Kaplan > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] No Interim on SDES at this juncture > > > On Jun 21, 2013, at 10:14 AM, Hadriel Kaplan > wrote: > > > > > On Jun 21, 2013, at 12:45 PM, Dan Wing wrote: > > > >>> We've talked about that one before I think. If jQuery is out to > get you, it's game over. It's essentially equivalent to a malicious > web-server, except of course that the operator of the web-server isn't > intending to be malicious (which is an important distinction). But > again, not only does jQuery have access to information such as who > you're talking to and when, it can also redirect your media to a > gateway of its choosing to terminate the DTLS-SRTP and record it, by > fiddling with the JSON/SDP stuff. > > >> > >> For the attacker to succeed with the redirection of DTLS-SRTP to a > server it controls, the attacker would also need to modify the SDP's > a=fingerprint line which is as trivial as the attacker's other SDP > modifications. To prevent the attacker from succeeding with such > modification, we need cryptographic identity (to protect the > From/To/Date/a=fingerprint and other fields), and need the browser (not > JS) to verify the identity using an external service (e.g., local disk, > IdP separate from the web server providing us the (compromised) JS and > the SDP). While it is true that today we don't have a way today to > provide that cryptographic identity (RFC4474 does not work, draft-wing- > rtcweb-identity-media written by me and Hadriel was met with silence) > DTLS-SRTP creates the foundation to build cryptographic identity which > can be verified by the browser itself. Such cryptographic identity > protects from this specific attack, and DTLS-SRTP protects from other > attacks. > > > > I agree - when we have such a thing, using DTLS-SRTP will have much > more meaning. But (1) there is no such thing yet, and (2) it won't > make DTLS-SRTP nor DTLS-EKT any stronger than SDES for the SIP-gateway > scenarios we're talking about, since the DTLS isn't going end-to-end. > I.e., none of the calls would successfully authenticate using such an > out-of-band mechanism, even the good ones. > > > > [note though I'm not saying DTLS-SRTP is useless today - quite the > contrary, I hummed in favor of making it MTI back when that was > decided, and I still think it should be MTI] > > Will the existence of SDES prevent WebRTC from building this more > secure system with strong identity? That is, when we add cryptographic > identity will that be effective to prevent a bid-down attack from DTLS- > SRTP to SDES? I am thinking right now that when we add identity we can > prevent that bid-down, so at that time SDES could become a proper > second-class citizen. > > -d > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From mail@makk.es Thu Jun 27 10:42:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80FA21F9E92 for ; Thu, 27 Jun 2013 10:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_111=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxNU0yWaSla4 for ; Thu, 27 Jun 2013 10:42:06 -0700 (PDT) Received: from lupus.uberspace.de (lupus.uberspace.de [95.143.172.176]) by ietfa.amsl.com (Postfix) with SMTP id 67FF921F9E94 for ; Thu, 27 Jun 2013 10:42:06 -0700 (PDT) Received: (qmail 4483 invoked from network); 27 Jun 2013 17:42:03 -0000 Received: from unknown (HELO ?192.168.0.20?) (31.18.98.41) by lupus.uberspace.de with SMTP; 27 Jun 2013 17:42:03 -0000 Message-ID: <51CC796A.5030507@makk.es> Date: Thu, 27 Jun 2013 19:42:02 +0200 From: Max Jonas Werner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Parthasarathi R References: <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> <529DCF4E-2A8B-475F-8CCE-7E2ABC72EFB1@oracle.com> <2C6DDF0C-201D-4CA3-8EB0-F14B! 8A2D5758@cisco.com> < CA2956C0-56B7-47E9-9EF4-9D639F8B8AD6@oracle.com> <12C17BE5-2302-48E9-A745-5B7265E83E8E@cisco.com> <012d01ce7357$39226ef0$ab674cd0$@co.in> In-Reply-To: <012d01ce7357$39226ef0$ab674cd0$@co.in> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2MXVDNUSTMMFEFWAIVHXJ" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 17:42:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MXVDNUSTMMFEFWAIVHXJ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Partha, On 27.06.2013 18:56, Parthasarathi R wrote: > Dan, >=20 > I'm wondering whether any identity is mandatory all for WebRTC session.= I'm > asking this query as lot of WebRTC demo works well without any identity= =2E For > example: it is possible to pass URL like > https://apprtc.appspot.com/?r=3D06095338 and ask the participant to joi= n the > session. whether an application makes use of the identity API is up to the developer as far as I unterstand the specs. This is why http://dev.w3.org/2011/webrtc/editor/webrtc.html#identity states: "WebRTC offers and answers (and hence the channels established by RTCPeerConnection objects) can be authenticated" I just recently gave a talk on WebRTC security and in the part about identity I stated that anonymity is a very useful tool to ensure user's privacy. That's why the identity services should always be optional. Max >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Dan Wing >> Sent: Friday, June 21, 2013 11:30 PM >> To: Hadriel Kaplan >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] No Interim on SDES at this juncture >> >> >> On Jun 21, 2013, at 10:14 AM, Hadriel Kaplan >> wrote: >> >>> >>> On Jun 21, 2013, at 12:45 PM, Dan Wing wrote: >>> >>>>> We've talked about that one before I think. If jQuery is out to >> get you, it's game over. It's essentially equivalent to a malicious >> web-server, except of course that the operator of the web-server isn't= >> intending to be malicious (which is an important distinction). But >> again, not only does jQuery have access to information such as who >> you're talking to and when, it can also redirect your media to a >> gateway of its choosing to terminate the DTLS-SRTP and record it, by >> fiddling with the JSON/SDP stuff. >> >>>> >>>> For the attacker to succeed with the redirection of DTLS-SRTP to a >> server it controls, the attacker would also need to modify the SDP's >> a=3Dfingerprint line which is as trivial as the attacker's other SDP >> modifications. To prevent the attacker from succeeding with such >> modification, we need cryptographic identity (to protect the >> From/To/Date/a=3Dfingerprint and other fields), and need the browser (= not >> JS) to verify the identity using an external service (e.g., local disk= , >> IdP separate from the web server providing us the (compromised) JS and= >> the SDP). While it is true that today we don't have a way today to >> provide that cryptographic identity (RFC4474 does not work, draft-wing= - >> rtcweb-identity-media written by me and Hadriel was met with silence) >> DTLS-SRTP creates the foundation to build cryptographic identity which= >> can be verified by the browser itself. Such cryptographic identity >> protects from this specific attack, and DTLS-SRTP protects from other >> attacks. >>> >>> I agree - when we have such a thing, using DTLS-SRTP will have much >> more meaning. But (1) there is no such thing yet, and (2) it won't >> make DTLS-SRTP nor DTLS-EKT any stronger than SDES for the SIP-gateway= >> scenarios we're talking about, since the DTLS isn't going end-to-end. >> I.e., none of the calls would successfully authenticate using such an >> out-of-band mechanism, even the good ones. >>> >>> [note though I'm not saying DTLS-SRTP is useless today - quite the >> contrary, I hummed in favor of making it MTI back when that was >> decided, and I still think it should be MTI] >> >> Will the existence of SDES prevent WebRTC from building this more >> secure system with strong identity? That is, when we add cryptographi= c >> identity will that be effective to prevent a bid-down attack from DTLS= - >> SRTP to SDES? I am thinking right now that when we add identity we ca= n >> prevent that bid-down, so at that time SDES could become a proper >> second-class citizen. >> >> -d ------enig2MXVDNUSTMMFEFWAIVHXJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFRzHlq1IVn4/X13N8RAn+lAJ9Kkwd4dL83m4XigYrwTSA2w6Q0pwCdH6qN imU/Uct+6KuPrqxw5DT5XkQ= =Sxfk -----END PGP SIGNATURE----- ------enig2MXVDNUSTMMFEFWAIVHXJ-- From andrew.hutton@siemens-enterprise.com Fri Jun 28 02:36:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F9221F9EBF for ; Fri, 28 Jun 2013 02:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQD9wSQiofcs for ; Fri, 28 Jun 2013 02:36:30 -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 ED2B121F9EA8 for ; Fri, 28 Jun 2013 02:36:29 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 7256723F05CA for ; Fri, 28 Jun 2013 11:36:26 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Fri, 28 Jun 2013 11:36:26 +0200 From: "Hutton, Andrew" To: "rtcweb@ietf.org" Thread-Topic: New Version Notification for draft-hutton-rtcweb-nat-firewall-considerations-01.txt Thread-Index: AQHOc0qTTJEVT6akKUqbUiE3WeI/V5lK3rDA Date: Fri, 28 Jun 2013 09:36:25 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115DD1C1@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] FW: New Version Notification for draft-hutton-rtcweb-nat-firewall-considerations-01.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, 28 Jun 2013 09:36:42 -0000 RllJIC0gV2UgaGF2ZSBzdWJtaXR0ZWQgYW4gdXBkYXRlIHRvIHRoaXMgZHJhZnQgYW5kIGFza2Vk IHRoZSBjaGFpcnMgZm9yIHNvbWUgYWdlbmRhIHRpbWUgdG8gZGlzY3VzcyB0aGlzIGFuZCBhc2sg Zm9yIGFkb3B0aW9uIGR1cmluZyBJRVRGODcuDQoNCkFuZHkNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiAyNyBKdW5lIDIwMTMgMTY6MjYNClRvOiBKdXN0aW4g VWJlcnRpOyBTdGFjaCwgVGhvbWFzOyBIdXR0b24sIEFuZHJldw0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odXR0b24tcnRjd2ViLW5hdC1maXJld2FsbC1jb25z aWRlcmF0aW9ucy0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaHV0dG9u LXJ0Y3dlYi1uYXQtZmlyZXdhbGwtY29uc2lkZXJhdGlvbnMtMDEudHh0DQpoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRob21hcyBTdGFjaCBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVU RiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWh1dHRvbi1ydGN3ZWItbmF0LWZpcmV3 YWxsLWNvbnNpZGVyYXRpb25zDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBSVENXRUIgQ29uc2lk ZXJhdGlvbnMgZm9yIE5BVHMsIEZpcmV3YWxscyBhbmQgSFRUUCBwcm94aWVzDQpDcmVhdGlvbiBk YXRlOgkgMjAxMy0wNi0yNw0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIg b2YgcGFnZXM6IDEwDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWh1dHRvbi1ydGN3ZWItbmF0LWZpcmV3YWxsLWNvbnNpZGVyYXRpb25z LTAxLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWh1dHRvbi1ydGN3ZWItbmF0LWZpcmV3YWxsLWNvbnNpZGVyYXRpb25zDQpIdG1saXpl ZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1dHRvbi1ydGN3ZWIt bmF0LWZpcmV3YWxsLWNvbnNpZGVyYXRpb25zLTAxDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWh1dHRvbi1ydGN3ZWItbmF0LWZpcmV3YWxs LWNvbnNpZGVyYXRpb25zLTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgbWVjaGFuaXNtIHRvIGVuYWJsZSBtZWRpYSBzdHJlYW0NCiAgIGVzdGFibGlzaG1lbnQgZm9y IFJlYWwtVGltZSBDb21tdW5pY2F0aW9uIGluIFdFQi1icm93c2VycyAoUlRDV0VCKSBpbg0KICAg dGhlIHByZXNlbmNlIG9mIG5ldHdvcmsgYWRkcmVzcyB0cmFuc2xhdG9ycywgZmlyZXdhbGxzIGFu ZCBIVFRQDQogICBwcm94aWVzLiAgSFRUUCBwcm94eSBhbmQgZmlyZXdhbGwgcG9saWNpZXMgYXBw bGllZCBpbiBtYW55IHByaXZhdGUNCiAgIG5ldHdvcmsgZG9tYWlucyBpbnRyb2R1Y2Ugb2JzdGFj bGVzIHRvIHRoZSBzdWNjZXNzZnVsIGVzdGFibGlzaG1lbnQNCiAgIG9mIG1lZGlhIHN0cmVhbSB2 aWEgUlRDV0VCLiAgVGhpcyBkb2N1bWVudCBleGFtaW5lcyBzb21lIG9mIHRoZXNlDQogICBwb2xp Y2llcyBhbmQgZGV2ZWxvcHMgcmVxdWlyZW1lbnRzIG9uIHRoZSB3ZWIgYnJvd3NlcnMgZGVzaWdu ZWQgdG8NCiAgIHByb3ZpZGUgdGhlIGJlc3QgcG9zc2libGUgY2hhbmNlIG9mIG1lZGlhIGNvbm5l Y3Rpdml0eSBiZXR3ZWVuIFJUQ1dFQg0KICAgcGVlcnMuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From yahui.wang@huawei.com Fri Jun 28 00:40:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0701D21F9EA6 for ; Fri, 28 Jun 2013 00:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWopcAFvxqcL for ; Fri, 28 Jun 2013 00:39:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4C79D21F9E71 for ; Fri, 28 Jun 2013 00:39:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASX92830; Fri, 28 Jun 2013 07:39:55 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 28 Jun 2013 08:38:54 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 28 Jun 2013 08:39:52 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Fri, 28 Jun 2013 15:39:44 +0800 From: "Wangyahui (Yahui)" To: "rtcweb@ietf.org" Thread-Topic: WebRTC service between SPs Thread-Index: Ac5z0qWy9y8UDykmSVWknFkwecyvnw== Date: Fri, 28 Jun 2013 07:39:43 +0000 Message-ID: <034C870DB898BE43B5787C7A79107CD94BFA4E1B@nkgeml507-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.63.61] Content-Type: multipart/alternative; boundary="_000_034C870DB898BE43B5787C7A79107CD94BFA4E1Bnkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 28 Jun 2013 08:49:02 -0700 Subject: [rtcweb] WebRTC service between SPs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 07:45:03 -0000 --_000_034C870DB898BE43B5787C7A79107CD94BFA4E1Bnkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have followed RTCWeb discussion for some time. As far as I know, any website can conveniently integrate WebRTC service, pa= rticularly social networking websites. It can easily be predicted that many= service providers (SPs), especially social networking SPs will release the= ir WebRTC services in the near future. But I am wondering how the users und= er different SPs can communicate using WebRTC client. Each SP offers differ= ent user identity in different domain. Although some mechanisms can support= to login multiple websites using a uniform account, such as Persona ID, Op= enID or OAuth, they have different Idps, and not all websites apply the sam= e mechanism. I am not sure whether it is a problem. Thanks for your any comments. --_000_034C870DB898BE43B5787C7A79107CD94BFA4E1Bnkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi all,

    I have followed RTCWeb discussi= on for some time.

    As far as I know, any website c= an conveniently integrate WebRTC service, particularly social networking we= bsites. It can easily be predicted that many service providers (SPs), espec= ially social networking SPs will release their WebRTC services in the near future. But I am wondering how the users= under different SPs can communicate using WebRTC client. Each SP offers di= fferent user identity in different domain. Although some mechanisms can sup= port to login multiple websites using a uniform account, such as Persona ID, OpenID or OAuth, they have di= fferent Idps, and not all websites apply the same mechanism.

    I am not sure whether it is a problem. Thanks for your any comments.

    --_000_034C870DB898BE43B5787C7A79107CD94BFA4E1Bnkgeml507mbxchi_-- From jim.barnett@genesyslab.com Fri Jun 28 09:03:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BAF21F9B10 for ; Fri, 28 Jun 2013 09:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhzYNLX+AYAO for ; Fri, 28 Jun 2013 09:03:33 -0700 (PDT) Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id F0E6F21F9ADD for ; Fri, 28 Jun 2013 09:03:32 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.3 [168.75.250.3]) (Using TLS) by service108-us.mimecast.com; Fri, 28 Jun 2013 12:03:28 -0400 Received: from GENSJZMBX01.msg.int.genesyslab.com ([fe80::c80a:d985:3cca:a5e7]) by GENSJZFE01.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 09:03:27 -0700 From: Jim Barnett To: "Wangyahui (Yahui)" , "rtcweb@ietf.org" Thread-Topic: WebRTC service between SPs Thread-Index: Ac5z0qWy9y8UDykmSVWknFkwecyvnwARaJEQ Date: Fri, 28 Jun 2013 16:03:27 +0000 Message-ID: <57A15FAF9E58F841B2B1651FFE16D281052E6B@GENSJZMBX01.msg.int.genesyslab.com> References: <034C870DB898BE43B5787C7A79107CD94BFA4E1B@nkgeml507-mbx.china.huawei.com> In-Reply-To: <034C870DB898BE43B5787C7A79107CD94BFA4E1B@nkgeml507-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.7.220.231] MIME-Version: 1.0 X-MC-Unique: 113062812032901202 Content-Type: multipart/alternative; boundary="_000_57A15FAF9E58F841B2B1651FFE16D281052E6BGENSJZMBX01msgint_" Subject: Re: [rtcweb] WebRTC service between SPs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 16:03:39 -0000 --_000_57A15FAF9E58F841B2B1651FFE16D281052E6BGENSJZMBX01msgint_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable As I understand it, it's not just a problem of identities. WebRTC does not= define the signaling protocol, but leaves it up to the application. If t= wo users download their applications/JavaScript from the same site, it won'= t be a problem, because the same application is handling both ends of the c= all. But if one user is on site A while the other is on site B, there is n= o guarantee that either site's application will understand the signaling fr= om the other. - Jim From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Wangyahui (Yahui) Sent: Friday, June 28, 2013 3:40 AM To: rtcweb@ietf.org Subject: [rtcweb] WebRTC service between SPs Hi all, I have followed RTCWeb discussion for some time. As far as I know, any website can conveniently integrate WebRTC service, pa= rticularly social networking websites. It can easily be predicted that many= service providers (SPs), especially social networking SPs will release the= ir WebRTC services in the near future. But I am wondering how the users und= er different SPs can communicate using WebRTC client. Each SP offers differ= ent user identity in different domain. Although some mechanisms can support= to login multiple websites using a uniform account, such as Persona ID, Op= enID or OAuth, they have different Idps, and not all websites apply the sam= e mechanism. I am not sure whether it is a problem. Thanks for your any comments. --_000_57A15FAF9E58F841B2B1651FFE16D281052E6BGENSJZMBX01msgint_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

    As I und= erstand it, it’s not just a problem of identities.  WebRTC does = not define the signaling protocol, but leaves it  up to the applicatio= n.  If two users download their applications/JavaScript from the same site, it= won’t be a problem, because the same application is handling both en= ds of the call.  But if one user is on site A while the other is on si= te B, there is no guarantee that either site’s application will understand the signaling from the other.

    -          = Jim

    &nb= sp;

    From: rtcweb-bounces@ietf.org [mailto= :rtcweb-bounces@ietf.org] On Behalf Of Wangyahui (Yahui)
    Sent: Friday, June 28, 2013 3:40 AM
    To: rtcweb@ietf.org
    Subject: [rtcweb] WebRTC service between SPs

     

    Hi all,

    I have followed RTCWeb discussion for some time.

    As far as I know, any website can conveniently integ= rate WebRTC service, particularly social networking websites. It can easily= be predicted that many service providers (SPs), especially social networki= ng SPs will release their WebRTC services in the near future. But I am wondering how the users under different SPs c= an communicate using WebRTC client. Each SP offers different user identity = in different domain. Although some mechanisms can support to login multiple= websites using a uniform account, such as Persona ID, OpenID or OAuth, they have different Idps, and not all= websites apply the same mechanism.

    I am not sure = whether it is a problem. Thanks for your any comments.=

    --_000_57A15FAF9E58F841B2B1651FFE16D281052E6BGENSJZMBX01msgint_-- From moises.silva@gmail.com Fri Jun 28 11:25:16 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A027F21F9BCE for ; Fri, 28 Jun 2013 11:25:16 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDV0ctua5Zzx for ; Fri, 28 Jun 2013 11:25:16 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 922DC21F9BC2 for ; Fri, 28 Jun 2013 11:25:14 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id f4so4673378iea.39 for ; Fri, 28 Jun 2013 11:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=avTjdAqgWNIiy7gX7IHIIHbcq/LHivok59OqPG6dcqg=; b=cfQR9pqQlpCa6eyn5UQvRSwH72EnJAHHd4dE/WdqNMUZ2OYu1eS3lOoe7949ucQDxc kh2hmtdZiENZPowYbz165glAjIkYyWVvK+4PRdWgrkQ0eZH5AGXa/8ay0bUoKAYmTq+J mxrCx3UgmdwZiQO7IUYcJoOOgb1HnJh6+Fjkqc199utZ0RiYOeKp9OdAzh/V1/nfFnkH AN5FeUXCogSiCGa4DjpJWH/WuZTIJHY66pnqOUBsjpLkhf4cSz+zY3mwPmt3pmYFKJXM BF7ADkBvnNDpbUHkdE0brej2LJEeuiW53rfomjnaNqNHOk6tsbZNOxl/q15hxOfXzKiy UjKg== MIME-Version: 1.0 X-Received: by 10.50.87.71 with SMTP id v7mr5267321igz.29.1372443913844; Fri, 28 Jun 2013 11:25:13 -0700 (PDT) Received: by 10.50.130.66 with HTTP; Fri, 28 Jun 2013 11:25:13 -0700 (PDT) In-Reply-To: <57A15FAF9E58F841B2B1651FFE16D281052E6B@GENSJZMBX01.msg.int.genesyslab.com> References: <034C870DB898BE43B5787C7A79107CD94BFA4E1B@nkgeml507-mbx.china.huawei.com> <57A15FAF9E58F841B2B1651FFE16D281052E6B@GENSJZMBX01.msg.int.genesyslab.com> Date: Fri, 28 Jun 2013 14:25:13 -0400 Message-ID: From: Moises Silva To: Jim Barnett Content-Type: multipart/alternative; boundary=089e0103ef52f5a28804e03affa2 Cc: "Wangyahui \(Yahui\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC service between SPs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 18:25:17 -0000 --089e0103ef52f5a28804e03affa2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jun 28, 2013 at 12:03 PM, Jim Barnett w= rote: > As I understand it, it=E2=80=99s not just a problem of identities. WebR= TC does > not define the signaling protocol, but leaves it up to the application. > If two users download their applications/JavaScript from the same site, i= t > won=E2=80=99t be a problem, because the same application is handling both= ends of > the call. But if one user is on site A while the other is on site B, the= re > is no guarantee that either site=E2=80=99s application will understand th= e > signaling from the other.**** > > ** > Unless websites agree to use something standard such as SIP/Jingle for federation (inter website/domain communication). - Moy --089e0103ef52f5a28804e03affa2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    On Fri, Jun 28, 2013 at 12:= 03 PM, Jim Barnett <Jim.Barnett@genesyslab.com> wro= te:

    As I und= erstand it, it=E2=80=99s not just a problem of identities.=C2=A0 WebRTC doe= s not define the signaling protocol, but leaves it=C2=A0 up to the applicat= ion.=C2=A0 If two users download their applications/JavaScript from the same site, it= won=E2=80=99t be a problem, because the same application is handling both = ends of the call.=C2=A0 But if one user is on site A while the other is on = site B, there is no guarantee that either site=E2=80=99s application will understand the signaling from the other.

    <= /p>


    Unless web= sites agree to use something standard such as SIP/Jingle for federation (in= ter website/domain communication).

    -
    Moy
    --089e0103ef52f5a28804e03affa2-- From fluffy@cisco.com Fri Jun 28 15:29:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA8621F9CF5 for ; Fri, 28 Jun 2013 15:29:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irzIUNDV5qx1 for ; Fri, 28 Jun 2013 15:29:08 -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 E18EF21F9D09 for ; Fri, 28 Jun 2013 15:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=360; q=dns/txt; s=iport; t=1372458539; x=1373668139; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NiZ41cdd1uw3ZSr7xrHF8wckhDwoTQymvb0TppKaiDw=; b=hP6nJqja0yMLS748Dun0rdJK/kGqfoH8YRHmulkTmP4G1Slhrx5/DQ37 zW7AGXSGIQVpnr/cGK+brDryYsL9Veq+zXEctgM8h4Lt8BqnaOX6AfYXT 90GxUMZmiqh8J142VVIV1MkSqoARrvxBgXEgTcMPAYphvRJ5EFTth5xuS Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAKsMzlGtJXG+/2dsb2JhbABbgwl7vwqBChZ0giMBAQEDATo/BQsCAQgiFAULIRElAgQOBQiHdQMJBQGxcg2IUoxugjUCMQeDBGMDlV6OB4UlgViBOYIo X-IronPort-AV: E=Sophos;i="4.87,962,1363132800"; d="scan'208";a="228793536" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 28 Jun 2013 22:28:58 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5SMSwft009956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 22:28:58 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 17:28:55 -0500 From: "Cullen Jennings (fluffy)" To: Silvia Pfeiffer Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) Thread-Index: AQHOdE7g5/y6jULE6kGJ5GQef/y6YQ== Date: Fri, 28 Jun 2013 22:28:57 +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: [171.68.20.14] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 22:29:14 -0000 On Jun 17, 2013, at 6:00 PM, Silvia Pfeiffer wr= ote: > Having hit my > head hard against the limitations of the current WebRTC API and being > forced to learn SDP to achieve some of the less common use cases, I'm > feeling the pain. Could you let us know the use cases of what it is you need an easy way to d= o ?=20 From pthatcher@google.com Fri Jun 28 16:30:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DDC21F9CBF for ; Fri, 28 Jun 2013 16:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMyprXI5uLSa for ; Fri, 28 Jun 2013 16:30:59 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 07CAF21F9CBC for ; Fri, 28 Jun 2013 16:30:58 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id r10so1313305pdi.41 for ; Fri, 28 Jun 2013 16:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XVXD5sA1zilf0k15d/z4dOInRFZIe0cpsqtsfdLiWAU=; b=kmoanubWkeX3WlUYuFJhNV2FCL92ShKJnd1pHnVVQg2us48f5NuMApq4XSPeF6Rn2r CHfVFOiwsU33sQWroIdvYvXFu/IPWjgBsPQbDJjUOhnf718ouOFLIU4aQy+Z1+nkP02x J/6TnuG5ibkI4YJxCd+pODXJ8Lz1l1fI5H4+mXrIrKVlMKc+IpmPX8A0VJEDS/ENiaPd O48Sgu3IMOKtiEXSOhAaO4CdwCipZ6OMYFKNqArb6Rr/ZScZTgeqZhjUGbkIkO0bi8hK lvPpGKEuZOO/3P7ij7kP4jrOaU02WNc3ViKtmzf7fn1m6zbTkt6h64QVxmsWjrhYNPTK W0mQ== 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=XVXD5sA1zilf0k15d/z4dOInRFZIe0cpsqtsfdLiWAU=; b=QLqDJ3o/IzAsiUx127zyV171YTfb/25nYkV8AzyYRdQahbRLShlQfUAsoQR/ssnRF5 kVMLTeedCXVBUd7CYAZd2mniuQjx12R2osULL1Z+Xmh17ScGJw01ur7DF4AO9KdWWsxQ UMNB0LriCDC3anRJ2S2+U5xSwnkivnrha9cE8cz+IdmaGbbiZI3jLYSpQ2nOKlTqD2+L oJFaiW7IcWw3NLBdq5g0aeGclM1K7MUnnQ/14vg+UTqlfPUaa9qk/klpeeTWFNtjntxt lwxNDsJhudlRLsy8KM8n2JDoTmBc8GYR6000M56HwH207UJJIqCya1pSXAmYDcPIlX7r MnPw== X-Received: by 10.66.162.102 with SMTP id xz6mr13867333pab.0.1372462258632; Fri, 28 Jun 2013 16:30:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.234.71 with HTTP; Fri, 28 Jun 2013 16:30:18 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Fri, 28 Jun 2013 16:30:18 -0700 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=047d7b86e55064dbb904e03f45bc X-Gm-Message-State: ALoCoQnx8S/iuzBnbVlMDXgGNMalvucS8pgImwe7LY30Wb8DBtyhvvFBL2tVaZPEbAD/lK+bXLbrEbC/P9siJCVxAMEppiZ34VBlORQX/1yQ4nXWUyVJxwjHnRp3VHclgtouzVoCrPmntMXjbokPFKLnuAk567z6zRhi/v/V2E7PQxKen2zstEz7386/iEkiVCid0mvO5ecz Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 23:30:59 -0000 --047d7b86e55064dbb904e03f45bc Content-Type: text/plain; charset=UTF-8 FYI, you might find some in this doc: https://docs.google.com/spreadsheet/ccc?key=0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=0 About nine developers have listed what they are trying to do and what pain they are running into, with SDP specifically. Granted, it's only what can fit in a single spreadsheet cell, but I'm sure you can ask for further details if you are interested. But at least one did mention how well SDP is working for them, so there's input on both sides. On Fri, Jun 28, 2013 at 3:28 PM, Cullen Jennings (fluffy) wrote: > > On Jun 17, 2013, at 6:00 PM, Silvia Pfeiffer > wrote: > > > Having hit my > > head hard against the limitations of the current WebRTC API and being > > forced to learn SDP to achieve some of the less common use cases, I'm > > feeling the pain. > > Could you let us know the use cases of what it is you need an easy way to > do ? > > --047d7b86e55064dbb904e03f45bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    FYI, you might find some in this doc:

    <= a href=3D"https://docs.google.com/spreadsheet/ccc?key=3D0AuaKXw3SkHMSdHlZdV= 9RN0xSWFhybVl4anJLRkVPV0E#gid=3D0">https://docs.google.com/spreadsheet/ccc?= key=3D0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=3D0

    About nine developers have listed what they are t= rying to do and what pain they are running into, with SDP specifically. =C2= =A0Granted, it's only what can fit in a single spreadsheet cell, but I&= #39;m sure you can ask for further details if you are interested. =C2=A0But= at least one did mention how well SDP is working for them, so there's = input on both sides.

    =C2=A0


    On Fri, Jun 28, 2013 at 3:28 PM, Cullen Jennings (= fluffy) <fluffy@cisco.com> wrote:

    On Jun 17, 2013, at 6:00 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

    > Having hit my
    > head hard against the limitations of the current WebRTC API and being<= br> > forced to learn SDP to achieve some of the less common use cases, I= 9;m
    > feeling the pain.

    Could you let us know the use cases of what it is you need an easy wa= y to do ?


    --047d7b86e55064dbb904e03f45bc-- From hangzhou.chenxin@huawei.com Fri Jun 28 18:59:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A318821F9DF9 for ; Fri, 28 Jun 2013 18:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CskKY-mqvkpe for ; Fri, 28 Jun 2013 18:59:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D74B121F99F3 for ; Fri, 28 Jun 2013 18:58:59 -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 ASY56295; Sat, 29 Jun 2013 01:58:58 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 29 Jun 2013 02:58:07 +0100 Received: from SZXEML454-HUB.china.huawei.com (10.82.67.197) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 29 Jun 2013 02:58:56 +0100 Received: from SZXEML538-MBX.china.huawei.com ([169.254.4.243]) by SZXEML454-HUB.china.huawei.com ([10.82.67.197]) with mapi id 14.01.0323.007; Sat, 29 Jun 2013 09:58:48 +0800 From: "Chenxin (Xin)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] FW: New Version Notification for draft-hutton-rtcweb-nat-firewall-considerations-01.txt Thread-Index: AQHOc0qTTJEVT6akKUqbUiE3WeI/V5lK3rDAgAEQszA= Date: Sat, 29 Jun 2013 01:58:47 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE0397643B58FB@szxeml538-mbx.china.huawei.com> References: <9F33F40F6F2CD847824537F3C4E37DDF115DD1C1@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115DD1C1@MCHP04MSX.global-ad.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [rtcweb] FW: New Version Notification for draft-hutton-rtcweb-nat-firewall-considerations-01.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, 29 Jun 2013 01:59:04 -0000 I support to add NAT/FW traversal topic into IETF87 agenda. I will update the turn over websocket draft to give WG a option to discu= ss. If I could attend this meeting ,I would like apply a slice of agenda ti= me to explain my proposal too. Best Regards, Xin=20 >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O= f >Hutton, Andrew >Sent: Friday, June 28, 2013 5:36 PM >To: rtcweb@ietf.org >Subject: [rtcweb] FW: New Version Notification for >draft-hutton-rtcweb-nat-firewall-considerations-01.txt > >FYI - We have submitted an update to this draft and asked the chairs for s= ome >agenda time to discuss this and ask for adoption during IETF87. > >Andy > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: 27 June 2013 16:26 >To: Justin Uberti; Stach, Thomas; Hutton, Andrew >Subject: New Version Notification for >draft-hutton-rtcweb-nat-firewall-considerations-01.txt > > >A new version of I-D, draft-hutton-rtcweb-nat-firewall-considerations-01.t= xt >has been successfully submitted by Thomas Stach and posted to the >IETF repository. > >Filename: draft-hutton-rtcweb-nat-firewall-considerations >Revision: 01 >Title: RTCWEB Considerations for NATs, Firewalls and HTTP proxies >Creation date: 2013-06-27 >Group: Individual Submission >Number of pages: 10 >URL: >http://www.ietf.org/internet-drafts/draft-hutton-rtcweb-nat-firewall-consi= derat >ions-01.txt >Status: >http://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-considera= tions >Htmlized: >http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations= -01 >Diff: >http://www.ietf.org/rfcdiff?url2=3Ddraft-hutton-rtcweb-nat-firewall-consid= eration >s-01 > >Abstract: > This document describes mechanism to enable media stream > establishment for Real-Time Communication in WEB-browsers (RTCWEB) in > the presence of network address translators, firewalls and HTTP > proxies. HTTP proxy and firewall policies applied in many private > network domains introduce obstacles to the successful establishment > of media stream via RTCWEB. This document examines some of these > policies and develops requirements on the web browsers designed to > provide the best possible chance of media connectivity between RTCWEB > peers. > > > > >The IETF Secretariat > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From rishi@turtleyogi.com Fri Jun 28 23:17:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1619921F9E54 for ; Fri, 28 Jun 2013 23:17: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kB+XWflzoYl for ; Fri, 28 Jun 2013 23:17:50 -0700 (PDT) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8916E21F9E43 for ; Fri, 28 Jun 2013 23:17:50 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 9so5800421iec.33 for ; Fri, 28 Jun 2013 23:17:50 -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:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ZHPpnbdB+7Yas4XEv/Q0lqy7++RBxbwsX1LjRaVM2SE=; b=GxOIIhlVUwQWCT1dbm/PCDcpqhz1vRECt8ek9PhR8ZUHli3vwKLR5/2hTqPWKOILjL EiRDkm+riypmhF4w+kY7I2FobL/k4PzW0d9B1EHpdEfUDIsS6k/ddmP+wOyOHuJPD83U FTgIomQUIEt/BXxB0xn3nKBQwNKlWA+74IWeIifNgeTuCIPl0+PKU43BDRckUyGHWLNx M5mvtnkm8cTyULw4B+zt+iiNNFM2XgpihDpUCpGYYnhILna9B+X4aQJDTEIJYSd2yoM6 AmAGc1lHBqNJrV0kEhGcJP63Rspdi8vJSqaPUhe7H6lfaqIuBOkBkGAJ9a/zcLe4hc/x 1sRQ== MIME-Version: 1.0 X-Received: by 10.50.136.196 with SMTP id qc4mr7265055igb.21.1372486669941; Fri, 28 Jun 2013 23:17:49 -0700 (PDT) Received: by 10.64.231.36 with HTTP; Fri, 28 Jun 2013 23:17:49 -0700 (PDT) X-Originating-IP: [122.166.178.191] In-Reply-To: References: <034C870DB898BE43B5787C7A79107CD94BFA4E1B@nkgeml507-mbx.china.huawei.com> <57A15FAF9E58F841B2B1651FFE16D281052E6B@GENSJZMBX01.msg.int.genesyslab.com> Date: Sat, 29 Jun 2013 11:47:49 +0530 Message-ID: From: Hrishikesh Kulkarni To: Moises Silva Content-Type: multipart/alternative; boundary=089e01494eee6bd20804e044f49c X-Gm-Message-State: ALoCoQkbASdKID9zJqLeaG2PTjDSdPblvWugiieuUPpPudd/erhsvBIm8CAGIMvQ/OzaQvPl7mYo Cc: "Wangyahui \(Yahui\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC service between SPs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 06:17:55 -0000 --089e01494eee6bd20804e044f49c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable SIP is an established standard to interoperate domains. We at OneKlikStreet.com developed a video/audio bridging service for WebRTC. Although it uses JS/JSON signaling for web based clients. Our server could very well federate with any other service using SIP. What does need to be discussed on app to app basis is what kind of federation you are looking for? In case of bridging service we could merge calls from both servers or redirect all the calls to the host service. regards, Rishi Founder, OneKlikStreet.com On Fri, Jun 28, 2013 at 11:55 PM, Moises Silva wrot= e: > > On Fri, Jun 28, 2013 at 12:03 PM, Jim Barnett wrote: > >> As I understand it, it=92s not just a problem of identities. WebRTC do= es >> not define the signaling protocol, but leaves it up to the application. >> If two users download their applications/JavaScript from the same site, = it >> won=92t be a problem, because the same application is handling both ends= of >> the call. But if one user is on site A while the other is on site B, th= ere >> is no guarantee that either site=92s application will understand the >> signaling from the other.**** >> >> ** >> > > Unless websites agree to use something standard such as SIP/Jingle for > federation (inter website/domain communication). > > - > Moy > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e01494eee6bd20804e044f49c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    SIP is an established standard to interoperate domains. We= at OneKlikStreet.com developed a video/audio bridging service for WebRTC. = Although it uses JS/JSON signaling for web based clients. Our server could = very well federate with any other service using SIP. What does need to be d= iscussed on app to app basis is what kind of federation you are looking for= ?=A0
    In case of bridging service we could merge calls from both servers or redir= ect all the calls to the host service.

    regards,=
    Rishi
    Founder, OneKlikStreet.com



    <= br>
    On Fri, Jun 28, 2013 at 11:55 PM, Moises Silv= a <moises.silva@gmail.com> wrote:

    On Fri, Jun 28, 2013 at 12:03 PM, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:

    As I und= erstand it, it=92s not just a problem of identities.=A0 WebRTC does not def= ine the signaling protocol, but leaves it=A0 up to the application.=A0 If two users download their applications/JavaScript from the same site, it= won=92t be a problem, because the same application is handling both ends o= f the call.=A0 But if one user is on site A while the other is on site B, t= here is no guarantee that either site=92s application will understand the signaling from the other.

    <= /p>


    Unle= ss websites agree to use something standard such as SIP/Jingle for federati= on (inter website/domain communication).

    -
    Moy

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


    --089e01494eee6bd20804e044f49c-- From ibc@aliax.net Fri Jun 28 23:23:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C594921F9983 for ; Fri, 28 Jun 2013 23:23:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RECqn4yWzC3a for ; Fri, 28 Jun 2013 23:23:29 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 201D721F9957 for ; Fri, 28 Jun 2013 23:23:22 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id g10so1067170qah.12 for ; Fri, 28 Jun 2013 23:23:21 -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=JikkJU+TCMy8Vs232rdPiFXcpYrkrTmGTyHT4U4G8Js=; b=KGyaX+et+1uOC4Y/+wi08XO9M/1I6QV2KBBW2nrSr6ll6miUODliy9VNvsw7L5hjq1 Dkx/YfvCNA7R1C6qDA557wTb+PqQVouIgZa5ktZOD6R3kSEwJM4RKtUb2s4VF+E8wHJd NoS029bA/e8BMPttIjknyXbsBhHxubEDuSOK32ESxAAOfZwq7c8jAhd4+1BmjnueckZQ GBxi+VWR+nJe8oPM9XitSlb50NFrNd5o9t5cPSlbBpIve4lj5oLuM4F0+8suCzMtBGU4 B3a0d8h+qWLUTvsEp9IJFV0V/fo3h0kib0/rAyceM0l96iAw7j4H+cLNe2wjndWamnbf zh2g== MIME-Version: 1.0 X-Received: by 10.49.61.167 with SMTP id q7mr20750437qer.80.1372487001602; Fri, 28 Jun 2013 23:23:21 -0700 (PDT) Received: by 10.49.72.132 with HTTP; Fri, 28 Jun 2013 23:23:21 -0700 (PDT) Received: by 10.49.72.132 with HTTP; Fri, 28 Jun 2013 23:23:21 -0700 (PDT) In-Reply-To: References: Date: Sat, 29 Jun 2013 08:23:21 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Cullen Jennings Content-Type: multipart/alternative; boundary=047d7bdc9fba30928304e04508d2 X-Gm-Message-State: ALoCoQmz1QNbxNqb257U0i8CBC00o8PUtytuAugminoDKBc5r8dLirLdFbiB9sleyAKz2Q3JoFN9 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 06:23:33 -0000 --047d7bdc9fba30928304e04508d2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cullen, do you think that W3C would ever design a JS API that forces the developer to deal with an unmanageable blob string? Can somebody point me to an existing similar "API" in HTML5? The problem is that telcos are much more used to IETF processes than Web people and hence this WG is dominated by telcos proposing their first API for the W3C, an API to satisfy their existing business model (the webphone)= . It is time to leave Web experts to design a really useful API for WebRTC. -- I=C3=B1aki Baz Castillo El 29/06/2013 00:29, "Cullen Jennings (fluffy)" escribi= =C3=B3: > > On Jun 17, 2013, at 6:00 PM, Silvia Pfeiffer > wrote: > > > Having hit my > > head hard against the limitations of the current WebRTC API and being > > forced to learn SDP to achieve some of the less common use cases, I'm > > feeling the pain. > > Could you let us know the use cases of what it is you need an easy way to > do ? > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bdc9fba30928304e04508d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    Cullen, do you think that W3C would ever design a JS API tha= t forces the developer to deal with an unmanageable blob string? Can somebo= dy point me to an existing similar "API" in HTML5?

    The problem is that telcos are much more used to IETF proces= ses than Web people and hence this WG is dominated by telcos proposing thei= r first API for the W3C, an API to satisfy their existing business model (t= he webphone).

    It is time to leave Web experts to design a really useful AP= I for WebRTC.

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

    El 29/06/2013 00:29, "Cullen Jennings (fluf= fy)" <fluffy@cisco.com> = escribi=C3=B3:

    On Jun 17, 2013, at 6:00 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

    > Having hit my
    > head hard against the limitations of the current WebRTC API and being<= br> > forced to learn SDP to achieve some of the less common use cases, I= 9;m
    > feeling the pain.

    Could you let us know the use cases of what it is you need an easy way to d= o ?

    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    = https://www.ietf.org/mailman/listinfo/rtcweb
    --047d7bdc9fba30928304e04508d2-- From yahui.wang@huawei.com Sat Jun 29 02:29:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE29D21F9E68 for ; Sat, 29 Jun 2013 02:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtguvyrCuB5T for ; Sat, 29 Jun 2013 02:29:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A4AF021F9E67 for ; Sat, 29 Jun 2013 02:29:46 -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 ASY74476; Sat, 29 Jun 2013 09:29:45 +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.7; Sat, 29 Jun 2013 10:28:49 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 29 Jun 2013 10:29:39 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Sat, 29 Jun 2013 17:29:31 +0800 From: "Wangyahui (Yahui)" To: Hrishikesh Kulkarni Thread-Topic: [rtcweb] WebRTC service between SPs Thread-Index: Ac5z0qWy9y8UDykmSVWknFkwecyvnwARaJEQ//+i/ICAAMcZgP//d1SA Date: Sat, 29 Jun 2013 09:29:30 +0000 Message-ID: <034C870DB898BE43B5787C7A79107CD94BFA5254@nkgeml507-mbx.china.huawei.com> References: <034C870DB898BE43B5787C7A79107CD94BFA4E1B@nkgeml507-mbx.china.huawei.com> <57A15FAF9E58F841B2B1651FFE16D281052E6B@GENSJZMBX01.msg.int.genesyslab.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.111.63.61] Content-Type: multipart/alternative; boundary="_000_034C870DB898BE43B5787C7A79107CD94BFA5254nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC service between SPs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 09:29:51 -0000 --_000_034C870DB898BE43B5787C7A79107CD94BFA5254nkgeml507mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KWWVzLCB3ZSBjYW4gaW1wbGVtZW50IHRoZSBmZWRl cmF0aW9uIGJldHdlZW4gU1BzIHRocm91Z2ggdXNpbmcgdGhlIHNhbWUgc2lnbmFsaW5nIHByb3Rv Y29sIChlLmcuIFNJUCkgb3IgZGVwbG95aW5nIGEgZ2F0ZXdheS4NCg0KQnV0IHdoYXQgSSBjb25j ZXJuIGlzIGhvdyB0byBjb21wYXRpYmxlIHdpdGggdGhlIGV4aXN0aW5nIHZhcmlvdXMgdXNlciBp ZCBmcm9tIGRpZmZlcmVudCBTUHMuIEZvciBleGFtcGxlLCBpZiBHb29nbGUgcHJvdmlkZXMgV2Vi UlRDIGNsaWVudCwgdGhlbiB0aGUgdXNlcnMgc2hvdWxkIGJlIGFibGUgdG8gbG9naW4gdXNpbmcg dGhlaXIgR21haWwgYWRkcmVzcy4gSW4gdGhlIHNhbWUgd2F5LCBGYWNlYm9vayBzdXBwb3J0IHRo ZSB1c2VycyB1c2luZyBGYWNlYm9va0lkLiBTbyB0aGUgZm9ybWF0IG9mIGlkZW50aWZpY2F0aW9u IG1heSBiZSBudW1iZXIsIHN0cmluZyBvciBlbWFpbCBhbmQgc28gb24uDQoNClRoZSBwcm9ibGVt IGlzIGhvdyB0byBoYW5kbGUgYWRkcmVzc2luZyB1c2VycyBvZiBkaWZmZXJlbnQgU1BzLiBTaG91 bGQgaXQgYmUgc3RhbmRhcmRpemVkIHRvIGEgdW5pZmllZCBXZWJSVEMgVVJJPw0KDQpZYWh1aQ0K DQq3orz+yMs6IEhyaXNoaWtlc2ggS3Vsa2FybmkgW21haWx0bzpyaXNoaUB0dXJ0bGV5b2dpLmNv bV0NCreiy83KsbzkOiAyMDEzxOo21MIyOcjVIDE0OjE4DQrK1bz+yMs6IE1vaXNlcyBTaWx2YQ0K s63LzTogSmltIEJhcm5ldHQ7IFdhbmd5YWh1aSAoWWFodWkpOyBydGN3ZWJAaWV0Zi5vcmcNCtb3 zOI6IFJlOiBbcnRjd2ViXSBXZWJSVEMgc2VydmljZSBiZXR3ZWVuIFNQcw0KDQpTSVAgaXMgYW4g ZXN0YWJsaXNoZWQgc3RhbmRhcmQgdG8gaW50ZXJvcGVyYXRlIGRvbWFpbnMuIFdlIGF0IE9uZUts aWtTdHJlZXQuY29tIGRldmVsb3BlZCBhIHZpZGVvL2F1ZGlvIGJyaWRnaW5nIHNlcnZpY2UgZm9y IFdlYlJUQy4gQWx0aG91Z2ggaXQgdXNlcyBKUy9KU09OIHNpZ25hbGluZyBmb3Igd2ViIGJhc2Vk IGNsaWVudHMuIE91ciBzZXJ2ZXIgY291bGQgdmVyeSB3ZWxsIGZlZGVyYXRlIHdpdGggYW55IG90 aGVyIHNlcnZpY2UgdXNpbmcgU0lQLiBXaGF0IGRvZXMgbmVlZCB0byBiZSBkaXNjdXNzZWQgb24g YXBwIHRvIGFwcCBiYXNpcyBpcyB3aGF0IGtpbmQgb2YgZmVkZXJhdGlvbiB5b3UgYXJlIGxvb2tp bmcgZm9yPw0KSW4gY2FzZSBvZiBicmlkZ2luZyBzZXJ2aWNlIHdlIGNvdWxkIG1lcmdlIGNhbGxz IGZyb20gYm90aCBzZXJ2ZXJzIG9yIHJlZGlyZWN0IGFsbCB0aGUgY2FsbHMgdG8gdGhlIGhvc3Qg c2VydmljZS4NCg0KcmVnYXJkcywNClJpc2hpDQpGb3VuZGVyLCBPbmVLbGlrU3RyZWV0LmNvbQ0K DQoNCg0KT24gRnJpLCBKdW4gMjgsIDIwMTMgYXQgMTE6NTUgUE0sIE1vaXNlcyBTaWx2YSA8bW9p c2VzLnNpbHZhQGdtYWlsLmNvbTxtYWlsdG86bW9pc2VzLnNpbHZhQGdtYWlsLmNvbT4+IHdyb3Rl Og0KDQpPbiBGcmksIEp1biAyOCwgMjAxMyBhdCAxMjowMyBQTSwgSmltIEJhcm5ldHQgPEppbS5C YXJuZXR0QGdlbmVzeXNsYWIuY29tPG1haWx0bzpKaW0uQmFybmV0dEBnZW5lc3lzbGFiLmNvbT4+ IHdyb3RlOg0KQXMgSSB1bmRlcnN0YW5kIGl0LCBpdKGvcyBub3QganVzdCBhIHByb2JsZW0gb2Yg aWRlbnRpdGllcy4gIFdlYlJUQyBkb2VzIG5vdCBkZWZpbmUgdGhlIHNpZ25hbGluZyBwcm90b2Nv bCwgYnV0IGxlYXZlcyBpdCAgdXAgdG8gdGhlIGFwcGxpY2F0aW9uLiAgSWYgdHdvIHVzZXJzIGRv d25sb2FkIHRoZWlyIGFwcGxpY2F0aW9ucy9KYXZhU2NyaXB0IGZyb20gdGhlIHNhbWUgc2l0ZSwg aXQgd29uoa90IGJlIGEgcHJvYmxlbSwgYmVjYXVzZSB0aGUgc2FtZSBhcHBsaWNhdGlvbiBpcyBo YW5kbGluZyBib3RoIGVuZHMgb2YgdGhlIGNhbGwuICBCdXQgaWYgb25lIHVzZXIgaXMgb24gc2l0 ZSBBIHdoaWxlIHRoZSBvdGhlciBpcyBvbiBzaXRlIEIsIHRoZXJlIGlzIG5vIGd1YXJhbnRlZSB0 aGF0IGVpdGhlciBzaXRloa9zIGFwcGxpY2F0aW9uIHdpbGwgdW5kZXJzdGFuZCB0aGUgc2lnbmFs aW5nIGZyb20gdGhlIG90aGVyLg0KDQpVbmxlc3Mgd2Vic2l0ZXMgYWdyZWUgdG8gdXNlIHNvbWV0 aGluZyBzdGFuZGFyZCBzdWNoIGFzIFNJUC9KaW5nbGUgZm9yIGZlZGVyYXRpb24gKGludGVyIHdl YnNpdGUvZG9tYWluIGNvbW11bmljYXRpb24pLg0KDQotDQpNb3kNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0 Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K --_000_034C870DB898BE43B5787C7A79107CD94BFA5254nkgeml507mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

    Thanks for= your comments.

    Yes, we ca= n implement the federation between SPs through using the same signaling pro= tocol (e.g. SIP) or deploying a gateway.

     = ;

    But what I= concern is how to compatible with the existing various user id from differ= ent SPs. For example, if Google provides WebRTC client, then the users should be able to login using their Gmail address. In the same w= ay, Facebook support the users using FacebookId. So the format of identific= ation may be number, string or email and so on.

     = ;

    The proble= m is how to handle addressing users of different SPs. Should it be standard= ized to a unified WebRTC URI?

     = ;

    Yahui=

     = ;

    =B7=A2=BC=FE=C8=CB: Hrishik= esh Kulkarni [mailto:rishi@turtleyogi.com]
    =B7=A2= =CB=CD=CA=B1=BC=E4: 2013=C4=EA6=D4=C229=C8=D5 14:18
    =CA=D5=BC=FE=C8=CB: Moises Silva
    =B3=AD=CB=CD: Jim Barnett; Wangyahui (Yahui); rtcweb@ietf.org
    =D6=F7=CC=E2: Re: [rtcweb] WebRTC service between SPs

     

    SIP is an established standard = to interoperate domains. We at OneKlikStreet.com developed a video/audio br= idging service for WebRTC. Although it uses JS/JSON signaling for web based= clients. Our server could very well federate with any other service using SIP. What does need to be discussed = on app to app basis is what kind of federation you are looking for? 

    In case of bridging service we = could merge calls from both servers or redirect all the calls to the host s= ervice.

     

    regards,

    Rishi

    Founder, OneKlikStreet.com=

     

     

    =  

    On Fri, Jun 28, 2013 at 11:55 P= M, Moises Silva <moises.silva@gmail.com> wrote:

     

    On Fri, Jun 28, 2013 at 12:03 P= M, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:

    As I understand it, it= =A1=AFs not just a problem of identities.  WebRTC does not define the signaling protocol, but leaves it  up to the application.  If tw= o users download their applications/JavaScript from the same site, it won= =A1=AFt be a problem, because the same application is handling both ends of= the call.  But if one user is on site A while the other is on site B, there is no guarantee that either site=A1=AFs applicat= ion will understand the signaling from the other.

     

    Unless websites agree to use so= mething standard such as SIP/Jingle for federation (inter website/domain co= mmunication).

    -

    Moy

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

     

    --_000_034C870DB898BE43B5787C7A79107CD94BFA5254nkgeml507mbxchi_-- From btdingle@gmail.com Sat Jun 29 03:27:05 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95F321F9EE5 for ; Sat, 29 Jun 2013 03:27: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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZVRz1d5RM3R for ; Sat, 29 Jun 2013 03:27:04 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8E021F9EE3 for ; Sat, 29 Jun 2013 03:27:04 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so1895173wes.40 for ; Sat, 29 Jun 2013 03:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UmZD8gI44F+uBLWeo0KZDWrnezmZOPHs+BlyoDXyjCk=; b=kkgq8Cp7f0wosmoZvRvcynvAYc55M1LLRcH0/uonbEBt3F9rFj4Y3i8K99gLxmg8dE 9njRezFcNFOW6X1g4uER5guN4fvHZUG8AsihpWd1JvL4JJG5OIaWFfVA5st/9hkGPdsH QSwECn/dJ7MD7oUMHLXevWBWG06aYirriciuWh+C48WcHFQc+D17WbelbL17gr4QABRg 8N+ykOv4yTxnnDg8O8wtL6Ez/2BNe61XOIEB2G2s5tQtai/VqxT+Tr8X3LSzINhh4qXa +vTxv4K3oKi28bzcIlxsq5tk0kEDrrhqfmeOjX0FcitpS8Bx3Tjjb3wlS05YhxmzCHPZ cJag== X-Received: by 10.180.20.116 with SMTP id m20mr5778005wie.46.1372501623478; Sat, 29 Jun 2013 03:27:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.103.135 with HTTP; Sat, 29 Jun 2013 03:26:43 -0700 (PDT) In-Reply-To: <034C870DB898BE43B5787C7A79107CD94BFA5254@nkgeml507-mbx.china.huawei.com> References: <034C870DB898BE43B5787C7A79107CD94BFA4E1B@nkgeml507-mbx.china.huawei.com> <57A15FAF9E58F841B2B1651FFE16D281052E6B@GENSJZMBX01.msg.int.genesyslab.com> <034C870DB898BE43B5787C7A79107CD94BFA5254@nkgeml507-mbx.china.huawei.com> From: Barry Dingle Date: Sat, 29 Jun 2013 20:26:43 +1000 Message-ID: To: "Wangyahui (Yahui)" Content-Type: multipart/alternative; boundary=bcaec53f2e31b8a36604e0486f34 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC service between SPs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 10:27:06 -0000 --bcaec53f2e31b8a36604e0486f34 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I had assumed that a DNS NAPTR record could be used to provide all the alternate "user id's". Am I right? Cheers, /Barry Barry Dingle Fixed - +61(0)3-9725-3937 Mob - +61(0)41-911-7578 Fellow of University of Melbourne, Electrical and Electronic Eng., Australia > Linux + Android + Apple + Open Source software On Sat, Jun 29, 2013 at 7:29 PM, Wangyahui (Yahui) w= rote: > Thanks for your comments.**** > > Yes, we can implement the federation between SPs through using the same > signaling protocol (e.g. SIP) or deploying a gateway.**** > > ** ** > > But what I concern is how to compatible with the existing various user id > from different SPs. For example, if Google provides WebRTC client, then t= he > users should be able to login using their Gmail address. In the same way, > Facebook support the users using FacebookId. So the format of > identification may be number, string or email and so on.**** > > ** ** > > The problem is how to handle addressing users of different SPs. Should it > be standardized to a unified WebRTC URI?**** > > ** ** > > Yahui**** > > ** ** > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Hrishikesh Kulkarni [mailto:rishi@turtleyo= gi.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2013=E5=B9=B46=E6=9C=8829=E6=97= =A5 14:18 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Moises Silva > *=E6=8A=84=E9=80=81:* Jim Barnett; Wangyahui (Yahui); rtcweb@ietf.org > *=E4=B8=BB=E9=A2=98:* Re: [rtcweb] WebRTC service between SPs**** > > ** ** > > SIP is an established standard to interoperate domains. We at > OneKlikStreet.com developed a video/audio bridging service for WebRTC. > Although it uses JS/JSON signaling for web based clients. Our server coul= d > very well federate with any other service using SIP. What does need to be > discussed on app to app basis is what kind of federation you are looking > for? **** > > In case of bridging service we could merge calls from both servers or > redirect all the calls to the host service.**** > > ** ** > > regards,**** > > Rishi**** > > Founder, OneKlikStreet.com**** > > ** ** > > ** ** > > ** ** > > On Fri, Jun 28, 2013 at 11:55 PM, Moises Silva > wrote:**** > > ** ** > > On Fri, Jun 28, 2013 at 12:03 PM, Jim Barnett > wrote:**** > > As I understand it, it=E2=80=99s not just a problem of identities. WebR= TC does > not define the signaling protocol, but leaves it up to the application. > If two users download their applications/JavaScript from the same site, i= t > won=E2=80=99t be a problem, because the same application is handling both= ends of > the call. But if one user is on site A while the other is on site B, the= re > is no guarantee that either site=E2=80=99s application will understand th= e > signaling from the other.**** > > ** ** > > Unless websites agree to use something standard such as SIP/Jingle for > federation (inter website/domain communication). > > -**** > > Moy**** > > > _______________________________________________ > 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 > > --bcaec53f2e31b8a36604e0486f34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I had assumed that a DNS NAPTR record could be used to pro= vide all the alternate "user id's". Am I right?

    Cheers,
    /Barry

    Barr= y Dingle
    Fixed - +61(0)3-9725-3937=C2=A0 =C2=A0 Mob - +61(0)41-911-7578=C2=A0=C2=A0 =
    Fellow of University of Melbourne, Electrical and Electronic Eng., Aust= ralia
    > Linux + Android + Apple + Open Source software


    On Sat, Jun 29, 2013 at 7:29 PM, Wangyah= ui (Yahui) <yahui.wang@huawei.com> wrote:

    Thanks for= your comments.

    Yes, we ca= n implement the federation between SPs through using the same signaling pro= tocol (e.g. SIP) or deploying a gateway.

    =C2= =A0

    But what I= concern is how to compatible with the existing various user id from differ= ent SPs. For example, if Google provides WebRTC client, then the users should be able to login using their Gmail address. In the same w= ay, Facebook support the users using FacebookId. So the format of identific= ation may be number, string or email and so on.

    =C2= =A0

    The proble= m is how to handle addressing users of different SPs. Should it be standard= ized to a unified WebRTC URI?

    =C2= =A0

    Yahui

    =C2= =A0

    =E5=8F=91=E4=BB=B6=E4=BA=BA: Hrishikesh Kulkarni [mailto:rishi@turtleyogi.com]
    = =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B46=E6=9C=8829=E6=97=A5 14:18
    =E6=94=B6=E4=BB=B6=E4=BA=BA: Moises Silva
    =E6=8A=84=E9=80=81: Jim Barnett; Wangyahui (Yahui); rtcweb@ietf.org
    =E4=B8=BB=E9=A2=98: Re: [rtcweb] WebRTC service between SPs=

    =C2=A0

    SIP is an established standard = to interoperate domains. We at OneKlikStreet.com developed a video/audio br= idging service for WebRTC. Although it uses JS/JSON signaling for web based= clients. Our server could very well federate with any other service using SIP. What does need to be discussed = on app to app basis is what kind of federation you are looking for?=C2=A0

    In case of bridging service we = could merge calls from both servers or redirect all the calls to the host s= ervice.

    =C2=A0

    regards,

    Rishi

    Founder, OneKlikStreet.com

    =C2=A0

    =C2=A0

    = =C2=A0

    On Fri, Jun 28, 2013 at 11:55 P= M, Moises Silva <moises.silva@gmail.com> wrote:

    =C2=A0

    On Fri, Jun 28, 2013 at 12:03 P= M, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:

    As I under= stand it, it=E2=80=99s not just a problem of identities.=C2=A0 WebRTC does = not define the signaling protocol, but leaves it=C2=A0 up to the application.=C2=A0 If tw= o users download their applications/JavaScript from the same site, it won= =E2=80=99t be a problem, because the same application is handling both ends= of the call.=C2=A0 But if one user is on site A while the other is on site B, there is no guarantee that either site=E2=80=99s appli= cation will understand the signaling from the other.

    =C2=A0

    Unless websites agree to use so= mething standard such as SIP/Jingle for federation (inter website/domain co= mmunication).

    -

    Moy

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

    =C2=A0


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


    --bcaec53f2e31b8a36604e0486f34-- From stefan.lk.hakansson@ericsson.com Sat Jun 29 06:18:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0F411E811B for ; Sat, 29 Jun 2013 06:18:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIp1o5wtf5-v for ; Sat, 29 Jun 2013 06:18:02 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C32CE11E8116 for ; Sat, 29 Jun 2013 06:18:00 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-34-51cede87e396 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 59.56.05990.78EDEC15; Sat, 29 Jun 2013 15:17:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Sat, 29 Jun 2013 15:17:58 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Harald Alvestrand Thread-Topic: [rtcweb] More H.264 vs VP8 tests Thread-Index: Ac5vQ4bE4hnmu5ERSv6YOg93i7vBVw== Date: Sat, 29 Jun 2013 13:17:58 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C308D3B@ESESSMB209.ericsson.se> References: <51C96E36.2000907@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvrW77vXOBBjPPqloc6+tis1j7r53d gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4eWU7S8FD1YqXE16yNDBeluti5OSQEDCR eLv5GROELSZx4d56NhBbSOAwo8T3j25djFxA9iJGiYVXrjGCJNgEAiW27lsAViQioCPxcH8D WDOzgLfE+u45LCC2sICuRMPxNVA1ehILn79ggbF37//I3MXIwcEioCrx4oYiiMkr4Ctx77ER xNoCiambtoBNZAQ65/upNVDTxSVuPZkPdaaAxJI955khbFGJl4//sULYShKNS56wQtTrSdyY OoUNwtaWWLbwNVg9r4CgxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsoqRPTcxMye93GgTIzAO Dm75rbqD8c45kUOM0hwsSuK8m/XOBAoJpCeWpGanphakFsUXleakFh9iZOLglGpg3P3w0f5c 4xWi3DLZzT/b+/LNXr9RWH3yW5p2QrLWA9lH34JOpjF6ynD6XXa9MeOvPtv+7OhzzJs6djD8 +hbcfj3LedWqA4yZGdyy8ffuhKQ4vBUOTuZcVH/KyaT0x9ILgh2bl1dmrlBmKY3W/+I3f9Mm 25yeOUk/K25H3/u/rKOf5bMil2mxEktxRqKhFnNRcSIACEmFEFECAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 13:18:07 -0000 On 6/25/13 12:17 PM, Harald Alvestrand wrote:=0A= > Again - thanks for releasing this openly!=0A= >=0A= > I ran the scripts (with a few tweaks; you run on a system where sh is=0A= > bash, not dash, for instance), and got the same numbers within +/- 0.5%= =0A= > (probably some binary version skew);=0A= =0A= I re-run the scripts on another computer with another OS today, and I =0A= get exactly the same results as Bo sent out. I noted however that if the = =0A= input clips are not cut at 10s (but used in their entire length) the =0A= results get slightly different, but within +/- 0.5%. Can this be the =0A= reason why you get slightly different numbers?=0A= =0A= =0A= > we may have disagreements on the=0A= > parameters to use, but we agree on the numbers those parameters produce.= =0A= >=0A= > (I have since modified the Google framework to include a script that=0A= > pulls in the sources for the needed binaries and compiles them - if you= =0A= > want to make 100% sure people are working from the same sources, you may= =0A= > want to rebase to a newer version of the comparision toolkit.)=0A= >=0A= > On 06/22/2013 03:41 PM, Bo Burman wrote:=0A= >> Hi all,=0A= >>=0A= >> We have had a look at Google's comparison between VP8 and H.264 constrai= ned baseline that was posted on April 3rd (http://www.ietf.org/mail-archive= /web/rtcweb/current/msg07028.html). This post contains, as the one mentione= d above (and if the attachments make it to the list), information on the ex= act tools and options used for encoding and should thus be repeatable by an= yone interested.=0A= >>=0A= >> As was already stated by others on this list, one major problem is that = Google's test involves the rate control mechanism. Typically codecs are mea= sured with rate control turned off, since it acts as a huge noise on the me= asurement. Instead we propose to compare the codecs using fixed qp-levels. = The qp-level is the quantization parameter that affects the rate/distortion= tradeoff. Comparing using fixed qp-levels is what has been used when bench= marking HEVC against H.264 in the JCT-VC standardization, for instance. We = are going to select a codec (essentially bit stream format), not a rate con= trol mechanism: Once the codec is selected you can choose whatever rate con= trol mechanism you wish.=0A= >>=0A= >> We used Google's excellent framework as the baseline and changed the par= ameter settings in order to make it possible to measure using fixed qp. We = used the same sequences, but limited them to the first 10 seconds since the= y varied from 10 seconds to minutes; this also eased computation time.=0A= >>=0A= >> We used two H.264 encoder implementations: X264, which is an open-source= codec that can operate in everything from real-time to slow, and JM which = is the reference implementation that was used to develop H.264. JM is very = slow but attempts to be very efficient in terms of bits per quality. The re= sults were as follows:=0A= >>=0A= >> X264 baseline vs VP8: H.264 wins with 1%=0A= >> JM baseline vs VP8: H.264 wins with 4%=0A= >>=0A= >> Running times:=0A= >> X264: 1 hour 3 minutes=0A= >> VP8: 2 hours 0 minutes=0A= >> JM: order of magnitude slower=0A= >>=0A= >> It is interesting to note that the measurements are more stable in the n= ew test; the variance of the percentages for the sequences is now around 70= , down from around 700 in Google's test of April 3rd. We believe this is d= ue to the removal of the rate controller, which acts like noise on the meas= urements.=0A= >>=0A= >> We also tried setting H.264 to constrained high (no interlace and no B-p= ictures, compared to high). The results were then:=0A= >>=0A= >> X264 constrained high vs VP8: H.264 wins with 25%=0A= >> JM constrained high vs VP8: H.264 wins with 24%=0A= >>=0A= >> We also note that the script that Google provided to calculate the rate = differences ("BD-rate") does not give exactly the same numbers as the JCT-V= C-way of calculating BD-rate. The main difference is that the JM score for = constrained high is better (around 29%) if the JCT-VC way of calculating BD= -rate is used.=0A= >>=0A= >> In summary we think that proper testing can conclude that there is no cl= ear performance advantage to any codec between VP8 and H.264 baseline. When= comparing VP8 against H.264 constrained high on the other hand, it seems l= ike there is an advantage for H.264 constrained high.=0A= >>=0A= >> The attached file includes the files necessary to reproduce the test.=0A= >>=0A= >> Best Regards,=0A= >>=0A= >> Bo Burman=0A= >>=0A= >>=0A= >> _______________________________________________=0A= >> rtcweb mailing list=0A= >> rtcweb@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From ekr@rtfm.com Sat Jun 29 06:25:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1FB11E8127 for ; Sat, 29 Jun 2013 06:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.721 X-Spam-Level: X-Spam-Status: No, score=-101.721 tagged_above=-999 required=5 tests=[AWL=0.955, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX8xAUNi-rWS for ; Sat, 29 Jun 2013 06:25:23 -0700 (PDT) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id D4DBA11E8117 for ; Sat, 29 Jun 2013 06:25:22 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id s14so1051938qeb.15 for ; Sat, 29 Jun 2013 06:25:22 -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=POzV4WNBsKdzd/5msHdnsCTXFuWyaXpK7by1w15fMw8=; b=I0DBzQ/O1O7uSohZ09GWtsPP/DYqnHV3QaaEWT9/AZGhZRxHHYje3JVAo7DrtlwE3O 0zCcdfExHN33iFKv7Uib6oS8HkY/dI6yhunQBIq1R5RHpRXNbkwED79HKZwwFq5z5yKI 3MmrNlIG+mUUkoltiQcxMx+keImLG3tuqEresjUKJeLrRc00nfCvuHIzmzxv88rusRRb sTclb8eLB9y6b4UW7DSRnmuVv0A4tS1trELaUS0C97hZPgJcTzwqND4t+Fc6KNijlzwM iPJfPlpA8euYSzTfmZnCc4XXePgHssK6zMwlJJZpimXJo8CAYzvMKyjjm228gXc+LS4o 8gsA== X-Received: by 10.49.130.8 with SMTP id oa8mr22566380qeb.87.1372512322372; Sat, 29 Jun 2013 06:25:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.94.137 with HTTP; Sat, 29 Jun 2013 06:24:42 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Sat, 29 Jun 2013 06:24:42 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b873a0a6cd69204e04aeda4 X-Gm-Message-State: ALoCoQm5z4FE3SaKSbKBesKwY2seGrjPNt3qC5ZDKN3BhLRxi0xRjpM31Gjl0JEKiw12wdfGg9mT Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 13:25:28 -0000 --047d7b873a0a6cd69204e04aeda4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jun 28, 2013 at 11:23 PM, I=F1aki Baz Castillo wrot= e: > Cullen, do you think that W3C would ever design a JS API that forces the > developer to deal with an unmanageable blob string? Can somebody point me > to an existing similar "API" in HTML5? > Well, the original WHATWG specification had more or less the same structure of having the PeerConnection emit an opaque SDP blob. I.e., this is a design that originally comes from Ian Hickson. -Ekr --047d7b873a0a6cd69204e04aeda4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --047d7b873a0a6cd69204e04aeda4-- From fluffy@cisco.com Sat Jun 29 14:10:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BBD21F9F13 for ; Sat, 29 Jun 2013 14:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.349 X-Spam-Level: X-Spam-Status: No, score=-110.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8R+o+AmOcXkd for ; Sat, 29 Jun 2013 14:10:42 -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 BBD6221F9F12 for ; Sat, 29 Jun 2013 14:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=321; q=dns/txt; s=iport; t=1372540238; x=1373749838; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SjMtvjDeOT6FFT/vY8rXkqlvouzkrdz+f7TZnnKtwzQ=; b=gZv/uWJ9wwQn1r3eZcDJdm0+xdnhrCJC00n2aP7qhjkNgJVejaiAnAB8 TKVWjQON8g4GJLErW/5x6O7UdzrCNKG7q2uf9rKkWINPgheAnMMfCa6C6 X7E1Aqb4AdyPrKOMmmoFKRBBxwjMKmLfaTj7fzHXaGxgryW2g7Q+OJS7t M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAKVLz1GtJV2Y/2dsb2JhbABagwl7vxKBABZ0giMBAQEDAXkFCwIBCCIZCzIlAgQOBQiIAQa6ZI8rAjEHgwRjA4hroCKBWIE5gig X-IronPort-AV: E=Sophos;i="4.87,967,1363132800"; d="scan'208";a="229045683" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 29 Jun 2013 21:10:38 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5TLAcXw007573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Jun 2013 21:10:38 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Sat, 29 Jun 2013 16:10:37 -0500 From: "Cullen Jennings (fluffy)" To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) Thread-Index: AQHOdJEmOvnZG+z+f0Kk7cl3DKmS85lNhOCA Date: Sat, 29 Jun 2013 21:10:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.126.5] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 21:10:47 -0000 On Jun 28, 2013, at 11:23 PM, I=F1aki Baz Castillo wrote: > Cullen, do you think that W3C would ever design a JS API that forces the = developer to deal with an unmanageable blob string? Can somebody point me t= o an existing similar "API" in HTML5? Uh, the video tag seems pretty popular... From robin@hookflash.com Sat Jun 29 20:28:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFA421F8FF8 for ; Sat, 29 Jun 2013 20:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+vlfX5xJfRR for ; Sat, 29 Jun 2013 20:28:28 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6A54E21F8C38 for ; Sat, 29 Jun 2013 20:28:28 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id u16so7142581iet.9 for ; Sat, 29 Jun 2013 20:28:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=8s1bok0erTqtx0O65IP/g9yhXJ2QlY3I4DC1BzyprkM=; b=me30zEoG3OTlKXVAxbH2/SY5mLAFmgMh+XMlFwFn2VWpZDPsOiZX+Asi2Mg3lhJdJf enFg4r4lYBwN5300doAuyRSwVfQlnKllrzZgnaj3455X7r86XiYhSq2SZUtu1w28Uwgf ZxyUsbYzIrVtCygU5mrjlwSOlDFYVaSPOzB/RWdeNZaZpNEbvIn7qCR0lMqpMGTVxQp3 h1Agjso5UoXfvMf9FlvftHqCwchC5CDKz6qKO4b+oZGE7ASU8Dg3sUzlunqIrOpXeTTJ Coh3ZLIr57TX6UVR2lQS5CJme+oIKLSWu1ZHKN49X9F2St0ognSLRpjLNmMqoZaSEF4t HkTQ== X-Received: by 10.50.8.10 with SMTP id n10mr10328437iga.20.1372562907897; Sat, 29 Jun 2013 20:28:27 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id p6sm6687161iga.10.2013.06.29.20.28.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 29 Jun 2013 20:28:26 -0700 (PDT) Message-ID: <51CFA5D6.201@hookflash.com> Date: Sat, 29 Jun 2013 23:28:22 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020001030303080200000705" X-Gm-Message-State: ALoCoQkty0EZTjOLpkKFREpG0XOkSP2fn2Dp4g46z8St8jqRkOeVRSJ8jFg06B1M7ibX0Hk4JvvC Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jun 2013 03:28:33 -0000 This is a multi-part message in MIME format. --------------020001030303080200000705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit You mean this HTML 5 video tag, right? This one: Versus this SDP blob that many of us must parse/mangle/generate from our code if we want to go beyond a basic demo: v=0 o=- 3572342242 3 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio data a=msid-semantic: WMS m=audio 54680 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126 c=IN IP4 97.213.43.112 a=rtcp:54680 IN IP4 97.213.43.112 a=candidate:4099047770 1 udp 2113937151 192.168.17.159 54680 typ host generation 0 a=candidate:4099047770 2 udp 2113937151 192.168.17.159 54680 typ host generation 0 a=candidate:1965854185 1 udp 2113937151 192.168.17.214 57626 typ host generation 0 a=candidate:1965854185 2 udp 2113937151 192.168.17.214 57626 typ host generation 0 a=candidate:954187465 1 udp 1845501695 97.213.43.112 54680 typ srflx raddr 192.168.17.159 rport 54680 generation 0 a=candidate:954187465 2 udp 1845501695 97.213.43.112 54680 typ srflx raddr 192.168.17.159 rport 54680 generation 0 a=candidate:3114381946 1 udp 1845501695 97.213.43.112 57626 typ srflx raddr 192.168.17.214 rport 57626 generation 0 a=candidate:3114381946 2 udp 1845501695 97.213.43.112 57626 typ srflx raddr 192.168.17.214 rport 57626 generation 0 a=candidate:3134291370 1 tcp 1509957375 192.168.17.159 49802 typ host generation 0 a=candidate:3134291370 2 tcp 1509957375 192.168.17.159 49802 typ host generation 0 a=candidate:1001353497 1 tcp 1509957375 192.168.17.214 49803 typ host generation 0 a=candidate:1001353497 2 tcp 1509957375 192.168.17.214 49803 typ host generation 0 a=ice-ufrag:zFLN0q7y22aeZBhg a=ice-pwd:KGoEmNSd9a5eRgSa9Whh7qaS a=ice-options:google-ice a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=recvonly a=mid:audio a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9aibUYmy/+AhPzg3nsbrKO7YFLBs0ekn0h8hTFID a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:107 CN/48000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 m=application 54680 RTP/SAVPF 101 c=IN IP4 97.213.43.112 a=rtcp:54680 IN IP4 97.213.43.112 a=candidate:4099047770 1 udp 2113937151 192.168.17.159 54680 typ host generation 0 a=candidate:4099047770 2 udp 2113937151 192.168.17.159 54680 typ host generation 0 a=candidate:1965854185 1 udp 2113937151 192.168.17.214 57626 typ host generation 0 a=candidate:1965854185 2 udp 2113937151 192.168.17.214 57626 typ host generation 0 a=candidate:954187465 1 udp 1845501695 97.213.43.112 54680 typ srflx raddr 192.168.17.159 rport 54680 generation 0 a=candidate:954187465 2 udp 1845501695 97.213.43.112 54680 typ srflx raddr 192.168.17.159 rport 54680 generation 0 a=candidate:3114381946 1 udp 1845501695 97.213.43.112 57626 typ srflx raddr 192.168.17.214 rport 57626 generation 0 a=candidate:3114381946 2 udp 1845501695 97.213.43.112 57626 typ srflx raddr 192.168.17.214 rport 57626 generation 0 a=candidate:3134291370 1 tcp 1509957375 192.168.17.159 49802 typ host generation 0 a=candidate:3134291370 2 tcp 1509957375 192.168.17.159 49802 typ host generation 0 a=candidate:1001353497 1 tcp 1509957375 192.168.17.214 49803 typ host generation 0 a=candidate:1001353497 2 tcp 1509957375 192.168.17.214 49803 typ host generation 0 a=ice-ufrag:zFLN0q7y22aeZBhg a=ice-pwd:KGoEmNSd9a5eRgSa9Whh7qaS a=ice-options:google-ice a=sendrecv a=mid:data b=AS:30 a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9aibUYmy/+AhPzg3nsbrKO7YFLBs0ekn0h8hTFID a=rtpmap:101 google-data/90000 a=ssrc:2838167882 cname:X00v2LuQqKzLnkBs a=ssrc:2838167882 msid:messaging messaging a=ssrc:2838167882 mslabel:messaging a=ssrc:2838167882 label:messaging Please clarify if I misunderstand you. -Robin > Cullen Jennings (fluffy) > 29 June, 2013 5:10 PM > On Jun 28, 2013, at 11:23 PM, Iñaki Baz Castillo > > Uh, the video tag seems pretty popular... > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Iñaki Baz Castillo > 29 June, 2013 2:23 AM > > Cullen, do you think that W3C would ever design a JS API that forces > the developer to deal with an unmanageable blob string? Can somebody > point me to an existing similar "API" in HTML5? > > The problem is that telcos are much more used to IETF processes than > Web people and hence this WG is dominated by telcos proposing their > first API for the W3C, an API to satisfy their existing business model > (the webphone). > > It is time to leave Web experts to design a really useful API for WebRTC. > > -- > Iñaki Baz Castillo > > > > --------------020001030303080200000705 Content-Type: multipart/related; boundary="------------090608040904020004040606" --------------090608040904020004040606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    You mean this HTML 5 video tag, right? This one:

    <video poster="movie.jpg" controls>
        <source src="movie.webm" type='video/webm; codecs="vp8.0, vorbis"'/>
        <source src="movie.ogg" type='video/ogg; codecs="theora, vorbis"'/>
        <source src="movie.mp4" type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'/>
        <p>This is fallback content</p>
</video>
     

    Versus this SDP blob that many of us must parse/mangle/generate from our code if we want to go beyond a basic demo:

    v=0
    o=- 3572342242 3 IN IP4 127.0.0.1
    s=-
    t=0 0
    a=group:BUNDLE audio data
    a=msid-semantic: WMS
    m=audio 54680 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126
    c=IN IP4 97.213.43.112
    a=rtcp:54680 IN IP4 97.213.43.112
    a=candidate:4099047770 1 udp 2113937151 192.168.17.159 54680 typ host generation 0
    a=candidate:4099047770 2 udp 2113937151 192.168.17.159 54680 typ host generation 0
    a=candidate:1965854185 1 udp 2113937151 192.168.17.214 57626 typ host generation 0
    a=candidate:1965854185 2 udp 2113937151 192.168.17.214 57626 typ host generation 0
    a=candidate:954187465 1 udp 1845501695 97.213.43.112 54680 typ srflx raddr 192.168.17.159 rport 54680 generation 0
    a=candidate:954187465 2 udp 1845501695 97.213.43.112 54680 typ srflx raddr 192.168.17.159 rport 54680 generation 0
    a=candidate:3114381946 1 udp 1845501695 97.213.43.112 57626 typ srflx raddr 192.168.17.214 rport 57626 generation 0
    a=candidate:3114381946 2 udp 1845501695 97.213.43.112 57626 typ srflx raddr 192.168.17.214 rport 57626 generation 0
    a=candidate:3134291370 1 tcp 1509957375 192.168.17.159 49802 typ host generation 0
    a=candidate:3134291370 2 tcp 1509957375 192.168.17.159 49802 typ host generation 0
    a=candidate:1001353497 1 tcp 1509957375 192.168.17.214 49803 typ host generation 0
    a=candidate:1001353497 2 tcp 1509957375 192.168.17.214 49803 typ host generation 0
    a=ice-ufrag:zFLN0q7y22aeZBhg
    a=ice-pwd:KGoEmNSd9a5eRgSa9Whh7qaS
    a=ice-options:google-ice
    a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
    a=recvonly
    a=mid:audio
    a=rtcp-mux
    a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9aibUYmy/+AhPzg3nsbrKO7YFLBs0ekn0h8hTFID
    a=rtpmap:111 opus/48000/2
    a=fmtp:111 minptime=10
    a=rtpmap:103 ISAC/16000
    a=rtpmap:104 ISAC/32000
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:107 CN/48000
    a=rtpmap:106 CN/32000
    a=rtpmap:105 CN/16000
    a=rtpmap:13 CN/8000
    a=rtpmap:126 telephone-event/8000
    a=maxptime:60
    m=application 54680 RTP/SAVPF 101
    c=IN IP4 97.213.43.112
    a=rtcp:54680 IN IP4 97.213.43.112
    a=candidate:4099047770 1 udp 2113937151 192.168.17.159 54680 typ host generation 0
    a=candidate:4099047770 2 udp 2113937151 192.168.17.159 54680 typ host generation 0
    a=candidate:1965854185 1 udp 2113937151 192.168.17.214 57626 typ host generation 0
    a=candidate:1965854185 2 udp 2113937151 192.168.17.214 57626 typ host generation 0
    a=candidate:954187465 1 udp 1845501695 97.213.43.112 54680 typ srflx raddr 192.168.17.159 rport 54680 generation 0
    a=candidate:954187465 2 udp 1845501695 97.213.43.112 54680 typ srflx raddr 192.168.17.159 rport 54680 generation 0
    a=candidate:3114381946 1 udp 1845501695 97.213.43.112 57626 typ srflx raddr 192.168.17.214 rport 57626 generation 0
    a=candidate:3114381946 2 udp 1845501695 97.213.43.112 57626 typ srflx raddr 192.168.17.214 rport 57626 generation 0
    a=candidate:3134291370 1 tcp 1509957375 192.168.17.159 49802 typ host generation 0
    a=candidate:3134291370 2 tcp 1509957375 192.168.17.159 49802 typ host generation 0
    a=candidate:1001353497 1 tcp 1509957375 192.168.17.214 49803 typ host generation 0
    a=candidate:1001353497 2 tcp 1509957375 192.168.17.214 49803 typ host generation 0
    a=ice-ufrag:zFLN0q7y22aeZBhg
    a=ice-pwd:KGoEmNSd9a5eRgSa9Whh7qaS
    a=ice-options:google-ice
    a=sendrecv
    a=mid:data
    b=AS:30
    a=rtcp-mux
    a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9aibUYmy/+AhPzg3nsbrKO7YFLBs0ekn0h8hTFID
    a=rtpmap:101 google-data/90000
    a=ssrc:2838167882 cname:X00v2LuQqKzLnkBs
    a=ssrc:2838167882 msid:messaging messaging
    a=ssrc:2838167882 mslabel:messaging
    a=ssrc:2838167882 label:messaging


    Please clarify if I misunderstand you.

    -Robin
    29 June, 2013 5:10 PM
    On Jun 28, 2013, at 11:23 PM, Iñaki Baz Castillo <ibc@aliax.net>

    Uh, the video tag seems pretty popular...

    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    29 June, 2013 2:23 AM

    Cullen, do you think that W3C would ever design a JS API that forces the developer to deal with an unmanageable blob string? Can somebody point me to an existing similar "API" in HTML5?

    The problem is that telcos are much more used to IETF processes than Web people and hence this WG is dominated by telcos proposing their first API for the W3C, an API to satisfy their existing business model (the webphone).

    It is time to leave Web experts to design a really useful API for WebRTC.

    --
    Iñaki Baz Castillo
    <ibc@aliax.net>


    --------------090608040904020004040606 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDyz4PaTo91ev8AGf40X1vcT34tbmOa/wBO gmkuZXt0Z5XdkLZLk4XcAAAAAAAOGtXvLkienQw6UfaSPQdW17wh4u1VtT8Dato0tvs8u4t/ 7JtiUwxb5dyblyTnuK53KcdztUIVFdHiM2rXVt8arFpItOsIEu1JaHToInKkgZSREDK+cEMC CCAe1dlOpeB51Wnadz17/hq74jf9Fj8Wf+A1p/hT+8wt5GjY/E/4f3HgPSPDI0ptRSbTba2S O1wWysKDJBxg/WuRwnSm7rU9qnJKHLIxNT+Euj6B8LNd8Y+AzKmr3sUbWnnlf3LlgNuFO3gc Y9etVZy1nsDpezi/ZnzjpyeOdW+Jel6dqS+ZqOkSxzXO5QDtaRdpPbjg8+tdNOEVFtHmVHLm SYz+0Piv/wBBHVf/AAGH/wARWnMzG8e5k2Nzf6fPA9x9p0280/ZE3mM0TxyRqFZGBwQQQQR1 HNdbiprU9iH7yCufQPwJ+FXxU+OGtjw74F1GX+ztVfzr+SSY/ZbRMjdO+3jIxgDAZjjr1rz6 lNuXKkc9Wt7Bbn6L/AT9jH4Z/APW9V+Imo6vP4k8TXyDzdV1FEiitIVUArFGOFGByzFj7iui MVBWR5VSq6ruzxD+w/EX/Qq6j/4Av/8AE1V2Zn55/tr/APJzHj7/AK/0/wDREdX0O/7KOx/Y f6+J/wDrna/zelI56+yPsPwf/wAjbof/AGEbb/0atSYH6JUAf//Z --------------090608040904020004040606 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxD9py+sZfjkviDxZNpF7b6h4d024uZb2x t7iQ3Ei/NuZkLAnggZwAwwAMVni+ZaU9ztwUafM5VtjEbQ/g0PD3/CSiz8MiBG2hlsrfBf02 iPn6Vwc+I2uel7DCfHbQn/Zrv9HvP2kfDcmk2+k2umTWl2q+TpkFs5kUAABljV1bLAjBByM1 24NzWlR6nnYyEG1KitD6v/4X78Wf+h4vv++Y/wD4mu3lRwninx/8CWFzqnhTxPelfsmuaPb2 cvOGE0UMZBz/ALgH5GuTGxcf3qPUwEoT/dSPKU8P+G1hGgb4vsP25l4cbgNgXP6detec5T+I 9lUaXLynqf7OHgDT7n4knX7IRiw8NKiLk5dppCSuPbCsT9BXZgqbqv2j6Hl46pClenHqrGl/ aC+o/OvSPGND9om/0xvhX4W0t763TXbSW1aOxeQC4ASBo5gU6jDYByBgjHWscY4+z1OnCX9r ofOZvNPWMvJc3PD7jAN2Q3pj0z2ryby5T3/rEeXlsfQv7K/iDw1pOhapZ6nrNjaa3e3xuGtJ 51SUwJGu1gCRkDLZxnFelgZQ9m0meHjU/aXZQ/4RHxx/0Jmvf+C6b/4mujmOM8Y/bJ/5PT+K P/X3a/8AoiKuLEbI6cN8R5mf9RP/ANdK5mdg7wx/yVDwJ/2Nmm/+jkrajuc2K2R+9VdJxn// 2Q== --------------090608040904020004040606-- --------------020001030303080200000705-- From stefan.lk.hakansson@ericsson.com Sat Jun 29 22:23:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486C721F9DEE for ; Sat, 29 Jun 2013 22:23:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5vY5NVtTmr7 for ; Sat, 29 Jun 2013 22:23:48 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9667621F9B2A for ; Sat, 29 Jun 2013 22:23:47 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-23-51cfc0e187a8 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5E.49.05990.1E0CFC15; Sun, 30 Jun 2013 07:23:45 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Sun, 30 Jun 2013 07:23:45 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Peter Thatcher Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) Thread-Index: AQHOa1pIfKQNX7+x70mEbzKV/FqHgg== Date: Sun, 30 Jun 2013 05:23:45 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C308DC9@ESESSMB209.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvre7DA+cDDc4eNrfomMxmcW35a1aL tf/a2R2YPab83sjqsWBTqceSJT+ZApijuGxSUnMyy1KL9O0SuDL+LOllLZjKU/F52TumBsaz nF2MnBwSAiYSCzo/MUHYYhIX7q1n62Lk4hASOMwosffYO0YIZxGjxLPdW1hAqtgEAiW27lvA BmKLCGhKTJ7czApiMwtESezY1AM0iYNDWCBfYsKzcBBTRKBA4tBORohqPYneK7PBbBYBVYmL Bx+D2bwCvhJnl75ngVi1kEmi8fI6sFWMQAd9P7WGCWK8uMStJ/OhDhWQWLLnPDOELSrx8vE/ VghbSaJxyROoc/QkbkydwgZha0ssW/iaGWKZoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKK kT03MTMnvdxoEyMwNg5u+a26g/HOOZFDjNIcLErivJv1zgQKCaQnlqRmp6YWpBbFF5XmpBYf YmTi4JRqYJz9zW/fShWF76KMMxdb+v7+JBt6NPrdrPzPhz7U2fn0puywn7pxxhxlux2z90Qb n3/fsS70/w2FcFmZrR3FQq7yvfYCfYfE9Wam7HS7pzLH2+Gp8r92mdvZtpkPjNqb0gLq7Q7l 8IQqbn2mqHzh6pbdV9OL9tUt1dA1eLjk47SPS8VS7h9ZEq/EUpyRaKjFXFScCACzv/KqWwIA AA== Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jun 2013 05:23:54 -0000 On 2013-06-29 01:31, Peter Thatcher wrote:=0A= > FYI, you might find some in this doc:=0A= >=0A= > https://docs.google.com/spreadsheet/ccc?key=3D0AuaKXw3SkHMSdHlZdV9RN0xSWF= hybVl4anJLRkVPV0E#gid=3D0=0A= =0A= I think it would be very helpful if people could provide some more =0A= detailed info about what modifications to the SDP they have been trying =0A= to do and why.=0A= =0A= That would give some guidance for what API functions that should be =0A= provided.=0A= =0A= =0A= >=0A= > About nine developers have listed what they are trying to do and what=0A= > pain they are running into, with SDP specifically. Granted, it's only=0A= > what can fit in a single spreadsheet cell, but I'm sure you can ask for= =0A= > further details if you are interested. But at least one did mention how= =0A= > well SDP is working for them, so there's input on both sides.=0A= >=0A= >=0A= >=0A= > On Fri, Jun 28, 2013 at 3:28 PM, Cullen Jennings (fluffy)=0A= > > wrote:=0A= >=0A= >=0A= > On Jun 17, 2013, at 6:00 PM, Silvia Pfeiffer=0A= > > wrote:= =0A= >=0A= > > Having hit my=0A= > > head hard against the limitations of the current WebRTC API and be= ing=0A= > > forced to learn SDP to achieve some of the less common use cases, = I'm=0A= > > feeling the pain.=0A= >=0A= > Could you let us know the use cases of what it is you need an easy=0A= > way to do ?=0A= >=0A= >=0A= =0A= From radhika.r.roy.civ@mail.mil Sun Jun 30 06:42:13 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A775921F9A70 for ; Sun, 30 Jun 2013 06:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExmAkqjhBrkG for ; Sun, 30 Jun 2013 06:42:08 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.13]) by ietfa.amsl.com (Postfix) with ESMTP id 67B0921F9A75 for ; Sun, 30 Jun 2013 06:42:08 -0700 (PDT) Received: from UCOLHP3E.easf.csd.disa.mil (131.64.100.144) by edge-cols.mail.mil (131.64.100.13) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 30 Jun 2013 13:42:00 +0000 Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.175]) by UCOLHP3E.easf.csd.disa.mil ([131.64.100.144]) with mapi id 14.03.0123.003; Sun, 30 Jun 2013 13:41:57 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: Robin Raymond , "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) (UNCLASSIFIED) Thread-Index: AQHOdJE2W6iGgSZ9hkeOJyr4v3GME5lNMRGAgABpiwCAAKa8MA== Date: Sun, 30 Jun 2013 13:41:54 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF49B13BC6@ucolhp9b.easf.csd.disa.mil> References: <51CFA5D6.201@hookflash.com> In-Reply-To: <51CFA5D6.201@hookflash.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0030_01CE7575.BBA61410" MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jun 2013 13:42:13 -0000 ------=_NextPart_000_0030_01CE7575.BBA61410 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Classification: UNCLASSIFIED Caveats: NONE Is it not the comparison of multi-dimensional intelligence (XML-script) = vs. one-dimensional intelligence (Binary) in expressing the description of a "multimedia session?" If it so, why are we waiting for as we know in the very beginning of the technical debate between H.323 (H.245) and SIP (SDP) where H.245 can negotiate and evolve a call between the two parties where media bridging = is not needed to a multi-party call that includes the media bridging automatically (while SDP cannot do so dynamically - that has been = another important limitations of SDP)? Best regards, Radhika -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Robin Raymond Sent: Saturday, June 29, 2013 11:28 PM To: Cullen Jennings (fluffy) Cc: Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) You mean this HTML 5 video tag, right? This one: =20 Versus this SDP blob that many of us must parse/mangle/generate from our code if we want to go beyond a basic demo: v=3D0 o=3D- 3572342242 3 IN IP4 127.0.0.1 s=3D- t=3D0 0 a=3Dgroup:BUNDLE audio data a=3Dmsid-semantic: WMS m=3Daudio 54680 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126 c=3DIN IP4 97.213.43.112 a=3Drtcp:54680 IN IP4 97.213.43.112 a=3Dcandidate:4099047770 1 udp 2113937151 192.168.17.159 54680 typ host generation 0 a=3Dcandidate:4099047770 2 udp 2113937151 192.168.17.159 54680 typ host generation 0 a=3Dcandidate:1965854185 1 udp 2113937151 192.168.17.214 57626 typ host generation 0 a=3Dcandidate:1965854185 2 udp 2113937151 192.168.17.214 57626 typ host generation 0 a=3Dcandidate:954187465 1 udp 1845501695 97.213.43.112 54680 typ srflx = raddr 192.168.17.159 rport 54680 generation 0 a=3Dcandidate:954187465 2 udp 1845501695 97.213.43.112 54680 typ srflx = raddr 192.168.17.159 rport 54680 generation 0 a=3Dcandidate:3114381946 1 udp 1845501695 97.213.43.112 57626 typ srflx = raddr 192.168.17.214 rport 57626 generation 0 a=3Dcandidate:3114381946 2 udp 1845501695 97.213.43.112 57626 typ srflx = raddr 192.168.17.214 rport 57626 generation 0 a=3Dcandidate:3134291370 1 tcp 1509957375 192.168.17.159 49802 typ host generation 0 a=3Dcandidate:3134291370 2 tcp 1509957375 192.168.17.159 49802 typ host generation 0 a=3Dcandidate:1001353497 1 tcp 1509957375 192.168.17.214 49803 typ host generation 0 a=3Dcandidate:1001353497 2 tcp 1509957375 192.168.17.214 49803 typ host generation 0 a=3Dice-ufrag:zFLN0q7y22aeZBhg = a=3Dice-pwd:KGoEmNSd9a5eRgSa9Whh7qaS a=3Dice-options:google-ice a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=3Drecvonly a=3Dmid:audio a=3Drtcp-mux a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_80 inline:9aibUYmy/+AhPzg3nsbrKO7YFLBs0ekn0h8hTFID a=3Drtpmap:111 opus/48000/2 a=3Dfmtp:111 minptime=3D10 a=3Drtpmap:103 ISAC/16000 a=3Drtpmap:104 ISAC/32000 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:107 CN/48000 a=3Drtpmap:106 CN/32000 a=3Drtpmap:105 CN/16000 a=3Drtpmap:13 CN/8000 a=3Drtpmap:126 telephone-event/8000 a=3Dmaxptime:60 m=3Dapplication 54680 RTP/SAVPF 101 c=3DIN IP4 97.213.43.112 a=3Drtcp:54680 IN IP4 97.213.43.112 a=3Dcandidate:4099047770 1 udp 2113937151 192.168.17.159 54680 typ host generation 0 a=3Dcandidate:4099047770 2 udp 2113937151 192.168.17.159 54680 typ host generation 0 a=3Dcandidate:1965854185 1 udp 2113937151 192.168.17.214 57626 typ host generation 0 a=3Dcandidate:1965854185 2 udp 2113937151 192.168.17.214 57626 typ host generation 0 a=3Dcandidate:954187465 1 udp 1845501695 97.213.43.112 54680 typ srflx = raddr 192.168.17.159 rport 54680 generation 0 a=3Dcandidate:954187465 2 udp 1845501695 97.213.43.112 54680 typ srflx = raddr 192.168.17.159 rport 54680 generation 0 a=3Dcandidate:3114381946 1 udp 1845501695 97.213.43.112 57626 typ srflx = raddr 192.168.17.214 rport 57626 generation 0 a=3Dcandidate:3114381946 2 udp 1845501695 97.213.43.112 57626 typ srflx = raddr 192.168.17.214 rport 57626 generation 0 a=3Dcandidate:3134291370 1 tcp 1509957375 192.168.17.159 49802 typ host generation 0 a=3Dcandidate:3134291370 2 tcp 1509957375 192.168.17.159 49802 typ host generation 0 a=3Dcandidate:1001353497 1 tcp 1509957375 192.168.17.214 49803 typ host generation 0 a=3Dcandidate:1001353497 2 tcp 1509957375 192.168.17.214 49803 typ host generation 0 a=3Dice-ufrag:zFLN0q7y22aeZBhg = a=3Dice-pwd:KGoEmNSd9a5eRgSa9Whh7qaS a=3Dice-options:google-ice a=3Dsendrecv a=3Dmid:data b=3DAS:30 a=3Drtcp-mux a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_80 inline:9aibUYmy/+AhPzg3nsbrKO7YFLBs0ekn0h8hTFID a=3Drtpmap:101 google-data/90000 a=3Dssrc:2838167882 cname:X00v2LuQqKzLnkBs a=3Dssrc:2838167882 msid:messaging messaging a=3Dssrc:2838167882 mslabel:messaging a=3Dssrc:2838167882 label:messaging Please clarify if I misunderstand you. -Robin =09 Cullen Jennings (fluffy) =20 29 June, 2013 5:10 PM On Jun 28, 2013, at 11:23 PM, I=F1aki Baz Castillo =20 =09 Uh, the video tag seems pretty popular... =09 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =09 =09 I=F1aki Baz Castillo =20 29 June, 2013 2:23 AM Cullen, do you think that W3C would ever design a JS API that forces the developer to deal with an unmanageable blob string? Can somebody = point me to an existing similar "API" in HTML5? The problem is that telcos are much more used to IETF processes than Web people and hence this WG is dominated by telcos proposing their = first API for the W3C, an API to satisfy their existing business model (the webphone). It is time to leave Web experts to design a really useful API for WebRTC. =09 =09 -- I=F1aki Baz Castillo Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0030_01CE7575.BBA61410 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMzA2MzAxMzM5MzZaMCMGCSqGSIb3DQEJBDEWBBShlM48jEiWJVQDIjAel00w T7UlKzBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBALiSIhMZYgbzqWQyY2vE3skWZIyn5BpGYWIdnocPSN5LVmeIV2oyGLha+KeqAx4zpa0E 4vNGetEXmy0v1RaEgoiRKqVXhb5m1FkfJNKXhn1Q2d3iYlIhGGqtJgVC3ZimQ+4yKfh1G2AnAz4i 3kKT7vO6xWNJAH1EP/nHil2gxVuLjuipLcgh0wUBnKVIvY0oxzdVZux13w5tEr52R+Cjh0xy9JvQ tkThFStqKuvNA27CytQMU/2wxhSsmpx/9hOY0YhMs7d8EowhUUU1SghfvlTFMRCiNcBMEwwx5yPF cftnPphPOInYM5XxCZgyx0ys5lZzFpbtR4ALi546EzOgELUAAAAAAAA= ------=_NextPart_000_0030_01CE7575.BBA61410-- From agouaillard@gmail.com Sun Jun 30 18:53:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB7E21F9ED1 for ; Sun, 30 Jun 2013 18:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtFnEDgf1CsZ for ; Sun, 30 Jun 2013 18:53:00 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8B30821F9EC6 for ; Sun, 30 Jun 2013 18:53:00 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id n10so4277134oag.28 for ; Sun, 30 Jun 2013 18:52: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 :content-type; bh=p+AIdQ384hP80aehpKRAzYPEThXiEM4uA1WmhIjWsTY=; b=iQGevU5OySPWpKQxeBwByohwmo2HInFwzIxsaU2WLy87aby++U+RXzCUaSduceqMlV 4hMU7YOqtGRpWt8usBhkHwZpc7haYrPKcsxy9o1zfKB43IG4nxXnrhY4k3JlFW0y/iyD nJyxNpSbS8qg8byoGBO7tvgzJfDcfoqVGMuBNVyaT4+m3KO5PmL5ybnNuDRdo3/Avbqc W8jvjq2ryjnCN8/L3apgLZk6RQW5oYSM3niU4TFpLx3v1JbktqCw4Ie28WfkCekj5k1j PT5a2TDQyKswtqBsUQ1/nZVT/h5zRDFyF2Cu9p3VrrwTL3PRL9lQ3Xm4ivy1ShoU9z/6 W2nQ== MIME-Version: 1.0 X-Received: by 10.182.80.5 with SMTP id n5mr9597690obx.88.1372643578942; Sun, 30 Jun 2013 18:52:58 -0700 (PDT) Received: by 10.182.49.8 with HTTP; Sun, 30 Jun 2013 18:52:58 -0700 (PDT) In-Reply-To: References: <5158F0FC.3070104@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02B56F@FR711WXCHMBA02.zeu.alcatel-lucent.com> <5165CF9D.6030302@jesup.org> <782A8339-9A9D-49AE-85E6-9FAD55436807@tokbox.com> <6dylyuxdj0v9xctq6nv1tpyy.1372290845930@email.android.com> Date: Mon, 1 Jul 2013 09:52:58 +0800 Message-ID: From: Alexandre GOUAILLARD To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7b2e4146ed20fb04e0697cb9 Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Jul 2013 01:53:02 -0000 --047d7b2e4146ed20fb04e0697cb9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable dear all, I will speak for the first time on this thread, so I guess I belong to that silent majority. I will make some candid comments here, hoping this help. This is *NOT* a call for more flame wars, far from it. The reasons why it took me so long to write here are manifold. In order: 1. The repeated shocks coming from non-constructive posts (understatement of the century), which make me feel like putting on my anti-riot protection, hide behind a virtual pillar not to take a lost bullet or die under friendly fire. (sometimes make me feel like being back in junior-high, which is just a slight variation of the previous feeling). 2. the time needed to find, read and digest all the RFC / proposals and to start getting the big picture. 3. the fact that it is difficult to articulate the pain points not knowing what is supposed to be difficult, and what is difficult because of wrong design. Coming from another field, and having a hacker mentality, everything is equally new and challenging, and our team just went ahead and find solutions. Being able to separate what is challenging because it's new and what is challenging because it shouldn't be done that way is hard at best without the right background and the global picture in mind. That is slowly changing. 4. I don't have a proposal to make it better at this stage. 5. webrct world is developing fast and we need to stay in the race, allocating most of our time to development, and maybe not enough to the standard part (our mistake). That is changing too. ok, that might have helped to answer the why people are silent, but not what should be done next. Here are a few more details. 1. we don't want to see webrtc being slow down. We would vote against anything that bring us back to zero like a complete rewrite. We would favor transition plans. 2. today, we manipulate SDP for the following things: - bandwidth limitation, as a temporary work around while corresponding constraints are not honored. - codec order - ICE candidate priority 3. We are available to give comment on other people proposal (if most of bitterness and non-constructive "I told you so", "i m not going to write a draft for something that should already be there", "feel free to wait until the end for my official rebuttal, so everybody will have lost their time" messages are left at the door), and spend some time testing, but it's very likely that we will *NOT* make a proposal ourselves. 4. We like the *concept* of separating functions/features in the peer connection, and we are interested in the way datachannels are set up, *but* we haven't took the time to dig into it enough. Now webrct expo in atlanta is over, this should change, hence this e-mail. HTH. alex. On Thu, Jun 27, 2013 at 11:05 AM, Marc Abrams wrote: > It=92s pretty telling when you have Digium and others making statements l= ike > =93...that relying on SDP hasn't been a panacea for interoperability, =93= or > =93... [they would] rather write an entirely new channel driver for Aster= isk > than have to re-write [their] SDP handling, =93 you know that it=92s not = =93just=94 > an SDB Rebellion. It=92s a problem. And waving your hands and claiming it= =92s > necessary does not make SDP the solution. > > We should punt on SDP for v1.0 and move on. > > Thanks. > > marc. > __________________ > +1-949-270-0935 > > > > On Jun 26, 2013, at 5:12 PM, Peter Thatcher wrote: > > On Wed, Jun 26, 2013 at 4:57 PM, Gustavo Garcia Bernardo > wrote: > >> Getting the feeling of that silent mayority is what we are doing in this >> thread. Hope we can put something together as Robin volunteered to lead= . >> >> > Even the "SDP rebellion" aside (by the way, you guys need some Star Wars > jokes), it would very useful to have a good idea of who is working on wha= t > and how well the API is working for them, and what things could be added = or > changed to help. Most of the WG does seem to have any real experience > actually using the API, and I think that limits are ability to design the > right API. More input from people actually using the API could only help= , > and I look forward to hearing more. > > There is a working implementation of cu-web-rtc, look for it in Microsoft >> html labs page. Obviously my prototype is quick and dirty but you get m= y >> point on what you can do. >> >> > I apologize if I missed the link to your prototype. I'd like to see it. > Can you repost the link? > > >> >> Sent from mobile >> >> Peter Thatcher wrote: >> >> On Wed, Jun 26, 2013 at 4:29 PM, Gustavo Garc=EDa wrote= : >> >>> "We reject kings, presidents and voting. We believe in rough consensus >>> and running code". (IETF TAO) >>> >>> - Lot of developers building stuff beyond a PSTN interconnection demo >>> are having problems with the existing model. Complexity, limitations = and >>> incompatibilities make us feel like fighting an API instead of using it= . >>> - There are a lot of issues (bugs, incompatibilities, feature requests) >>> because of SDP and O/A. Take a look at webrtc issue tracker. >>> - The actual experience of people using the API should be a stronger >>> argument than a voting done one year ago. Specially when most of >>> developers are not participating in IETF voting and after realizing the >>> implications of SDP and O/A model f.e. on all those endless Plan-XXX >>> discussions. >>> >> >> If there's a great "silent majority" out there, I think it would help th= e >> WG a lot for them to come on the forum and give clear, concrete examples >> (not ranty, please) of what they're trying to do and what their pain poi= nts >> are. I think that's much more helpful than just remaining silently in >> pain. On the flip side, if app developers love using the current API an= d >> think SDP O/A is great, they should express that as well. >> >> >>> - There is a much more simple solution (something like CU-RTC-Web) and >>> you can always write a SDP/O/A/PeerConnection API on top of it (I had a >>> prototype working in a couple of hours), but the other way around is mu= ch >>> more hard if not impossible. >>> >> >> You know you're in trouble when CU-RTC-Web is considered "much more >> simple" :). >> >> I think your "bulid RtcPeerConnection on top in JS" is a great idea, but >> you had a prototype in a couple of hours? I have a hard time you could >> implement much of SDP O/A correctly in a couple of ours. And how could = you >> test such a thing, without a working implementation of CU-RTC-Web? >> >> >>> In my opinion the only reasonable approaches are: >>> - Change the API now >>> - Change the API in one year >>> >>> >> You could add: >> >> - Change the API every couple weeks by changing what SDP is >> generated/supported. >> >> >> :) >> >> +1 to I=F1aki's request too >>> >>> G. >>> >>> On 18/06/2013, at 15:19, Matthew Jordan wrote: >>> >>> > >>> > On Tue, Jun 18, 2013 at 1:22 PM, Adrian Georgescu >>> wrote: >>> > +1 >>> > >>> > While working with the specs, some may have realised that SDP is not >>> such a great idea to put in practice and may also want to come forward = to >>> admit their mistake. >>> > >>> > Regards, >>> > Adrian >>> > >>> > >>> > In the Asterisk project, we were able to use our legacy SIP stack to >>> enable very basic WebRTC communication with Chrome and FireFox. That so= unds >>> nice, until you realize we have to continually preface that with >>> "sometimes". >>> > >>> > Because the answer is, more often than not, something breaks. >>> Invariably, the breakages have been in the SDPs sent to Asterisk by the >>> browser. What SDP breaks us changes depending on the browser being used= , >>> the version of said browser, and whether or not some new WebRTC SDP fea= ture >>> has been put in the browser's latest release. And just when we think we >>> have to modify Asterisk to handle the new SDP sent by some browser, the >>> browser changes again. As a result, Asterisk 11 hasn't changed a lot si= nce >>> we released; we've been trying to avoid coding to a moving target. We >>> always envisioned that things would quiet down and the browsers would >>> settle on an implementation of SDP that we could adapt to - but it does= n't >>> seem like things are quieting down as much as we'd like. And sure, the = SIP >>> stack in Asterisk is crufty, and sure, sometimes the fault is in our >>> implementation, not the browser's - but I think we on the Asterisk proj= ect >>> can certainly say that relying on SDP hasn't been a panacea for >>> interoperability. >>> > >>> > It feels like maintaining compatibility with "traditional" SDP >>> implementations is getting harder for the browsers to manage and holdin= g >>> the entire process back. As one of those older "traditional" >>> implementations, I'd rather write an entirely new channel driver for >>> Asterisk than have to re-write our SDP handling. >>> > >>> > So... +1 to Inaki's request. >>> > >>> > Matt >>> > >>> > -- >>> > Matthew Jordan >>> > Digium, Inc. | Engineering Manager >>> > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >>> > Check us out at: http://digium.com & http://asterisk.org >>> > _______________________________________________ >>> > rtcweb mailing list >>> > rtcweb@ietf.org >>> > https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> >> ------------------------------ >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar >> nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en e= l enlace >> situado m=E1s abajo. >> This message is intended exclusively for its addressee. We only send and >> receive email on the basis of the terms set out at: >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >> > > _______________________________________________ > 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 > > --047d7b2e4146ed20fb04e0697cb9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    dear all,

    I will speak for the fi= rst time on this thread, so I guess I belong to that silent majority. I wil= l make some candid comments here, hoping this help. This is *NOT* a call fo= r more flame wars, far from it.

    The reasons why it took me so long to write= here are manifold. In order:
    1. The repeated shocks coming= from non-constructive posts (understatement of the century), which make me= feel like putting on my anti-riot protection, hide behind a virtual pillar= not to take a lost bullet or die under friendly fire. (sometimes make me f= eel like being back in junior-high, which is just a slight variation of the= previous feeling).
    2. the time needed to find, read and digest all the RFC / = proposals and to start getting the big picture.
    3. the fact= that it is difficult to articulate the pain points not knowing what is sup= posed to be difficult, and what is difficult because of wrong design. Comin= g from another field, and having a hacker mentality, everything is equally = new and challenging, and our team just went ahead and find solutions. Being= able to separate what is challenging because it's new and what is chal= lenging because it shouldn't be done =A0that way is hard at best withou= t the right background and the global picture in mind. That is slowly chang= ing.
    4. I don't have a proposal to make it better at this stage.<= /div>
    5. webrct world is developing fast and we need to stay in t= he race, allocating most of our time to development, and maybe not enough t= o the standard part (our mistake). That is changing too.

    ok, that might have helped to answer the wh= y people are silent, but not what should be done next. Here are a few more = details.

    1. we don't want to see w= ebrtc being slow down. We would vote against anything that bring us back to= zero like a complete rewrite. We would favor transition plans.
    2. today, we manipulate SDP for the following things:
    =A0 - bandwidth limitation, as a temporary work around while correspo= nding constraints are not honored.
    =A0 - codec order
    <= div style> =A0 - ICE candidate priority
    3. We are available to give co= mment on other people proposal (if most of bitterness and non-constructive = "I told you so", "i m not going to write a draft for somethi= ng that should already be there", "feel free to wait until the en= d for my official rebuttal, so everybody will have lost their time" me= ssages are left at the door), and spend some time testing, but it's ver= y likely that we will *NOT* make a proposal ourselves.
    4. We like the *concept* of separating functions/features in the= peer connection, and we are interested in the way datachannels are set up,= *but* we haven't took the time to dig into it enough. Now webrct expo = in atlanta is over, this should change, hence this e-mail.

    HTH.

    a= lex. =A0


    On Thu, Jun 27, 2013 at 11:05 AM, Marc Abrams <= span dir=3D"ltr"><ma= rc@mocet.com> wrote:
    It=92s p= retty telling when you have Digium and others making statements like =93...= that relying on SDP hasn't been a panacea for interoperability, =93 or = =93... [they would] rather write an entirely new channel driver for Asteris= k than have to re-write [their] SDP handling, =93 you know that it=92s not = =93just=94 an SDB Rebellion. It=92s a problem. And waving your hands and cl= aiming it=92s necessary does not make SDP the solution.=A0

    We should punt on SDP for v1.0 and move on.=A0

    Thanks.

    marc.
    __________________
    +1-949-270-0935



    On Jun 26, 2013, at 5:12 PM, Peter Thatcher <pthatcher@google.com> w= rote:

    On Wed, Jun 26, 2013 at 4:57 PM, Gustavo Garcia Bernardo=A0<ggb@tid.es>=A0wrote:
    Getting the feeling of tha= t silent mayority is what we are doing in this thread. =A0Hope we can put s= omething together as Robin volunteered to lead.


    Even the "SDP rebellio= n" aside (by the way, you guys need some Star Wars jokes), it would ve= ry useful to have a good idea of who is working on what and how well the AP= I is working for them, and what things could be added or changed to help. = =A0 Most of the WG does seem to have any real experience actually using the= API, and I think that limits are ability to design the right API. =A0More = input from people actually using the API could only help, and I look forwar= d to hearing more. =A0

    There is a working implemen= tation of cu-web-rtc, look for it in Microsoft html labs page. =A0Obviously= my prototype is quick and dirty but you get my point on what you can do.


    I apologize if I missed the= link to your prototype. =A0I'd like to see it. =A0Can you repost the l= ink?
    =A0

    Sent from mobile

    Peter Thatcher <pthatcher@google.com= > wrote:

    On Wed, Jun 26, 2013 at 4:29 PM, Gustavo Garc=EDa=A0<ggb@to= kbox.com>=A0wrote:
    "We reject kings, presidents and voting. We believe i= n rough consensus and running code". (IETF TAO)

    - Lot of developers building stuff beyond a PSTN interconnection demo a= re having problems with the existing model. =A0 Complexity, limitations and= incompatibilities make us feel like fighting an API instead of using it. - There are a lot of issues (bugs, incompatibilities, feature requests) bec= ause of SDP and O/A. =A0Take a look at webrtc issue tracker.
    - The actua= l experience of people using the API should be a stronger argument than a v= oting done one year ago. =A0Specially when most of developers are not parti= cipating in IETF voting and after realizing the implications of SDP and O/A= model f.e. on all those endless Plan-XXX =A0discussions.

    If there's a great "silent majori= ty" out there, I think it would help the WG a lot for them to come on = the forum and give clear, concrete examples (not ranty, please) of what the= y're trying to do and what their pain points are. =A0 I think that'= s much more helpful than just remaining silently in pain. =A0On the flip si= de, if app developers love using the current API and think SDP O/A is great= , they should express that as well.
    =A0 =A0
    - There is a much more simple solution (= something like CU-RTC-Web) and you can always write a SDP/O/A/PeerConnectio= n API on top of it (I had a prototype working in a couple of hours), but th= e other way around is much more hard if not impossible.

    You know you're in trouble when CU-RTC= -Web is considered "much more simple" :).

    I think your "bulid RtcPeerConnection on top in JS" is a great = idea, but you had a prototype in a couple of hours? =A0I have a hard time y= ou could implement much of SDP O/A correctly in a couple of ours. =A0And ho= w could you test such a thing, without a working implementation of CU-RTC-W= eb?
    =A0
    In my opinion the only reasonable approaches= are:
    - Change the API now
    - Change the API in one year


    You could add:

    - Change the API = every couple weeks by changing what SDP is generated/supported.
    =A0

    :)

    +1 to = I=F1aki's request too

    G.

    On 18/06/201= 3, at 15:19, Matthew Jordan wrote:

    >
    > On Tue, Jun 18, 2013= at 1:22 PM, Adrian Georgescu <ag@ag-projects.com> wrote:
    > +1
    >
    > While working with the specs, some may have realise= d that SDP is not such a great idea to put in practice and may also want to= come forward to admit their mistake.
    >
    > Regards,
    > Adri= an
    >
    >
    > In the Asterisk project, we were able to use our legac= y SIP stack to enable very basic WebRTC communication with Chrome and FireF= ox. That sounds nice, until you realize we have to continually preface that= with "sometimes".
    >
    > Because the answer is, more often than not, something breaks. = Invariably, the breakages have been in the SDPs sent to Asterisk by the bro= wser. What SDP breaks us changes depending on the browser being used, the v= ersion of said browser, and whether or not some new WebRTC SDP feature has = been put in the browser's latest release. And just when we think we hav= e to modify Asterisk to handle the new SDP sent by some browser, the browse= r changes again. As a result, Asterisk 11 hasn't changed a lot since we= released; we've been trying to avoid coding to a moving target. We alw= ays envisioned that things would quiet down and the browsers would settle o= n an implementation of SDP that we could adapt to - but it doesn't seem= like things are quieting down as much as we'd like. And sure, the SIP = stack in Asterisk is crufty, and sure, sometimes the fault is in our implem= entation, not the browser's - but I think we on the Asterisk project ca= n certainly say that relying on SDP hasn't been a panacea for interoper= ability.
    >
    > It feels like maintaining compatibility with "traditional= " SDP implementations is getting harder for the browsers to manage and= holding the entire process back. As one of those older "traditional&q= uot; implementations, I'd rather write an entirely new channel driver f= or Asterisk than have to re-write our SDP handling.
    >
    > So... +1 to Inaki's request.
    >
    > Matt
    ><= br>> --
    > Matthew Jordan
    > Digium, Inc. | Engineering Manage= r
    > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
    > Check= us out at:=A0http://digium.com=A0&=A0http://asterisk.org
    > _______________________________________________
    > rtc= web mailing list
    >=A0rtcweb@ietf.org
    >=A0https://www.ie= tf.org/mailman/listinfo/rtcweb

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



    Este mensaje se dirige exclusiva= mente a su destinatario. Puede consultar nuestra pol=EDtica de env=EDo y re= cepci=F3n de correo electr=F3nico en el enlace situado m=E1s abajo.
    This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
    http://www.tid.es/ES/P= AGINAS/disclaimer.aspx

    _________________________________= ______________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/list= info/rtcweb


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


    --047d7b2e4146ed20fb04e0697cb9-- From agouaillard@gmail.com Sun Jun 30 19:52:01 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B110621F9EB1 for ; Sun, 30 Jun 2013 19:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycA0tISsj6fc for ; Sun, 30 Jun 2013 19:52:01 -0700 (PDT) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DFDB421F936E for ; Sun, 30 Jun 2013 19:52:00 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id l10so4295336oag.31 for ; Sun, 30 Jun 2013 19:52:00 -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=7rZ022rqR32BrApDjX2I8DaWfPc7m8rpwQiHAboI2Gk=; b=Y4e8YUHbP3WhPhvgvgoluL3DGbtghMETlCfkt7lr+BxH8fIRXaVVeBEoh+T+Gvblnh iYatpVgP3ZW942c2ZaY04ygcuVA0ILdf/lKnDa7b1eWuOXHdSi4xcKHPR/nopQ2HOQje voX4aTXRRL1WfqQJgQKtPd/Ggx+8nkWvHp0dUGCJ9e9eAuYjhQV3OUJcGJYvgxJYVnoH mjTu8m5L7E5WoV7ghtq710jD/lIcfJBXorZ5wntTeeGymvAh7a3iNtVaDh1wmw/guwUo 35PTlutz8zcCYVIKk9hTUJ9YgzNP3nuUTwif++S9vah7z9UD4rli3VxcGVXr0XfDhc8m ZWbw== MIME-Version: 1.0 X-Received: by 10.60.98.41 with SMTP id ef9mr8769121oeb.68.1372647119486; Sun, 30 Jun 2013 19:51:59 -0700 (PDT) Received: by 10.182.49.8 with HTTP; Sun, 30 Jun 2013 19:51:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Jul 2013 10:51:59 +0800 Message-ID: From: Alexandre GOUAILLARD To: Peter Thatcher Content-Type: multipart/alternative; boundary=089e013a100af5882a04e06a4fba Cc: "" Subject: Re: [rtcweb] Request for input from WebRTC JS (web app) developers (please respond if you are *using* the 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: Mon, 01 Jul 2013 02:52:01 -0000 --089e013a100af5882a04e06a4fba Content-Type: text/plain; charset=ISO-8859-1 thanks for the effort. I think it goes in the right direction. I filled my part. regards, alex. On Thu, Jun 27, 2013 at 2:36 PM, Peter Thatcher wrote: > I don't know if this has been done already, but I think that the WG could > really use come good feedback from the JS developers out there actually > using the WebRTC API. What are you making? What's working well? What's > not working well? Do you like SDP? (Try to be constructive with that last > one). > > So, I made a little spreadsheet where you can leave feedback: > > > https://docs.google.com/spreadsheet/ccc?key=0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=0 > > If you are a JS developer using the WebRTC API, would you please fill in > some feedback? If you can't give details about what you're working on, I > can understand that. But please give us a sense of what is working well > and what isn't. I think it would help the WG a lot. But please do > remember that the WG is focusing on getting 1.0 out the door and probably > wants to hear something more constructive than "I hate it; start over", so > try to be constructive, especially when talking about SDP. > > Speaking of SDP, I read through 190+ recent emails about SDP (yeah... hot > topic!) and collected quotes from some of you and put them in the > spreadsheet. If you don't like that, I apologize; please let me know, or > just remove yourself from the doc. I wanted to do the same for the other > questions, but found it too hard. So I hope you'll help me :). > > (I didn't include anyone from Google, Mozilla, or Microsoft; I wanted > this to be feedback for developers, not implementors, even if the > implementors are also developers; And I didn't include myself :) > > Thank you so much for your feedback! > > > > > PS: if anyone is interested, my quick tally of opinions of SDP indicate: > > Like: 3 > Strongly Dislike: 6 > Would like something else, or at least discussion of something else: 5 > > I may have gotten some wrong, so please give feedback to help it be more > accurate. > > Thanks again! > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e013a100af5882a04e06a4fba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    thanks for the effort.
    I think it goes in the right di= rection.
    I filled my part.

    regards,

    alex.


    On Thu, Jun 27, 2013 at 2:36 PM, Peter Thatcher <pthatcher@google.com> wrote:
    I don't know if this has been done already, but I thin= k that the WG could really use come good feedback from the JS developers ou= t there actually using the WebRTC API. =A0What are you making? =A0What'= s working well? What's not working well? =A0Do you like SDP? =A0(Try to= be constructive with that last one).

    So, I made a little spreadsheet where you can leave feedback= :


    If you are a JS developer using the WebRTC API, w= ould you please fill in some feedback? =A0If you can't give details abo= ut what you're working on, I can understand that. =A0But please give us= a sense of what is working well and what isn't. =A0I think it would he= lp the WG a lot. =A0But please do remember =A0that the WG is focusing on ge= tting 1.0 out the door and probably wants to hear something more constructi= ve than "I hate it; start over", so try to be constructive, espec= ially when talking about SDP.

    Speaking of SDP, I read through 190+ recent emails abou= t SDP (yeah... hot topic!) and collected quotes from some of you and put th= em in the spreadsheet. =A0If you don't like that, I apologize; please l= et me know, or just remove yourself from the doc. =A0I wanted to do the sam= e for the other questions, but found it too hard. =A0So I hope you'll h= elp me :).

    (I didn't include anyone from Google, Mozilla, or M= icrosoft; =A0I wanted this to be feedback for developers, not implementors,= even if the implementors are also developers; =A0And I didn't include = myself :)

    Thank you so much for your feedback!=A0




    PS: if anyone = is interested, my quick tally of opinions of SDP indicate:

    Like: 3
    Strongly Dislike: 6
    Would like s= omething else, or at least discussion of something else: 5

    I may have gotten some wrong, so please give feedback to help it b= e more accurate.

    Thanks again!



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


    --089e013a100af5882a04e06a4fba-- From stefan.lk.hakansson@ericsson.com Sun Jun 30 23:46:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2880C21F9F35 for ; Sun, 30 Jun 2013 23:46:01 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTa2z9UN9zCt for ; Sun, 30 Jun 2013 23:45:55 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C61C021F9F2F for ; Sun, 30 Jun 2013 23:45:54 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-03-51d125a18155 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 45.AE.19388.1A521D15; Mon, 1 Jul 2013 08:45:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Mon, 1 Jul 2013 08:45:53 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Robin Raymond Thread-Topic: [rtcweb] New Draft - WebRTC JS Object API Model Thread-Index: AQHOcibV+w71mSCXSkiQxLiPakqfXQ== Date: Mon, 1 Jul 2013 06:45:53 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> References: <51CA6FEE.6030702@hookflash.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvre5C1YuBBl9XWFn87u5gt1j7r53d gcnj/NYlTB5LlvxkCmCK4rJJSc3JLEst0rdL4MqYuv8VU8E2xYrze6YzNzB+lepi5OSQEDCR +Lj2GjOELSZx4d56ti5GLg4hgcOMEovmLWGBcBYySmxdtIMdpIpNIFBi674FbCC2iIC6xIlj zWDdzED2ncXnwGqEBWwk+j58Zupi5ACqsZXY1sYKUa4nMefzSrASFgEVieaVJxlBbF4BX4np M4+AjRQS0JHYfvIXE4jNCHTQ91NrmCDGi0vcejKfCeJQAYkle85DHS0q8fLxP1YIW0nix4ZL LBD1ehI3pk5hg7C1JZYtfM0MsUtQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcXInpuYmZNe br6JERgLB7f8NtjBuOm+2CFGaQ4WJXHezXpnAoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw BuauO9vvk3Z5zVr7+ddnn//jHrRpFcvCLQJG0tcqGmWkHSQOOX30mV65IEmtfdtNvV8MhS5d p71ENvIImG0Vit3FM1XAQXx7tpq6ZIvfkc1XTOx2c0mKb3B3vLXGUfIL+2aJn7fZnb9npi3f n1V64lDRDaPXH/4WxGofv2q2Ybd5KHdi84NeJZbijERDLeai4kQApQ8ogVMCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Jul 2013 06:46:02 -0000 I had a quick look at the use-cases in section 4, and have some comments:= =0A= =0A= 4.1: What is "hold" really? Seems like a very SIP specific thing and =0A= nothing someone building a service that not interop with legacy would =0A= ever care about. Could the intended functionality be expressed in terms =0A= like "pause/resume" on MediaStreamTrack level? And, getUserMedia would =0A= never produce an SDP.=0A= =0A= 4.2: The model to specify video properties of a video track is to use =0A= constraints. And it is the generator/sender of the video that has =0A= control. So for the scenario described, the app at browser A would have =0A= to tell - in some not standardized way - the app at browser B that it =0A= wants to have the video in another format, and the app at browser B =0A= would have to modify some constraint. Not SDP involved (unless the new =0A= constraint applied would trigger a new SDP o/a initiated by browser B).=0A= =0A= 4.3: Nice use-case. What should happen if client D wants to enter later? = =0A= Do you imply that all peer-2-peeer connections use the same keys and =0A= fingerprints?=0A= =0A= 4.4: I have always been told that in scenarios like this the new feature = =0A= (that is described by the SDP extension) will not be used since the =0A= other end point does not support it. To me this is one of the nice =0A= things with O/A. Say that a new, better codec is being introduced. It =0A= won't be in all browsers over night - but I think it is nice if it gets =0A= used when possible without any changes to the app.=0A= =0A= 4.5: This really underlines the need to specify in detail what the =0A= allowed SDP variations are (or, if we remove SDP, to specify any other =0A= mechanism to exchange the things needed to set up RTP and other things =0A= going on the wire).=0A= =0A= 4.6: I'm not sure any SDP exchange would be needed at all. The bitrate =0A= can be varied between the boundaries already set up, and there is also =0A= functionality like DTX.=0A= =0A= =0A= In section 5, I think 5.3.5 "Well Defined Behaviors" is a key =0A= observation. SDP or not, it must be very well specced up what different =0A= API call really mean, and what is allowed and not.=0A= =0A= Note, I am not really trying to defend SDP. I think it should definitely = =0A= not be part of the API - there should be specific API methods available =0A= instead IMO. I have been assuming it could be a tool for telling the =0A= other browser how it should use the incoming RTP, but we've all seen the = =0A= problems with agreeing on the format (with all Plan's).=0A= =0A= But I think we should split things up. One thing is what API methods we =0A= have need for. Another what signaling is needed between end-points, and =0A= how it is done. And this part could be split up in categories like =0A= things needed to be signaled to establish connection, to set up =0A= transmission of media and data over the connection, to change the =0A= characteristics of how media is transmitted.=0A= =0A= Stefan=0A= =0A= =0A= On 2013-06-26 06:37, Robin Raymond wrote:=0A= >=0A= > *=0A= >=0A= > According to many, real adoption of WebRTC will not happen if we=0A= > continue to force everyone to use this SDP Offer/Answer methodology. It= =0A= > is clearly blocking our way forward and the amount of specification=0A= > documentation remaining needed for the browser vendors to produce a=0A= > compatible SDP based WebRTC engine in a browser is much more daunting=0A= > than most are willing to admit.=0A= >=0A= >=0A= > The draft rationale behind a JavaScript Object API model:=0A= >=0A= > http://www.ietf.org/internet-drafts/draft-raymond-rtcweb-webrtc-js-obj-ap= i-rationale-00.txt=0A= >=0A= > Whereas:=0A= >=0A= > The WebRTC JavaScript Object API & Shim document will be along shortly.= =0A= >=0A= >=0A= > We wanted to get this initial rationale draft informational document out= =0A= > right away. Everyone that has any interest should review the reasons and= =0A= > concepts and comment before we get too far along on the details of an=0A= > actual API, the initial API will follow in the coming days.=0A= >=0A= >=0A= > Best regards,=0A= >=0A= > Robin Raymond*=0A= >=0A= =0A=

    What is the aim of NoPlan? The draft says "This document does not
    question the use of SDP and the Offer/Answer model". Why? It should question it since it treats SDP as if it was a silly and unmanageable
    binary blob. It is like "we must live with SDP because it is
    mandatory, but let's try to ignore it as much as possible". If so,= why
    don't ignore SDP entirely?

    However NoPlan is the best we have if, finally, SDP is mandated in WebRTC.<= br>
    I think it is time to write two lists:

    1) Advantages of using SDP in WebRTC.

    Someb= ody wrote a bunch of code based on JSEP. =A0
    =A0
    2) Dissadvantages of using SPD in WebRTC.

    A= n unmanageable monster was created which currently stays in the way of deve= loping new functionality (bundle), building applications (does not provide = obvious ways to implement obvious tasks, like adding an extra stream withou= t re-negotiating all the existing ones) and even interop with existing SIP = endpoints (which was the original but now is complicated since it would req= uire a non trivial set of constraints and subsequent SDP manipulation).=A0<= /div>
    _____________
    Roman Shpount
    =A0
    --f46d04426c0a5af7de04df60c5d3-- From robin@hookflash.com Mon Jun 17 17:13:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48EF21F9E79 for ; Mon, 17 Jun 2013 17:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxiVLCay6Bam for ; Mon, 17 Jun 2013 17:13:50 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 65C3821F9E6B for ; Mon, 17 Jun 2013 17:13:48 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 16so8628002iea.3 for ; Mon, 17 Jun 2013 17:13:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=Kcdi4mw/hOaOfjvgWH1HglgWcHmHA6EvuRvMbPpAmFU=; b=SybNmUWRKxvM714UBZhSdnxrOk/QphX2MayPSQI6kEcMo9bA7Hf5cBAieAvOLInpl/ 6fxFSX8ixO/ntclV6JdSEpORh8SleM78RqNhi9JxIpUptSXGzpFKjdTUQrFxhPlTIFxd +fWN3UHACIqpB/NH1vVR2YzxBNxWaU4mVcN6t1KkiQghlgLNezU85CZQi2fAnjGpAS3d 5GhjMzINXsQSzXVVXumLXKxl+Au40BktHQMNvzwLLx52cv4cn8vGxvxNAqCOeomJ9FNt PaK2ZZie2ZScf/FyzIFnwYYyGjRX57PKvutZp4cq99Kq4NMFhRuw4yPrFCoRz8L6UTtV Y5vQ== X-Received: by 10.50.50.172 with SMTP id d12mr6388346igo.106.1371514428523; Mon, 17 Jun 2013 17:13:48 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id z6sm19502047igw.8.2013.06.17.17.13.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Jun 2013 17:13:47 -0700 (PDT) Message-ID: <51BFA638.4020303@hookflash.com> Date: Mon, 17 Jun 2013 20:13:44 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Martin Thomson References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090500050407060900010504" X-Gm-Message-State: ALoCoQkz3VbyrFgc1T8UC0Dd0Bjbecb3d3dk3h+CoxfZ6H9Qef7MqBPfRVpE4UTecwCJrc2avOi2 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 00:13:59 -0000 This is a multi-part message in MIME format. --------------090500050407060900010504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Seems that this SDP issue keeps coming back with a bit of "I told you so" attached. It's truly awful and I've expressed my personal disdain previously. I've only kept quiet because I have no desire to stop WebRTC despite how personally horrible I find SDP. However bad it is I do want WebRTC released and hopefully this existing SDP based API can be deprecated -- fast. I want to see Microsoft onboard with WebRTC but I fully understand their position. I find it equally horrible for our Open Peer P2P signalling although we can "work around" it temporarily but it does hinder our ability to innovate. And when I refer to SDP I really mean SDP + offer/answer. As I knew going in this effort is being primarily spearheaded by the SIP world and the push for SDP comes from that realm. At first I thought the SIP vendors would love it but I've refined my thinking and I think it's equally bad for SIP guys too if they were to think about the consequences. They are demanding features like crazy in the browser but have made the browser the bottle neck for innovation rather than allowing all their features to be implemented within JavaScript with media engine hooks inside the browser. The SDP produced by browsers won't likely be compatible with them anyway and they are likely to require SBCs to "fix" it. This is just bad, especially knowing how SIP guys love tweaking SIP for their own favourite flavours. As much as I hate to say it, I think we need to hold off on releasing WebRTC as it is until we have a lower level API. SDP offer/answer is not going to cut it for the initial release, this first version of the standard needs to live on for at least a few years. We must deprecate the current WebRTC API in favour of a more suitable low-level replacement API. The revision should focus instead on the extensions that can be added in the JavaScript layer and only put the necessary hooks in the browser at the most basic level for a media and RTC engine to be controlled. Let's not hamper innovation! If we need compatibility with the current WebRTC API it would be easy to create a JavaScript shim that supports the current API and allows a more long innovative approach. If there is interest in creating such a shim, I would be more than happy to be part of that development effort. I've written more on the subject here but I don't want to post a long rant here: http://blog.webrtc.is/2013/06/17/sdp-inside-webrtc-is-bad-for-sip/ -Robin > Martin Thomson > 17 June, 2013 5:56 PM > On 17 June 2013 12:26, Peter Thatcher wrote: >> Yes, I was expecting you to be more supportive. I'm surprised out how your >> want "all or nothing". I'm afraid if our options for a clean API are all or >> nothing, we'll just end up with nothing. I'd prefer to try incremental >> improvements to word toward (eventually) a clean API. > > Yes, I apologize if the language seemed strong, but I stand by those words. > > The problem that I see with this, and it is a problem with any > incremental approach, is that it produces two very different > interaction models for things that are approximately the same > fundamental operation. > > That is, when I add the first video track to a session I perform one > set of actions. Then, when I add subsequent tracks, it's different. > > This also has all the purported drawbacks of comment 22 with respect > to usability, whatever they are. There must have been some because I > got a lot of heat about that when we discussed it. > >> Do you think it is impossible to work toward a clean API in an incremental >> approach? If you think it's possible, I'd like to hear your thoughts on >> how. > > The fundamental problem in WebRTC is the Offer/Answer semantics in the > API. That's hard to remove now. I can't see an incremental change > that would remove that, and that's every bit as much of a problem as > having to deal with SDP. That's how we got to comment 22. > > I know that you wanted to do some sort of object representation of > SDP. That can be done incrementally by adding to > RTCSessionDescription, or by replacing it entirely, but it doesn't > really go to the core of the problem. If you were willing to tolerate > the fact that there would be two code paths, two control surfaces that > effectively did the same things. > >> By the way, these API additions would greatly minimize the amount of SDP >> editing necessary for JS clients that don't use SDP for signalling. And >> later incremental improvements could reduce it further. Also, it's no >> longer necessary to do offer/answer for adding tracks. It's only the intial >> PeerConnection setup that needs to do Offer/Answer. So, it doesn't inherit >> all the problems quite as much as you described. It may be slightly >> abominable, but I certainly consider it less abominable than the SDP editing >> necessary without it. > > If I am forced to do SDP, I'd rather not have something else as well > unless that something else is getting me something concrete. What you > are proposing does too little to advance a cleaner API model to > justify the extra overhead that it introduces. It doesn't tackle the > hard problems. > > I appreciate the philosophy behind no-plan, which is not a non-plan in > any sense. It addresses a concern that we (unfortunately) didn't > really touch on in the MMUSIC call this morning. However, the > requirements of the-not-no-plan could be far more elegantly addressed > within the constraints of the current API without adding all those > extra description bits. > > --Martin > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Peter Thatcher > 17 June, 2013 3:26 PM > Yes, I was expecting you to be more supportive. I'm surprised out how > your want "all or nothing". I'm afraid if our options for a clean API > are all or nothing, we'll just end up with nothing. I'd prefer to try > incremental improvements to word toward (eventually) a clean API. > > Do you think it is impossible to work toward a clean API in an > incremental approach? If you think it's possible, I'd like to hear > your thoughts on how. > > > By the way, these API additions would greatly minimize the amount of > SDP editing necessary for JS clients that don't use SDP for > signalling. And later incremental improvements could reduce it > further. Also, it's no longer necessary to do offer/answer for adding > tracks. It's only the intial PeerConnection setup that needs to do > Offer/Answer. So, it doesn't inherit all the problems quite as much > as you described. It may be slightly abominable, but I certainly > consider it less abominable than the SDP editing necessary without it. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Martin Thomson > 17 June, 2013 2:57 PM > Maybe you'd expect me to be more supportive of something that looked > so much like CU-RTC-Web. It inherits all the worst properties of JSEP > (Offer/Answer, SDP editing) with a partial implementation of a clean > API. > > It's comment 22-lite. It's an abomination. If you are going to do > this, do it properly. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Peter Thatcher > 17 June, 2013 8:57 AM > Google is in full support of "Plan B" for encoding multiple media > sources in SDP, and would like to see the Plan A vs. Plan B decision > resolved soon. Recently, though, a third option, called "NoPlan" has > been proposed, but it lacked the details of what a JS API would look > like for NoPlan. Cullen asked to see such an API proposal, and so I > have worked with Emil to make one. He will be adding it to the NoPlan > draft, but I will also include it in this email. > > Again, Google is in full support of "Plan B". But if Plan A vs. Plan > B cannot be decided, then we support NoPlan with the following > additions to the WebRTC JS API as an option that allows implementing > either Plan A or Plan B in Javascript. And even if Plan A vs. Plan B > is resolved, these API additions would still be a big improvement for > those WebRTC applications that don't use SDP for signalling. > > It is a bit long because I have added many comments and examples, but > the actually additions only include two new methods on PeerConnection > and a few new dictionaries. So don't be overwhelmed :). > > > > Intro: This follows the model of createDataChannel, which has a JS > method on PeerConnection that makes it possible to add data channels > without going through SDP. Furthermore, just like createDataChannel > allows 2 ways to handle neogitation (the "I know what I'm doing; > Here's what I want to send; Let me signal everything" mode and the > "please take care of it for me; send an OPEN message" mode), this > also has 2 ways to handle negotiation (the "I know what I'm doing; > Here's what I want to send; Let me signal everything" mode and the > "please take care of it for me; send SDP back and forth" mode). > > Following the success of createDataChannel, this allows simple > applications to Just Work and more advanced applications to easily > control what they need to. In particular, it's possible to use this > API to implement either Plan A or Plan B. > > // The following two method are added to RTCPeerConnection > partial interface RTCPeerConnection { > // Create a stream that is used to send a source stream. > // The MediaSendStream.description can be used for signalling. > // No media is sent until addStream(MediaSendStream) is called. > LocalMediaStream createLocalStream(MediaStream sourceStream); > > // Create a stream that is used to receive media from the remote side, > // given the parameters signalled from MedaiSendStream.description. > MediaStream createRemoteStream(MediaStreamDescription description); > } > > > interface LocalMediaStream implements MediaStream { > // This can be changed at any time, but especially before calling > // PeerConnection.addStream > attribute MediaStreamDescription description; > } > > > // Represents the parameters used to either send or receive a stream > // over a PeerConnection. > dictionary MediaStreamDescription { > MediaStreamTrackDescription[] tracks; > } > > > // Represents the parameters used to either send or receive a track > over // a PeerConnection. A track has many "flows", which can be grouped > // together. > dictionary MediaStreamTrackDescription { > // Same as the MediaStreamTrack.id > DOMString id; > > // Same as the MediaStreamTrack.kind > DOMString kind; > > // A track can have many "flows", such as for Simulcast, FEC, etc. > // And they can be grouped in arbitrary ways. > MediaFlowDescription[] flows; > MediaFlowGroup[] flowGroups; > } > > // Represents the parameters used to either send or receive a "flow" > // over a PeerConnection. A "flow" is a media that arrives with a > // single, unique SSRC. One to many flows together make up the media > // for a track. For example, there may be Simulcast, FEC, and RTX > // flows. > dictionay MediaFlowDescription { > // The "flow id" must be unique to the track, but need not be unique > // outside of the track (two tracks could both have a flow with the > // same flow ID). > DOMString id; > > // Each flow can go over its own transport. If the JS sets this to a > // transportId that doesn't have a transport setup already, the > // browser will use SDP negotiation to setup a transport to back that > // transportId. If This is set to an MID in the SDP, then that MID's > // transport is used. > DOMString transportId; > > // The SSRC used to send the flow. > unsigned int ssrc; > > // When used as receive parameters, this indicates the possible list > // of codecs that might come in for this flow. For exmample, a given > // receive flow could be setup to receive any of OPUS, ISAC, or PCMU. > // When used as send parameters, this indicates that the first codec > // should be used, but the browser can use send other codecs if it > // needs to because of either bandwidth or CPU constraints. > MediaCodecDescription[] codecs; > } > > > dictionary MediaFlowGroup { > DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc > DOMString[] flowids; > } > > dictionary MediaCodecDescription { > unsigned byte payloadType; > DOMString name; > unsigned int? clockRate; > unsigned int? bitRate; > // A grab bag of other fmtp that will need to be further defined. > MediaCodecParam[] params; > } > > dictionary MediaCodecParam { > DOMString key; > DOMString value; > } > > > Notes: > > - When LocalMediaStreams are added using addStream, onnegotiatedneeded > is not called, and those streams are never reflected in future SDP > exchanges. Indeed, it would be impossible to put them in the SDP > without first resolving if that would be Plan A SDP or Plan B SDP. > > - Just like piles of attributes would need to be defined for Plan A > and for Plan B, similar attributes would need to be defined here > (Luckily, much work has already been done figuring out what those > parameters are :). > > > Pros: > > - Either Plan A or Plan B or could be implemented in Javascript using > this API > - It exposes all the same functionality to the Javascript as SDP, but > in a much nicer format that is much easier to work with. > - Any other signalling mechanism, such as Jingle or CLUE could be > implemented using this API. > - There is almost no risk of signalling glare. > - Debugging errors with misconfigured descriptions should be much > easier with this than with large SDP blobs. > > > Cons: > > - Now there are two slightly different ways to add streams: by > creating a LocalMediaStream first, and not. This is, however, > analogous to setting "negotiated: true" in createDataChannel. On way > is "Just Work", and the other is more advanced control. > > - All the options in MediaCodecDescription are a bit complicated. > Really, this is only necessary because Plan A requires being able to > specify codec parameters per SSRC, and set each flow on different > transports. If we did not have this requirement, we could simplify. > > > Example Usage: > > // Imagine I have MyApp, handles creating a PeerConnection, > // signalling, and rendering streams. This is how the new API could be > // used. > var peerConnection = MyApp.createPeerConnection(); > > // On sender side: > var stream = MyApp.getMediaStream(); > var localStream = peerConnection.createSendStream(stream); > sendStream.description = MyApp.modifyStream(localStream.description) > MyApp.signalAddStream(localStream.description, function(response)) { > if (!response.rejected) { > // Media will not be sent. > peerConnection.addStream(localStream); > } > } > > // On receiver side: > MyApp.onAddStreamSignalled = function(streamDescription) { > var stream = peerConnection.createReceiveStream(streamDescription); > MyApp.renderStream(stream); > } > > > // In this exchange, the MediaStreamDescription signalled from the > // sender to the receiver may have looked something like this: > > { > tracks: [ > { > id: "audio1", > kind: "audio", > flows: [ > { > id: "main", > transportId: "transport1", > ssrc: 1111, > codecs: [ > { > payloadType: 111, > name: "opus", > // ... more codec details > }, > { > payloadType: 112, > name: "pcmu", > // ... more codec details > }] > }] > }, > { > id: "video1", > kind: "video", > flows: [ > { > id: "sim0", > transportId: "transport2", > ssrc: 2222, > codecs: [ > { > payloadType: 122, > name: "vp8" > // ... more codec details > }] > }, > { > id: "sim1", > transportId: "transport2", > ssrc: 2223, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... more codec details > }] > }, > { > id: "sim2", > transportId: "transport2", > ssrc: 2224, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... more codec details > }] > }, > > { > id: "sim0fec", > transportId: "transport2", > ssrc: 2225, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... > }] > }], > flowGroups: [ > { > semantics: "SIM", > ssrcs: [2222, 2223, 2224] > }, > { > semantics: "FEC", > ssrcs: [2222, 2225] > }] > }] > } > > > Constructive feedback is welcome :). > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------090500050407060900010504 Content-Type: multipart/related; boundary="------------060904050004050804040000" --------------060904050004050804040000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    Seems that this SDP issue keeps coming back with a bit of "I told you so" attached. It's truly awful and I've expressed my personal disdain previously. I've only kept quiet because I have no desire to stop WebRTC despite how personally horrible I find SDP. However bad it is I do want WebRTC released and hopefully this existing SDP based API can be deprecated -- fast. I want to see Microsoft onboard with WebRTC but I fully understand their position. I find it equally horrible for our Open Peer P2P signalling although we can "work around" it temporarily but it does hinder our ability to innovate. And when I refer to SDP I really mean SDP + offer/answer.

    As I knew going in this effort is being primarily spearheaded by the SIP world and the push for SDP comes from that realm. At first I thought the SIP vendors would love it but I've refined my thinking and I think it's equally bad for SIP guys too if they were to think about the consequences. They are demanding features like crazy in the browser but have made the browser the bottle neck for innovation rather than allowing all their features to be implemented within JavaScript with media engine hooks inside the browser. The SDP produced by browsers won't likely be compatible with them anyway and they are likely to require SBCs to "fix" it. This is just bad, especially knowing how SIP guys love tweaking SIP for their own favourite flavours.

    As much as I hate to say it, I think we need to hold off on releasing WebRTC as it is until we have a lower level API. SDP offer/answer is not going to cut it for the initial release, this first version of the standard needs to live on for at least a few years. We must deprecate the current WebRTC API in favour of a more suitable low-level replacement API. The revision should focus instead on the extensions that can be added in the JavaScript layer and only put the necessary hooks in the browser at the most basic level for a media and RTC engine to be controlled. Let’s not hamper innovation!

    If we need compatibility with the current WebRTC API it would be easy to create a JavaScript shim that supports the current API and allows a more long innovative approach. If there is interest in creating such a shim, I would be more than happy to be part of that development effort.

    I've written more on the subject here but I don't want to post a long rant here: http://blog.webrtc.is/2013/06/17/sdp-inside-webrtc-is-bad-for-sip/

    -Robin

    17 June, 2013 5:56 PM
    On 17 June 2013 12:26, Peter Thatcher <pthatcher@google.com> wrote:

    Yes, I was expecting you to be more supportive.  I'm surprised out how your
want "all or nothing".  I'm afraid if our options for a clean API are all or
nothing, we'll just end up with nothing.  I'd prefer to try incremental
improvements to word toward (eventually) a clean API.

    
Yes, I apologize if the language seemed strong, but I stand by those words.

The problem that I see with this, and it is a problem with any
incremental approach, is that it produces two very different
interaction models for things that are approximately the same
fundamental operation.

That is, when I add the first video track to a session I perform one
set of actions.  Then, when I add subsequent tracks, it's different.

This also has all the purported drawbacks of comment 22 with respect
to usability, whatever they are.  There must have been some because I
got a lot of heat about that when we discussed it.


    Do you think it is impossible to work toward a clean API in an incremental
approach?  If you think it's possible, I'd like to hear your thoughts on
how.

    
The fundamental problem in WebRTC is the Offer/Answer semantics in the
API.  That's hard to remove now.  I can't see an incremental change
that would remove that, and that's every bit as much of a problem as
having to deal with SDP.  That's how we got to comment 22.

I know that you wanted to do some sort of object representation of
SDP.  That can be done incrementally by adding to
RTCSessionDescription, or by replacing it entirely, but it doesn't
really go to the core of the problem.  If you were willing to tolerate
the fact that there would be two code paths, two control surfaces that
effectively did the same things.


    By the way, these API additions would greatly minimize the amount of SDP
editing necessary for JS clients that don't use SDP for signalling.  And
later incremental improvements could reduce it further.  Also, it's no
longer necessary to do offer/answer for adding tracks.  It's only the intial
PeerConnection setup that needs to do Offer/Answer.  So, it doesn't inherit
all the problems quite as much as you described.  It may be slightly
abominable, but I certainly consider it less abominable than the SDP editing
necessary without it.

    
If I am forced to do SDP, I'd rather not have something else as well
unless that something else is getting me something concrete.  What you
are proposing does too little to advance a cleaner API model to
justify the extra overhead that it introduces.  It doesn't tackle the
hard problems.

I appreciate the philosophy behind no-plan, which is not a non-plan in
any sense.  It addresses a concern that we (unfortunately) didn't
really touch on in the MMUSIC call this morning.  However, the
requirements of the-not-no-plan could be far more elegantly addressed
within the constraints of the current API without adding all those
extra description bits.

--Martin
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
    17 June, 2013 3:26 PM
    Yes, I was expecting you to be more supportive.  I'm surprised out how your want "all or nothing".  I'm afraid if our options for a clean API are all or nothing, we'll just end up with nothing.  I'd prefer to try incremental improvements to word toward (eventually) a clean API. 

    Do you think it is impossible to work toward a clean API in an incremental approach?  If you think it's possible, I'd like to hear your thoughts on how. 


    By the way, these API additions would greatly minimize the amount of SDP editing necessary for JS clients that don't use SDP for signalling.  And later incremental improvements could reduce it further.  Also, it's no longer necessary to do offer/answer for adding tracks.  It's only the intial PeerConnection setup that needs to do Offer/Answer.  So, it doesn't inherit all the problems quite as much as you described.  It may be slightly abominable, but I certainly consider it less abominable than the SDP editing necessary without it.



    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    17 June, 2013 2:57 PM
    Maybe you'd expect me to be more supportive of something that looked
    so much like CU-RTC-Web. It inherits all the worst properties of JSEP
    (Offer/Answer, SDP editing) with a partial implementation of a clean
    API.

    It's comment 22-lite. It's an abomination. If you are going to do
    this, do it properly.
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    17 June, 2013 8:57 AM
    Google is in full support of "Plan B" for encoding multiple media sources in SDP, and would like to see the Plan A vs. Plan B decision resolved soon.  Recently, though, a third option, called "NoPlan" has been proposed, but it lacked the details of what a JS API would look like for NoPlan.  Cullen asked to see such an API proposal, and so I have worked with Emil to make one.  He will be adding it to the NoPlan draft, but I will also include it in this email.

    Again, Google is in full support of "Plan B".  But if Plan A vs. Plan B cannot be decided, then we support NoPlan with the following additions to the WebRTC JS API as an option that allows implementing either Plan A or Plan B  in Javascript.  And even if Plan A vs. Plan B is resolved, these API additions would still be a big improvement for those WebRTC applications that don't use SDP for signalling.

    It is a bit long because I have added many comments and examples, but the actually additions only include two new methods on PeerConnection and a few new dictionaries.  So don't be overwhelmed :).



    Intro: This follows the model of createDataChannel, which has a JS method on PeerConnection that makes it possible to add data channels without going through SDP.  Furthermore, just like createDataChannel allows 2 ways to handle neogitation (the "I know what I'm doing;  Here's what I want to send; Let me signal everything" mode and the "please take care of it for me;  send an OPEN message" mode), this also has 2 ways to handle negotiation (the "I know what I'm doing; Here's what I want to send; Let me signal everything" mode and the "please take care of it for me;  send SDP back and forth" mode). 
     
    Following the success of createDataChannel, this allows simple applications to Just Work and more advanced applications to easily control what they need to.  In particular, it's possible to use this API to implement either Plan A or Plan B.

    // The following two method are added to RTCPeerConnection
    partial interface RTCPeerConnection {
     // Create a stream that is used to send a source stream.
     // The MediaSendStream.description can be used for signalling.
     // No media is sent until addStream(MediaSendStream) is called.
     LocalMediaStream createLocalStream(MediaStream sourceStream);

     // Create a stream that is used to receive media from the remote side,
     // given the parameters signalled from MedaiSendStream.description.
     MediaStream createRemoteStream(MediaStreamDescription description);
    }


    interface LocalMediaStream implements MediaStream {
      // This can be changed at any time, but especially before calling
      // PeerConnection.addStream
      attribute MediaStreamDescription description;
    }


    // Represents the parameters used to either send or receive a stream 
    // over a PeerConnection.
    dictionary MediaStreamDescription {
      MediaStreamTrackDescription[] tracks;
    }


    // Represents the parameters used to either send or receive a track over // a PeerConnection.  A track has many "flows", which can be grouped 
    // together.
    dictionary MediaStreamTrackDescription {
      // Same as the MediaStreamTrack.id
      DOMString id;

      // Same as the MediaStreamTrack.kind
      DOMString kind;  

      // A track can have many "flows", such as for Simulcast, FEC, etc.
      // And they can be grouped in arbitrary ways.
      MediaFlowDescription[] flows;
      MediaFlowGroup[] flowGroups;
    }

    // Represents the parameters used to either send or receive a "flow" 
    // over a PeerConnection.  A "flow" is a media that arrives with a 
    // single, unique SSRC.  One to many flows together make up the media 
    // for a track.  For example, there may be Simulcast, FEC, and RTX 
    // flows.
    dictionay MediaFlowDescription {
      // The "flow id" must be unique to the track, but need not be unique 
      // outside of the track (two tracks could both have a flow with the 
      // same flow ID).
      DOMString id;

      // Each flow can go over its own transport.  If the JS sets this to a
      // transportId that doesn't have a transport setup already, the 
      // browser will use SDP negotiation to setup a transport to back that 
      // transportId.  If This is set to an MID in the SDP, then that MID's 
      // transport is used.
      DOMString transportId;

      // The SSRC used to send the flow.
      unsigned int ssrc;

      // When used as receive parameters, this indicates the possible list 
      // of codecs that might come in for this flow.  For exmample, a given 
      // receive flow could be setup to receive any of OPUS, ISAC, or PCMU.
      // When used as send parameters, this indicates that the first codec 
      // should be used, but the browser can use send other codecs if it 
      // needs to because of either bandwidth or CPU constraints.
      MediaCodecDescription[] codecs;
    }


    dictionary MediaFlowGroup {
      DOMString type;  // "SIM" for Simulcast, "FEC" for FEC, etc
      DOMString[] flowids;
    }

    dictionary MediaCodecDescription {
      unsigned byte payloadType;
      DOMString name;
      unsigned int? clockRate;
      unsigned int? bitRate;
      // A grab bag of other fmtp that will need to be further defined.
      MediaCodecParam[] params;  
    }

    dictionary MediaCodecParam {
      DOMString key;
      DOMString value;
    }


    Notes:

    - When LocalMediaStreams are added using addStream, onnegotiatedneeded is not called, and those streams are never reflected in future SDP exchanges.  Indeed, it would be impossible to put them in the SDP without first resolving if that would be Plan A SDP or Plan B SDP.

    - Just like piles of attributes would need to be defined for Plan A and for Plan B, similar attributes would need to be defined here (Luckily,  much work has already been done figuring out what those parameters are :).


    Pros:

    - Either Plan A or Plan B or could be implemented in Javascript using this API
    - It exposes all the same functionality to the Javascript as SDP, but in a much nicer format that is much easier to work with.
    - Any other signalling mechanism, such as Jingle or CLUE could be implemented using this API.
    - There is almost no risk of signalling glare.
    - Debugging errors with misconfigured descriptions should be much easier with this than with large SDP blobs.


    Cons:

    - Now there are two slightly different ways to add streams: by creating a LocalMediaStream first, and not.  This is, however, analogous to setting "negotiated: true" in createDataChannel.  On way is "Just Work", and the other is more advanced control.

    - All the options in MediaCodecDescription are a bit complicated.  Really, this is only necessary because Plan A requires being able to specify codec parameters per SSRC, and set each flow on different transports.  If we did not have this requirement, we could simplify.


    Example Usage:

    // Imagine I have MyApp, handles creating a PeerConnection,
    // signalling, and rendering streams.  This is how the new API could be 
    // used.
    var peerConnection = MyApp.createPeerConnection();

    // On sender side:
    var stream = MyApp.getMediaStream();
    var localStream = peerConnection.createSendStream(stream);
    sendStream.description = MyApp.modifyStream(localStream.description)
    MyApp.signalAddStream(localStream.description, function(response)) {
      if (!response.rejected) {
        // Media will not be sent.
        peerConnection.addStream(localStream);
      }
    }

    // On receiver side:
    MyApp.onAddStreamSignalled = function(streamDescription) {
      var stream = peerConnection.createReceiveStream(streamDescription);
      MyApp.renderStream(stream);
    }


    // In this exchange, the MediaStreamDescription signalled from the 
    // sender to the receiver may have looked something like this:

    {
      tracks: [
      {
        id: "audio1",
        kind: "audio",
        flows: [
        {
              id: "main",
          transportId: "transport1",
          ssrc: 1111,
          codecs: [
          {
            payloadType: 111,
            name: "opus",
            // ... more codec details
          },
          { 
            payloadType: 112,
            name: "pcmu",
            // ... more codec details
          }]
       }]
     },
     {
        id: "video1",
        kind: "video",
        flows: [
        {
          id: "sim0",
          transportId: "transport2",
          ssrc: 2222,
          codecs: [
          {
            payloadType: 122,
            name: "vp8"
            // ... more codec details
          }]
       },
       {
         id: "sim1",
         transportId: "transport2",
         ssrc: 2223,
         codecs: [
         {
           payloadType: 122,
           name: "vp8",
               // ... more codec details
         }]
       },
       {
         id: "sim2",
         transportId: "transport2",
         ssrc: 2224,
         codecs: [
         {
           payloadType: 122,
           name: "vp8",
               // ... more codec details
         }]
       },

       {
         id: "sim0fec",
         transportId: "transport2",
         ssrc: 2225,
         codecs: [
         {
           payloadType: 122,
           name: "vp8",
           // ...
         }]
       }],
       flowGroups: [
       {
         semantics: "SIM",
         ssrcs: [2222, 2223, 2224]
       },
       {
         semantics: "FEC",
         ssrcs: [2222, 2225]
       }]
     }]
    }


    Constructive feedback is welcome :).
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    --------------060904050004050804040000 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------060904050004050804040000-- --------------090500050407060900010504-- From bernard_aboba@hotmail.com Mon Jun 17 17:14:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D27721F9E90 for ; Mon, 17 Jun 2013 17:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4tifpm6E3gs for ; Mon, 17 Jun 2013 17:14:04 -0700 (PDT) Received: from blu0-omc1-s33.blu0.hotmail.com (blu0-omc1-s33.blu0.hotmail.com [65.55.116.44]) by ietfa.amsl.com (Postfix) with ESMTP id 63B7321F9E6B for ; Mon, 17 Jun 2013 17:14:01 -0700 (PDT) Received: from BLU169-W133 ([65.55.116.7]) by blu0-omc1-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jun 2013 17:14:01 -0700 X-TMN: [wY7vbdkkDCeppRdkhfNB8plnuzP1XNku] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_6f3edcda-c2c9-4425-ae23-c803fe464999_" From: Bernard Aboba To: Roman Shpount Date: Mon, 17 Jun 2013 17:14:00 -0700 Importance: Normal In-Reply-To: References: , , <51BF5F00.90705@jitsi.org>, , , MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jun 2013 00:14:01.0394 (UTC) FILETIME=[BC148920:01CE6BB8] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 00:14:10 -0000 --_6f3edcda-c2c9-4425-ae23-c803fe464999_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =0A= 2) Dissadvantages of using SDP in WebRTC. Roman said:"An unmanageable monster was created which currently stays in th= e way of developing new functionality (bundle)=2C building applications (do= es not provide obvious ways to implement obvious tasks=2C like adding an ex= tra stream without re-negotiating all the existing ones) and even interop w= ith existing SIP endpoints (which was the original but now is complicated s= ince it would require a non trivial set of constraints and subsequent SDP m= anipulation)." [BA] Hard to argue with this=2C but I would point out that b= y far the ugliest part of the monster is the video hindquarters. While one= could argue that we have been living with the warts of SDP for audio and t= herefore know the workarounds=2C with video there are substantial interoper= ability issues=2C *even among vendors who utilize the same codec*=2C someti= mes even in relatively basic scenarios (e.g. P2P video call with H.264/SVC)= . So the "multivendor legacy of interop" just doesn't exist yet (at least= =2C based on standards). So as I see it=2C it does represent progress that= we have contained the SDP monster's impact on the the data channel=2C and= I welcome Peter's effort to enable applications who don't care about SDP t= o minimize its usage even if it is not eliminated entirely. = --_6f3edcda-c2c9-4425-ae23-c803fe464999_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
     =3B
     =3B
    =0A= 2) Dissadvantages of using SDP in WebRTC.

    R= oman said:
    "An unmanageable monster was created which currently s= tays in the way of developing new functionality (bundle)=2C building applic= ations (does not provide obvious ways to implement obvious tasks=2C like ad= ding an extra stream without re-negotiating all the existing ones) and even= interop with existing SIP endpoints (which was the original but now is com= plicated since it would require a non trivial set of constraints and subseq= uent SDP manipulation)."
     =3B
    [BA] Hard to argue wi= th this=2C but I would point out that by far the ugliest part of the monste= r is the video hindquarters. =3B While one could argue that we have bee= n living with the warts of SDP for audio and therefore know the workarounds= =2C with video there are substantial interoperability issues=2C *even among= vendors who utilize the same codec*=2C =3Bsometimes even in relatively= basic scenarios (e.g. P2P video call with H.264/SVC). =3B So the "mult= ivendor legacy of interop" just doesn't exist yet (at least=2C based on sta= ndards).
     =3B
    So as I see it=2C it does represent = progress that we have =3Bcontained the SDP monster's =3Bimpact on t= he =3B the data channel=2C and I welcome Peter's effort to enable appli= cations who don't care about SDP to minimize its usage even if it is not el= iminated entirely. =3B  =3B
    = --_6f3edcda-c2c9-4425-ae23-c803fe464999_-- From silviapfeiffer1@gmail.com Mon Jun 17 18:00:58 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EE821F8AF4 for ; Mon, 17 Jun 2013 18:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5CSYI08HZVw for ; Mon, 17 Jun 2013 18:00:57 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 21CA721F8ADC for ; Mon, 17 Jun 2013 18:00:57 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wd20so3931519obb.5 for ; Mon, 17 Jun 2013 18:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=m+OX1jmfo7tk7uAoY4JfF3wZ45BpAfFyWvVsH1QvDrw=; b=RVLwwiUlJ10DaksXe6f99xn8Tz+kQjI3Uf4NBZ229qzdc6CiQyQeGITiPVaTsbE9MD yIBXp6w1VsHTF5ReEarFDfUuP5O+ibFvh8HpR8rLBirNnepmTPPSo9EU9u8cdv25u/Ro OGeJJhd7UCV/v6bhYMQzm3wfN34kwccX1sgpOzQXNMcETQXk8VowOToicn5yS+adgN0n 43c6mCQjwXT+FVqchclHg2mIpQSNhmTB4c+xgXYl6FRkxvjNKzN2L7lRwRPdTX/Nutws 7i2eXOnWckLzSyk8eFexfrbXxUA9N5bG/PkimhfUtwp83yTicorlg3iKnQVcJ8li1dEQ GUbg== X-Received: by 10.182.33.4 with SMTP id n4mr10305360obi.19.1371517256700; Mon, 17 Jun 2013 18:00:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.116.71 with HTTP; Mon, 17 Jun 2013 18:00:36 -0700 (PDT) In-Reply-To: References: From: Silvia Pfeiffer Date: Tue, 18 Jun 2013 11:00:36 +1000 Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=ISO-8859-1 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 01:00:58 -0000 Hi Peter, all, I'm looking at all this from the view of a JS developer and I am really excited that there is movement in this space. Having hit my head hard against the limitations of the current WebRTC API and being forced to learn SDP to achieve some of the less common use cases, I'm feeling the pain. I am therefore happy to see that there is a proposal for a higher-level API with similarities to the Microsoft's CU-WebRTC proposal and I hope that together with Microsoft's input this can become a really useful API. What I would like to see, though, is a bit different from what you've proposed. In particular, the MediaFlowDescription object is the one object that I believe is supposed to enable JS developers to do "SDP hacking" without having to understand SDP. Unfortunately, the way in which it is currently written, this API doesn't help a JS developer much. There are properties in that object like "ssrc" that mean nothing unless you understand SDP. I would therefore like to recommend making the properties on the MediaFlowDescription more semantic - in particular giving them better names - such that a JS developer really doesn't have to understand SDP to create/change media flow descriptions. Can we find better names for id, transportId and ssrc that are more explicitly expressing what they stand for and when a JS developer would actually change them? It would be nice if the MediaFlowDescription was abstract enough such that in future it doesn't matter if SDP is actually underneath (with offer/answer), but that's not actually my main goal. What I'm after is an API that can be used without having to understand what is underneath. Thanks for listening and HTH, Silvia. On Mon, Jun 17, 2013 at 10:57 PM, Peter Thatcher wrote: > Google is in full support of "Plan B" for encoding multiple media sources in > SDP, and would like to see the Plan A vs. Plan B decision resolved soon. > Recently, though, a third option, called "NoPlan" has been proposed, but it > lacked the details of what a JS API would look like for NoPlan. Cullen > asked to see such an API proposal, and so I have worked with Emil to make > one. He will be adding it to the NoPlan draft, but I will also include it > in this email. > > Again, Google is in full support of "Plan B". But if Plan A vs. Plan B > cannot be decided, then we support NoPlan with the following additions to > the WebRTC JS API as an option that allows implementing either Plan A or > Plan B in Javascript. And even if Plan A vs. Plan B is resolved, these API > additions would still be a big improvement for those WebRTC applications > that don't use SDP for signalling. > > It is a bit long because I have added many comments and examples, but the > actually additions only include two new methods on PeerConnection and a few > new dictionaries. So don't be overwhelmed :). > > > > Intro: This follows the model of createDataChannel, which has a JS method on > PeerConnection that makes it possible to add data channels without going > through SDP. Furthermore, just like createDataChannel allows 2 ways to > handle neogitation (the "I know what I'm doing; Here's what I want to send; > Let me signal everything" mode and the "please take care of it for me; send > an OPEN message" mode), this also has 2 ways to handle negotiation (the "I > know what I'm doing; Here's what I want to send; Let me signal everything" > mode and the "please take care of it for me; send SDP back and forth" > mode). > > Following the success of createDataChannel, this allows simple applications > to Just Work and more advanced applications to easily control what they need > to. In particular, it's possible to use this API to implement either Plan A > or Plan B. > > // The following two method are added to RTCPeerConnection > partial interface RTCPeerConnection { > // Create a stream that is used to send a source stream. > // The MediaSendStream.description can be used for signalling. > // No media is sent until addStream(MediaSendStream) is called. > LocalMediaStream createLocalStream(MediaStream sourceStream); > > // Create a stream that is used to receive media from the remote side, > // given the parameters signalled from MedaiSendStream.description. > MediaStream createRemoteStream(MediaStreamDescription description); > } > > > interface LocalMediaStream implements MediaStream { > // This can be changed at any time, but especially before calling > // PeerConnection.addStream > attribute MediaStreamDescription description; > } > > > // Represents the parameters used to either send or receive a stream > // over a PeerConnection. > dictionary MediaStreamDescription { > MediaStreamTrackDescription[] tracks; > } > > > // Represents the parameters used to either send or receive a track over // > a PeerConnection. A track has many "flows", which can be grouped > // together. > dictionary MediaStreamTrackDescription { > // Same as the MediaStreamTrack.id > DOMString id; > > // Same as the MediaStreamTrack.kind > DOMString kind; > > // A track can have many "flows", such as for Simulcast, FEC, etc. > // And they can be grouped in arbitrary ways. > MediaFlowDescription[] flows; > MediaFlowGroup[] flowGroups; > } > > // Represents the parameters used to either send or receive a "flow" > // over a PeerConnection. A "flow" is a media that arrives with a > // single, unique SSRC. One to many flows together make up the media > // for a track. For example, there may be Simulcast, FEC, and RTX > // flows. > dictionay MediaFlowDescription { > // The "flow id" must be unique to the track, but need not be unique > // outside of the track (two tracks could both have a flow with the > // same flow ID). > DOMString id; > > // Each flow can go over its own transport. If the JS sets this to a > // transportId that doesn't have a transport setup already, the > // browser will use SDP negotiation to setup a transport to back that > // transportId. If This is set to an MID in the SDP, then that MID's > // transport is used. > DOMString transportId; > > // The SSRC used to send the flow. > unsigned int ssrc; > > // When used as receive parameters, this indicates the possible list > // of codecs that might come in for this flow. For exmample, a given > // receive flow could be setup to receive any of OPUS, ISAC, or PCMU. > // When used as send parameters, this indicates that the first codec > // should be used, but the browser can use send other codecs if it > // needs to because of either bandwidth or CPU constraints. > MediaCodecDescription[] codecs; > } > > > dictionary MediaFlowGroup { > DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc > DOMString[] flowids; > } > > dictionary MediaCodecDescription { > unsigned byte payloadType; > DOMString name; > unsigned int? clockRate; > unsigned int? bitRate; > // A grab bag of other fmtp that will need to be further defined. > MediaCodecParam[] params; > } > > dictionary MediaCodecParam { > DOMString key; > DOMString value; > } > > > Notes: > > - When LocalMediaStreams are added using addStream, onnegotiatedneeded is > not called, and those streams are never reflected in future SDP exchanges. > Indeed, it would be impossible to put them in the SDP without first > resolving if that would be Plan A SDP or Plan B SDP. > > - Just like piles of attributes would need to be defined for Plan A and for > Plan B, similar attributes would need to be defined here (Luckily, much > work has already been done figuring out what those parameters are :). > > > Pros: > > - Either Plan A or Plan B or could be implemented in Javascript using this > API > - It exposes all the same functionality to the Javascript as SDP, but in a > much nicer format that is much easier to work with. > - Any other signalling mechanism, such as Jingle or CLUE could be > implemented using this API. > - There is almost no risk of signalling glare. > - Debugging errors with misconfigured descriptions should be much easier > with this than with large SDP blobs. > > > Cons: > > - Now there are two slightly different ways to add streams: by creating a > LocalMediaStream first, and not. This is, however, analogous to setting > "negotiated: true" in createDataChannel. On way is "Just Work", and the > other is more advanced control. > > - All the options in MediaCodecDescription are a bit complicated. Really, > this is only necessary because Plan A requires being able to specify codec > parameters per SSRC, and set each flow on different transports. If we did > not have this requirement, we could simplify. > > > Example Usage: > > // Imagine I have MyApp, handles creating a PeerConnection, > // signalling, and rendering streams. This is how the new API could be > // used. > var peerConnection = MyApp.createPeerConnection(); > > // On sender side: > var stream = MyApp.getMediaStream(); > var localStream = peerConnection.createSendStream(stream); > sendStream.description = MyApp.modifyStream(localStream.description) > MyApp.signalAddStream(localStream.description, function(response)) { > if (!response.rejected) { > // Media will not be sent. > peerConnection.addStream(localStream); > } > } > > // On receiver side: > MyApp.onAddStreamSignalled = function(streamDescription) { > var stream = peerConnection.createReceiveStream(streamDescription); > MyApp.renderStream(stream); > } > > > // In this exchange, the MediaStreamDescription signalled from the > // sender to the receiver may have looked something like this: > > { > tracks: [ > { > id: "audio1", > kind: "audio", > flows: [ > { > id: "main", > transportId: "transport1", > ssrc: 1111, > codecs: [ > { > payloadType: 111, > name: "opus", > // ... more codec details > }, > { > payloadType: 112, > name: "pcmu", > // ... more codec details > }] > }] > }, > { > id: "video1", > kind: "video", > flows: [ > { > id: "sim0", > transportId: "transport2", > ssrc: 2222, > codecs: [ > { > payloadType: 122, > name: "vp8" > // ... more codec details > }] > }, > { > id: "sim1", > transportId: "transport2", > ssrc: 2223, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... more codec details > }] > }, > { > id: "sim2", > transportId: "transport2", > ssrc: 2224, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... more codec details > }] > }, > > { > id: "sim0fec", > transportId: "transport2", > ssrc: 2225, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... > }] > }], > flowGroups: [ > { > semantics: "SIM", > ssrcs: [2222, 2223, 2224] > }, > { > semantics: "FEC", > ssrcs: [2222, 2225] > }] > }] > } > > > Constructive feedback is welcome :). > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From matthew.kaufman@skype.net Mon Jun 17 18:35:16 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECEC21F9DD5 for ; Mon, 17 Jun 2013 18:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmL5uPhU9l3j for ; Mon, 17 Jun 2013 18:35:10 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8E74D21F9CCA for ; Mon, 17 Jun 2013 18:35:10 -0700 (PDT) Received: from BL2FFO11FD005.protection.gbl (10.173.161.203) by BL2FFO11HUB027.protection.gbl (10.173.161.51) with Microsoft SMTP Server (TLS) id 15.0.707.0; Tue, 18 Jun 2013 01:35:07 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD005.mail.protection.outlook.com (10.173.161.1) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 18 Jun 2013 01:35:07 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.171]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Tue, 18 Jun 2013 01:35:06 +0000 From: "Matthew Kaufman (SKYPE)" To: Peter Thatcher , Martin Thomson Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) Thread-Index: AQHOa1pL3f2CtN2bTEydXd59L0Jyj5k6QmQAgAAH7oCAAGYM4A== Date: Tue, 18 Jun 2013 01:35:05 +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.75] Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C5986TK5EX14MBXC273r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(43544003)(199002)(377454002)(52034003)(189002)(24454002)(51704005)(54356001)(55846006)(74502001)(33656001)(76786001)(47976001)(4396001)(20776003)(50986001)(15202345002)(77982001)(49866001)(31966008)(47446002)(44976003)(77096001)(81342001)(47736001)(74366001)(56776001)(51856001)(74662001)(46102001)(512874002)(76796001)(56816003)(76482001)(16406001)(74876001)(81542001)(6806003)(79102001)(80022001)(69226001)(16236675002)(59766001)(66066001)(561944002)(74706001)(54316002)(71186001)(65816001)(63696002)(53806001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB027; H:TK5EX14HUBC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0881A7A935 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 01:35:16 -0000 --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C5986TK5EX14MBXC273r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHByb2JsZW0gaXMgdGhhdCBhbGwgc29ydHMgb2YgaW50ZXJlc3RpbmcgdXNlIGNhc2VzIGFy ZSBoYW1wZXJlZCBieSBoYXZpbmcgYSBnaWFudCBvYmplY3QgdGhhdCBlbmNhcHN1bGF0ZXMgZXZl cnl0aGluZyBhbmQgd2hpY2ggaXMgY29udHJvbGxlZCB3aXRoIGEgcG9pbnR5IFNEUCBzdGljayBv ciBldmVuIGEgc3RpY2sgdGhhdCBoYXMgdGhlIFNEUCBjb3ZlcmVkIGluIHRhcGUgYW5kIGdsdWUu DQoNCkhlcmXigJlzIGFuIGV4YW1wbGUgY2FzZSBJ4oCZZCBsb3ZlIHRvIGhhdmUgc29tZW9uZSBz aG93IG1lIGhvdyB0byBkbyB3aXRoIHRoZSBjdXJyZW50IEFQSToNCg0KICBPcGVuIGEgY29ubmVj dGlvbiBiZXR3ZWVuIGNsaWVudCBBIGFuZCBjbGllbnQgQiB0aGF0IHRlc3RzIGZvciBhIHBlZXIt dG8tcGVlciBwYXRoIGJldHdlZW4gY2xpZW50IEEgYW5kIGNsaWVudCBCIChieSBkb2luZyBhIFNU VU4gY29ubmVjdGl2aXR5IHRlc3QpIGJ1dCB3aGljaCBwcmVmZXJzIHRvIHNlbmQgbWVkaWEgdmlh IGEgcmVsYXllZCBwYXRoIChvdmVyIG15IG93biBwcml2YXRlIGZpYmVyIGJhY2tib25lKS4NCg0K SSB3YW50IHRvIGRvIHRoZSBjb25uZWN0aXZpdHkgdGVzdCBzbyB0aGF0IEkga25vdyB3aGV0aGVy IHdoZW4gdGhlcmXigJlzIGEgcGF0aCBmYWlsdXJlIEkgbmVlZCB0byBpbnN0YW50aWF0ZSBhIG5l dyByZWxheSBwYXRoIG9yIEkgY2FuIGp1c3QgZmFsbCBiYWNrIHRvIHRoZSBJbnRlcm5ldCBwYXRo LiBPaCwgYW5kIEnigJlkIGxpa2UgdG8gY29sbGVjdCB0aGUgZGVyaXZlZCBhZGRyZXNzZXMgYW5k IHNvbWUgb3RoZXIgc3RhdHMgZnJvbSB0aGUgY29ubmVjdGl2aXR5IHRlc3Qgc28gSSBjYW4gZmVl ZCB0aGF0IGJhY2sgaW50byBteSBiaWcgZGF0YSBhbmFseXNpcyBzeXN0ZW0uDQoNCk90aGVyIHRo YW4gb3BlbmluZyBhIHNlY29uZCBmdWxsIFBlZXJDb25uZWN0aW9uIG9iamVjdCwgSSBkb27igJl0 IHNlZSB0aGF0IEkgaGF2ZSBlbm91Z2ggY29udHJvbCBvdmVyIHRoZSBjYW5kaWRhdGUgc2VsZWN0 aW9uLCBldmVuIGlmIEkgbWFuZ2xlIHRoZSBTRFAsIGFuZCBjZXJ0YWlubHkgbm90IGF0IGFsbCBp ZiBJIGRvbuKAmXQuDQoNCk1hdHRoZXcgS2F1Zm1hbg0KDQpGcm9tOiBydGN3ZWItYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGV0 ZXIgVGhhdGNoZXINClNlbnQ6IE1vbmRheSwgSnVuZSAxNywgMjAxMyAxMjoyNiBQTQ0KVG86IE1h cnRpbiBUaG9tc29uDQpDYzogPHJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2Vi XSBQcm9wb3NhbCBmb3IgYSBKUyBBUEkgZm9yIE5vUGxhbiAoYWRkaW5nIG11bHRpcGxlIHNvdXJj ZXMgd2l0aG91dCBlbmNvZGluZyB0aGVtIGluIFNEUCkNCg0KWWVzLCBJIHdhcyBleHBlY3Rpbmcg eW91IHRvIGJlIG1vcmUgc3VwcG9ydGl2ZS4gIEknbSBzdXJwcmlzZWQgb3V0IGhvdyB5b3VyIHdh bnQgImFsbCBvciBub3RoaW5nIi4gIEknbSBhZnJhaWQgaWYgb3VyIG9wdGlvbnMgZm9yIGEgY2xl YW4gQVBJIGFyZSBhbGwgb3Igbm90aGluZywgd2UnbGwganVzdCBlbmQgdXAgd2l0aCBub3RoaW5n LiAgSSdkIHByZWZlciB0byB0cnkgaW5jcmVtZW50YWwgaW1wcm92ZW1lbnRzIHRvIHdvcmQgdG93 YXJkIChldmVudHVhbGx5KSBhIGNsZWFuIEFQSS4NCg0KRG8geW91IHRoaW5rIGl0IGlzIGltcG9z c2libGUgdG8gd29yayB0b3dhcmQgYSBjbGVhbiBBUEkgaW4gYW4gaW5jcmVtZW50YWwgYXBwcm9h Y2g/ICBJZiB5b3UgdGhpbmsgaXQncyBwb3NzaWJsZSwgSSdkIGxpa2UgdG8gaGVhciB5b3VyIHRo b3VnaHRzIG9uIGhvdy4NCg0KDQpCeSB0aGUgd2F5LCB0aGVzZSBBUEkgYWRkaXRpb25zIHdvdWxk IGdyZWF0bHkgbWluaW1pemUgdGhlIGFtb3VudCBvZiBTRFAgZWRpdGluZyBuZWNlc3NhcnkgZm9y IEpTIGNsaWVudHMgdGhhdCBkb24ndCB1c2UgU0RQIGZvciBzaWduYWxsaW5nLiAgQW5kIGxhdGVy IGluY3JlbWVudGFsIGltcHJvdmVtZW50cyBjb3VsZCByZWR1Y2UgaXQgZnVydGhlci4gIEFsc28s IGl0J3Mgbm8gbG9uZ2VyIG5lY2Vzc2FyeSB0byBkbyBvZmZlci9hbnN3ZXIgZm9yIGFkZGluZyB0 cmFja3MuICBJdCdzIG9ubHkgdGhlIGludGlhbCBQZWVyQ29ubmVjdGlvbiBzZXR1cCB0aGF0IG5l ZWRzIHRvIGRvIE9mZmVyL0Fuc3dlci4gIFNvLCBpdCBkb2Vzbid0IGluaGVyaXQgYWxsIHRoZSBw cm9ibGVtcyBxdWl0ZSBhcyBtdWNoIGFzIHlvdSBkZXNjcmliZWQuICBJdCBtYXkgYmUgc2xpZ2h0 bHkgYWJvbWluYWJsZSwgYnV0IEkgY2VydGFpbmx5IGNvbnNpZGVyIGl0IGxlc3MgYWJvbWluYWJs ZSB0aGFuIHRoZSBTRFAgZWRpdGluZyBuZWNlc3Nhcnkgd2l0aG91dCBpdC4NCg0KT24gTW9uLCBK dW4gMTcsIDIwMTMgYXQgMTE6NTcgQU0sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBn bWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KTWF5YmUg eW91J2QgZXhwZWN0IG1lIHRvIGJlIG1vcmUgc3VwcG9ydGl2ZSBvZiBzb21ldGhpbmcgdGhhdCBs b29rZWQNCnNvIG11Y2ggbGlrZSBDVS1SVEMtV2ViLiAgSXQgaW5oZXJpdHMgYWxsIHRoZSB3b3Jz dCBwcm9wZXJ0aWVzIG9mIEpTRVANCihPZmZlci9BbnN3ZXIsIFNEUCBlZGl0aW5nKSB3aXRoIGEg cGFydGlhbCBpbXBsZW1lbnRhdGlvbiBvZiBhIGNsZWFuDQpBUEkuDQoNCkl0J3MgY29tbWVudCAy Mi1saXRlLiAgSXQncyBhbiBhYm9taW5hdGlvbi4gIElmIHlvdSBhcmUgZ29pbmcgdG8gZG8NCnRo aXMsIGRvIGl0IHByb3Blcmx5Lg0KDQpPbiAxNyBKdW5lIDIwMTMgMDU6NTcsIFBldGVyIFRoYXRj aGVyIDxwdGhhdGNoZXJAZ29vZ2xlLmNvbTxtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20+PiB3 cm90ZToNCj4gR29vZ2xlIGlzIGluIGZ1bGwgc3VwcG9ydCBvZiAiUGxhbiBCIiBmb3IgZW5jb2Rp bmcgbXVsdGlwbGUgbWVkaWEgc291cmNlcyBpbg0KPiBTRFAsIGFuZCB3b3VsZCBsaWtlIHRvIHNl ZSB0aGUgUGxhbiBBIHZzLiBQbGFuIEIgZGVjaXNpb24gcmVzb2x2ZWQgc29vbi4NCj4gUmVjZW50 bHksIHRob3VnaCwgYSB0aGlyZCBvcHRpb24sIGNhbGxlZCAiTm9QbGFuIiBoYXMgYmVlbiBwcm9w b3NlZCwgYnV0IGl0DQo+IGxhY2tlZCB0aGUgZGV0YWlscyBvZiB3aGF0IGEgSlMgQVBJIHdvdWxk IGxvb2sgbGlrZSBmb3IgTm9QbGFuLiAgQ3VsbGVuDQo+IGFza2VkIHRvIHNlZSBzdWNoIGFuIEFQ SSBwcm9wb3NhbCwgYW5kIHNvIEkgaGF2ZSB3b3JrZWQgd2l0aCBFbWlsIHRvIG1ha2UNCj4gb25l LiAgSGUgd2lsbCBiZSBhZGRpbmcgaXQgdG8gdGhlIE5vUGxhbiBkcmFmdCwgYnV0IEkgd2lsbCBh bHNvIGluY2x1ZGUgaXQNCj4gaW4gdGhpcyBlbWFpbC4NCj4NCj4gQWdhaW4sIEdvb2dsZSBpcyBp biBmdWxsIHN1cHBvcnQgb2YgIlBsYW4gQiIuICBCdXQgaWYgUGxhbiBBIHZzLiBQbGFuIEINCj4g Y2Fubm90IGJlIGRlY2lkZWQsIHRoZW4gd2Ugc3VwcG9ydCBOb1BsYW4gd2l0aCB0aGUgZm9sbG93 aW5nIGFkZGl0aW9ucyB0bw0KPiB0aGUgV2ViUlRDIEpTIEFQSSBhcyBhbiBvcHRpb24gdGhhdCBh bGxvd3MgaW1wbGVtZW50aW5nIGVpdGhlciBQbGFuIEEgb3INCj4gUGxhbiBCICBpbiBKYXZhc2Ny aXB0LiAgQW5kIGV2ZW4gaWYgUGxhbiBBIHZzLiBQbGFuIEIgaXMgcmVzb2x2ZWQsIHRoZXNlIEFQ SQ0KPiBhZGRpdGlvbnMgd291bGQgc3RpbGwgYmUgYSBiaWcgaW1wcm92ZW1lbnQgZm9yIHRob3Nl IFdlYlJUQyBhcHBsaWNhdGlvbnMNCj4gdGhhdCBkb24ndCB1c2UgU0RQIGZvciBzaWduYWxsaW5n Lg0KPg0KPiBJdCBpcyBhIGJpdCBsb25nIGJlY2F1c2UgSSBoYXZlIGFkZGVkIG1hbnkgY29tbWVu dHMgYW5kIGV4YW1wbGVzLCBidXQgdGhlDQo+IGFjdHVhbGx5IGFkZGl0aW9ucyBvbmx5IGluY2x1 ZGUgdHdvIG5ldyBtZXRob2RzIG9uIFBlZXJDb25uZWN0aW9uIGFuZCBhIGZldw0KPiBuZXcgZGlj dGlvbmFyaWVzLiAgU28gZG9uJ3QgYmUgb3ZlcndoZWxtZWQgOikuDQo+DQo+DQo+DQo+IEludHJv OiBUaGlzIGZvbGxvd3MgdGhlIG1vZGVsIG9mIGNyZWF0ZURhdGFDaGFubmVsLCB3aGljaCBoYXMg YSBKUyBtZXRob2Qgb24NCj4gUGVlckNvbm5lY3Rpb24gdGhhdCBtYWtlcyBpdCBwb3NzaWJsZSB0 byBhZGQgZGF0YSBjaGFubmVscyB3aXRob3V0IGdvaW5nDQo+IHRocm91Z2ggU0RQLiAgRnVydGhl cm1vcmUsIGp1c3QgbGlrZSBjcmVhdGVEYXRhQ2hhbm5lbCBhbGxvd3MgMiB3YXlzIHRvDQo+IGhh bmRsZSBuZW9naXRhdGlvbiAodGhlICJJIGtub3cgd2hhdCBJJ20gZG9pbmc7ICBIZXJlJ3Mgd2hh dCBJIHdhbnQgdG8gc2VuZDsNCj4gTGV0IG1lIHNpZ25hbCBldmVyeXRoaW5nIiBtb2RlIGFuZCB0 aGUgInBsZWFzZSB0YWtlIGNhcmUgb2YgaXQgZm9yIG1lOyAgc2VuZA0KPiBhbiBPUEVOIG1lc3Nh Z2UiIG1vZGUpLCB0aGlzIGFsc28gaGFzIDIgd2F5cyB0byBoYW5kbGUgbmVnb3RpYXRpb24gKHRo ZSAiSQ0KPiBrbm93IHdoYXQgSSdtIGRvaW5nOyBIZXJlJ3Mgd2hhdCBJIHdhbnQgdG8gc2VuZDsg TGV0IG1lIHNpZ25hbCBldmVyeXRoaW5nIg0KPiBtb2RlIGFuZCB0aGUgInBsZWFzZSB0YWtlIGNh cmUgb2YgaXQgZm9yIG1lOyAgc2VuZCBTRFAgYmFjayBhbmQgZm9ydGgiDQo+IG1vZGUpLg0KPg0K PiBGb2xsb3dpbmcgdGhlIHN1Y2Nlc3Mgb2YgY3JlYXRlRGF0YUNoYW5uZWwsIHRoaXMgYWxsb3dz IHNpbXBsZSBhcHBsaWNhdGlvbnMNCj4gdG8gSnVzdCBXb3JrIGFuZCBtb3JlIGFkdmFuY2VkIGFw cGxpY2F0aW9ucyB0byBlYXNpbHkgY29udHJvbCB3aGF0IHRoZXkgbmVlZA0KPiB0by4gIEluIHBh cnRpY3VsYXIsIGl0J3MgcG9zc2libGUgdG8gdXNlIHRoaXMgQVBJIHRvIGltcGxlbWVudCBlaXRo ZXIgUGxhbiBBDQo+IG9yIFBsYW4gQi4NCj4NCj4gLy8gVGhlIGZvbGxvd2luZyB0d28gbWV0aG9k IGFyZSBhZGRlZCB0byBSVENQZWVyQ29ubmVjdGlvbg0KPiBwYXJ0aWFsIGludGVyZmFjZSBSVENQ ZWVyQ29ubmVjdGlvbiB7DQo+ICAvLyBDcmVhdGUgYSBzdHJlYW0gdGhhdCBpcyB1c2VkIHRvIHNl bmQgYSBzb3VyY2Ugc3RyZWFtLg0KPiAgLy8gVGhlIE1lZGlhU2VuZFN0cmVhbS5kZXNjcmlwdGlv biBjYW4gYmUgdXNlZCBmb3Igc2lnbmFsbGluZy4NCj4gIC8vIE5vIG1lZGlhIGlzIHNlbnQgdW50 aWwgYWRkU3RyZWFtKE1lZGlhU2VuZFN0cmVhbSkgaXMgY2FsbGVkLg0KPiAgTG9jYWxNZWRpYVN0 cmVhbSBjcmVhdGVMb2NhbFN0cmVhbShNZWRpYVN0cmVhbSBzb3VyY2VTdHJlYW0pOw0KPg0KPiAg Ly8gQ3JlYXRlIGEgc3RyZWFtIHRoYXQgaXMgdXNlZCB0byByZWNlaXZlIG1lZGlhIGZyb20gdGhl IHJlbW90ZSBzaWRlLA0KPiAgLy8gZ2l2ZW4gdGhlIHBhcmFtZXRlcnMgc2lnbmFsbGVkIGZyb20g TWVkYWlTZW5kU3RyZWFtLmRlc2NyaXB0aW9uLg0KPiAgTWVkaWFTdHJlYW0gY3JlYXRlUmVtb3Rl U3RyZWFtKE1lZGlhU3RyZWFtRGVzY3JpcHRpb24gZGVzY3JpcHRpb24pOw0KPiB9DQo+DQo+DQo+ IGludGVyZmFjZSBMb2NhbE1lZGlhU3RyZWFtIGltcGxlbWVudHMgTWVkaWFTdHJlYW0gew0KPiAg IC8vIFRoaXMgY2FuIGJlIGNoYW5nZWQgYXQgYW55IHRpbWUsIGJ1dCBlc3BlY2lhbGx5IGJlZm9y ZSBjYWxsaW5nDQo+ICAgLy8gUGVlckNvbm5lY3Rpb24uYWRkU3RyZWFtDQo+ICAgYXR0cmlidXRl IE1lZGlhU3RyZWFtRGVzY3JpcHRpb24gZGVzY3JpcHRpb247DQo+IH0NCj4NCj4NCj4gLy8gUmVw cmVzZW50cyB0aGUgcGFyYW1ldGVycyB1c2VkIHRvIGVpdGhlciBzZW5kIG9yIHJlY2VpdmUgYSBz dHJlYW0NCj4gLy8gb3ZlciBhIFBlZXJDb25uZWN0aW9uLg0KPiBkaWN0aW9uYXJ5IE1lZGlhU3Ry ZWFtRGVzY3JpcHRpb24gew0KPiAgIE1lZGlhU3RyZWFtVHJhY2tEZXNjcmlwdGlvbltdIHRyYWNr czsNCj4gfQ0KPg0KPg0KPiAvLyBSZXByZXNlbnRzIHRoZSBwYXJhbWV0ZXJzIHVzZWQgdG8gZWl0 aGVyIHNlbmQgb3IgcmVjZWl2ZSBhIHRyYWNrIG92ZXIgLy8NCj4gYSBQZWVyQ29ubmVjdGlvbi4g IEEgdHJhY2sgaGFzIG1hbnkgImZsb3dzIiwgd2hpY2ggY2FuIGJlIGdyb3VwZWQNCj4gLy8gdG9n ZXRoZXIuDQo+IGRpY3Rpb25hcnkgTWVkaWFTdHJlYW1UcmFja0Rlc2NyaXB0aW9uIHsNCj4gICAv LyBTYW1lIGFzIHRoZSBNZWRpYVN0cmVhbVRyYWNrLmlkDQo+ICAgRE9NU3RyaW5nIGlkOw0KPg0K PiAgIC8vIFNhbWUgYXMgdGhlIE1lZGlhU3RyZWFtVHJhY2sua2luZA0KPiAgIERPTVN0cmluZyBr aW5kOw0KPg0KPiAgIC8vIEEgdHJhY2sgY2FuIGhhdmUgbWFueSAiZmxvd3MiLCBzdWNoIGFzIGZv ciBTaW11bGNhc3QsIEZFQywgZXRjLg0KPiAgIC8vIEFuZCB0aGV5IGNhbiBiZSBncm91cGVkIGlu IGFyYml0cmFyeSB3YXlzLg0KPiAgIE1lZGlhRmxvd0Rlc2NyaXB0aW9uW10gZmxvd3M7DQo+ICAg TWVkaWFGbG93R3JvdXBbXSBmbG93R3JvdXBzOw0KPiB9DQo+DQo+IC8vIFJlcHJlc2VudHMgdGhl IHBhcmFtZXRlcnMgdXNlZCB0byBlaXRoZXIgc2VuZCBvciByZWNlaXZlIGEgImZsb3ciDQo+IC8v IG92ZXIgYSBQZWVyQ29ubmVjdGlvbi4gIEEgImZsb3ciIGlzIGEgbWVkaWEgdGhhdCBhcnJpdmVz IHdpdGggYQ0KPiAvLyBzaW5nbGUsIHVuaXF1ZSBTU1JDLiAgT25lIHRvIG1hbnkgZmxvd3MgdG9n ZXRoZXIgbWFrZSB1cCB0aGUgbWVkaWENCj4gLy8gZm9yIGEgdHJhY2suICBGb3IgZXhhbXBsZSwg dGhlcmUgbWF5IGJlIFNpbXVsY2FzdCwgRkVDLCBhbmQgUlRYDQo+IC8vIGZsb3dzLg0KPiBkaWN0 aW9uYXkgTWVkaWFGbG93RGVzY3JpcHRpb24gew0KPiAgIC8vIFRoZSAiZmxvdyBpZCIgbXVzdCBi ZSB1bmlxdWUgdG8gdGhlIHRyYWNrLCBidXQgbmVlZCBub3QgYmUgdW5pcXVlDQo+ICAgLy8gb3V0 c2lkZSBvZiB0aGUgdHJhY2sgKHR3byB0cmFja3MgY291bGQgYm90aCBoYXZlIGEgZmxvdyB3aXRo IHRoZQ0KPiAgIC8vIHNhbWUgZmxvdyBJRCkuDQo+ICAgRE9NU3RyaW5nIGlkOw0KPg0KPiAgIC8v IEVhY2ggZmxvdyBjYW4gZ28gb3ZlciBpdHMgb3duIHRyYW5zcG9ydC4gIElmIHRoZSBKUyBzZXRz IHRoaXMgdG8gYQ0KPiAgIC8vIHRyYW5zcG9ydElkIHRoYXQgZG9lc24ndCBoYXZlIGEgdHJhbnNw b3J0IHNldHVwIGFscmVhZHksIHRoZQ0KPiAgIC8vIGJyb3dzZXIgd2lsbCB1c2UgU0RQIG5lZ290 aWF0aW9uIHRvIHNldHVwIGEgdHJhbnNwb3J0IHRvIGJhY2sgdGhhdA0KPiAgIC8vIHRyYW5zcG9y dElkLiAgSWYgVGhpcyBpcyBzZXQgdG8gYW4gTUlEIGluIHRoZSBTRFAsIHRoZW4gdGhhdCBNSUQn cw0KPiAgIC8vIHRyYW5zcG9ydCBpcyB1c2VkLg0KPiAgIERPTVN0cmluZyB0cmFuc3BvcnRJZDsN Cj4NCj4gICAvLyBUaGUgU1NSQyB1c2VkIHRvIHNlbmQgdGhlIGZsb3cuDQo+ICAgdW5zaWduZWQg aW50IHNzcmM7DQo+DQo+ICAgLy8gV2hlbiB1c2VkIGFzIHJlY2VpdmUgcGFyYW1ldGVycywgdGhp cyBpbmRpY2F0ZXMgdGhlIHBvc3NpYmxlIGxpc3QNCj4gICAvLyBvZiBjb2RlY3MgdGhhdCBtaWdo dCBjb21lIGluIGZvciB0aGlzIGZsb3cuICBGb3IgZXhtYW1wbGUsIGEgZ2l2ZW4NCj4gICAvLyBy ZWNlaXZlIGZsb3cgY291bGQgYmUgc2V0dXAgdG8gcmVjZWl2ZSBhbnkgb2YgT1BVUywgSVNBQywg b3IgUENNVS4NCj4gICAvLyBXaGVuIHVzZWQgYXMgc2VuZCBwYXJhbWV0ZXJzLCB0aGlzIGluZGlj YXRlcyB0aGF0IHRoZSBmaXJzdCBjb2RlYw0KPiAgIC8vIHNob3VsZCBiZSB1c2VkLCBidXQgdGhl IGJyb3dzZXIgY2FuIHVzZSBzZW5kIG90aGVyIGNvZGVjcyBpZiBpdA0KPiAgIC8vIG5lZWRzIHRv IGJlY2F1c2Ugb2YgZWl0aGVyIGJhbmR3aWR0aCBvciBDUFUgY29uc3RyYWludHMuDQo+ICAgTWVk aWFDb2RlY0Rlc2NyaXB0aW9uW10gY29kZWNzOw0KPiB9DQo+DQo+DQo+IGRpY3Rpb25hcnkgTWVk aWFGbG93R3JvdXAgew0KPiAgIERPTVN0cmluZyB0eXBlOyAgLy8gIlNJTSIgZm9yIFNpbXVsY2Fz dCwgIkZFQyIgZm9yIEZFQywgZXRjDQo+ICAgRE9NU3RyaW5nW10gZmxvd2lkczsNCj4gfQ0KPg0K PiBkaWN0aW9uYXJ5IE1lZGlhQ29kZWNEZXNjcmlwdGlvbiB7DQo+ICAgdW5zaWduZWQgYnl0ZSBw YXlsb2FkVHlwZTsNCj4gICBET01TdHJpbmcgbmFtZTsNCj4gICB1bnNpZ25lZCBpbnQ/IGNsb2Nr UmF0ZTsNCj4gICB1bnNpZ25lZCBpbnQ/IGJpdFJhdGU7DQo+ICAgLy8gQSBncmFiIGJhZyBvZiBv dGhlciBmbXRwIHRoYXQgd2lsbCBuZWVkIHRvIGJlIGZ1cnRoZXIgZGVmaW5lZC4NCj4gICBNZWRp YUNvZGVjUGFyYW1bXSBwYXJhbXM7DQo+IH0NCj4NCj4gZGljdGlvbmFyeSBNZWRpYUNvZGVjUGFy YW0gew0KPiAgIERPTVN0cmluZyBrZXk7DQo+ICAgRE9NU3RyaW5nIHZhbHVlOw0KPiB9DQo+DQo+ DQo+IE5vdGVzOg0KPg0KPiAtIFdoZW4gTG9jYWxNZWRpYVN0cmVhbXMgYXJlIGFkZGVkIHVzaW5n IGFkZFN0cmVhbSwgb25uZWdvdGlhdGVkbmVlZGVkIGlzDQo+IG5vdCBjYWxsZWQsIGFuZCB0aG9z ZSBzdHJlYW1zIGFyZSBuZXZlciByZWZsZWN0ZWQgaW4gZnV0dXJlIFNEUCBleGNoYW5nZXMuDQo+ IEluZGVlZCwgaXQgd291bGQgYmUgaW1wb3NzaWJsZSB0byBwdXQgdGhlbSBpbiB0aGUgU0RQIHdp dGhvdXQgZmlyc3QNCj4gcmVzb2x2aW5nIGlmIHRoYXQgd291bGQgYmUgUGxhbiBBIFNEUCBvciBQ bGFuIEIgU0RQLg0KPg0KPiAtIEp1c3QgbGlrZSBwaWxlcyBvZiBhdHRyaWJ1dGVzIHdvdWxkIG5l ZWQgdG8gYmUgZGVmaW5lZCBmb3IgUGxhbiBBIGFuZCBmb3INCj4gUGxhbiBCLCBzaW1pbGFyIGF0 dHJpYnV0ZXMgd291bGQgbmVlZCB0byBiZSBkZWZpbmVkIGhlcmUgKEx1Y2tpbHksICBtdWNoDQo+ IHdvcmsgaGFzIGFscmVhZHkgYmVlbiBkb25lIGZpZ3VyaW5nIG91dCB3aGF0IHRob3NlIHBhcmFt ZXRlcnMgYXJlIDopLg0KPg0KPg0KPiBQcm9zOg0KPg0KPiAtIEVpdGhlciBQbGFuIEEgb3IgUGxh biBCIG9yIGNvdWxkIGJlIGltcGxlbWVudGVkIGluIEphdmFzY3JpcHQgdXNpbmcgdGhpcw0KPiBB UEkNCj4gLSBJdCBleHBvc2VzIGFsbCB0aGUgc2FtZSBmdW5jdGlvbmFsaXR5IHRvIHRoZSBKYXZh c2NyaXB0IGFzIFNEUCwgYnV0IGluIGENCj4gbXVjaCBuaWNlciBmb3JtYXQgdGhhdCBpcyBtdWNo IGVhc2llciB0byB3b3JrIHdpdGguDQo+IC0gQW55IG90aGVyIHNpZ25hbGxpbmcgbWVjaGFuaXNt LCBzdWNoIGFzIEppbmdsZSBvciBDTFVFIGNvdWxkIGJlDQo+IGltcGxlbWVudGVkIHVzaW5nIHRo aXMgQVBJLg0KPiAtIFRoZXJlIGlzIGFsbW9zdCBubyByaXNrIG9mIHNpZ25hbGxpbmcgZ2xhcmUu DQo+IC0gRGVidWdnaW5nIGVycm9ycyB3aXRoIG1pc2NvbmZpZ3VyZWQgZGVzY3JpcHRpb25zIHNo b3VsZCBiZSBtdWNoIGVhc2llcg0KPiB3aXRoIHRoaXMgdGhhbiB3aXRoIGxhcmdlIFNEUCBibG9i cy4NCj4NCj4NCj4gQ29uczoNCj4NCj4gLSBOb3cgdGhlcmUgYXJlIHR3byBzbGlnaHRseSBkaWZm ZXJlbnQgd2F5cyB0byBhZGQgc3RyZWFtczogYnkgY3JlYXRpbmcgYQ0KPiBMb2NhbE1lZGlhU3Ry ZWFtIGZpcnN0LCBhbmQgbm90LiAgVGhpcyBpcywgaG93ZXZlciwgYW5hbG9nb3VzIHRvIHNldHRp bmcNCj4gIm5lZ290aWF0ZWQ6IHRydWUiIGluIGNyZWF0ZURhdGFDaGFubmVsLiAgT24gd2F5IGlz ICJKdXN0IFdvcmsiLCBhbmQgdGhlDQo+IG90aGVyIGlzIG1vcmUgYWR2YW5jZWQgY29udHJvbC4N Cj4NCj4gLSBBbGwgdGhlIG9wdGlvbnMgaW4gTWVkaWFDb2RlY0Rlc2NyaXB0aW9uIGFyZSBhIGJp dCBjb21wbGljYXRlZC4gIFJlYWxseSwNCj4gdGhpcyBpcyBvbmx5IG5lY2Vzc2FyeSBiZWNhdXNl IFBsYW4gQSByZXF1aXJlcyBiZWluZyBhYmxlIHRvIHNwZWNpZnkgY29kZWMNCj4gcGFyYW1ldGVy cyBwZXIgU1NSQywgYW5kIHNldCBlYWNoIGZsb3cgb24gZGlmZmVyZW50IHRyYW5zcG9ydHMuICBJ ZiB3ZSBkaWQNCj4gbm90IGhhdmUgdGhpcyByZXF1aXJlbWVudCwgd2UgY291bGQgc2ltcGxpZnku DQo+DQo+DQo+IEV4YW1wbGUgVXNhZ2U6DQo+DQo+IC8vIEltYWdpbmUgSSBoYXZlIE15QXBwLCBo YW5kbGVzIGNyZWF0aW5nIGEgUGVlckNvbm5lY3Rpb24sDQo+IC8vIHNpZ25hbGxpbmcsIGFuZCBy ZW5kZXJpbmcgc3RyZWFtcy4gIFRoaXMgaXMgaG93IHRoZSBuZXcgQVBJIGNvdWxkIGJlDQo+IC8v IHVzZWQuDQo+IHZhciBwZWVyQ29ubmVjdGlvbiA9IE15QXBwLmNyZWF0ZVBlZXJDb25uZWN0aW9u KCk7DQo+DQo+IC8vIE9uIHNlbmRlciBzaWRlOg0KPiB2YXIgc3RyZWFtID0gTXlBcHAuZ2V0TWVk aWFTdHJlYW0oKTsNCj4gdmFyIGxvY2FsU3RyZWFtID0gcGVlckNvbm5lY3Rpb24uY3JlYXRlU2Vu ZFN0cmVhbShzdHJlYW0pOw0KPiBzZW5kU3RyZWFtLmRlc2NyaXB0aW9uID0gTXlBcHAubW9kaWZ5 U3RyZWFtKGxvY2FsU3RyZWFtLmRlc2NyaXB0aW9uKQ0KPiBNeUFwcC5zaWduYWxBZGRTdHJlYW0o bG9jYWxTdHJlYW0uZGVzY3JpcHRpb24sIGZ1bmN0aW9uKHJlc3BvbnNlKSkgew0KPiAgIGlmICgh cmVzcG9uc2UucmVqZWN0ZWQpIHsNCj4gICAgIC8vIE1lZGlhIHdpbGwgbm90IGJlIHNlbnQuDQo+ ICAgICBwZWVyQ29ubmVjdGlvbi5hZGRTdHJlYW0obG9jYWxTdHJlYW0pOw0KPiAgIH0NCj4gfQ0K Pg0KPiAvLyBPbiByZWNlaXZlciBzaWRlOg0KPiBNeUFwcC5vbkFkZFN0cmVhbVNpZ25hbGxlZCA9 IGZ1bmN0aW9uKHN0cmVhbURlc2NyaXB0aW9uKSB7DQo+ICAgdmFyIHN0cmVhbSA9IHBlZXJDb25u ZWN0aW9uLmNyZWF0ZVJlY2VpdmVTdHJlYW0oc3RyZWFtRGVzY3JpcHRpb24pOw0KPiAgIE15QXBw LnJlbmRlclN0cmVhbShzdHJlYW0pOw0KPiB9DQo+DQo+DQo+IC8vIEluIHRoaXMgZXhjaGFuZ2Us IHRoZSBNZWRpYVN0cmVhbURlc2NyaXB0aW9uIHNpZ25hbGxlZCBmcm9tIHRoZQ0KPiAvLyBzZW5k ZXIgdG8gdGhlIHJlY2VpdmVyIG1heSBoYXZlIGxvb2tlZCBzb21ldGhpbmcgbGlrZSB0aGlzOg0K Pg0KPiB7DQo+ICAgdHJhY2tzOiBbDQo+ICAgew0KPiAgICAgaWQ6ICJhdWRpbzEiLA0KPiAgICAg a2luZDogImF1ZGlvIiwNCj4gICAgIGZsb3dzOiBbDQo+ICAgICB7DQo+ICAgICAgIGlkOiAibWFp biIsDQo+ICAgICAgIHRyYW5zcG9ydElkOiAidHJhbnNwb3J0MSIsDQo+ICAgICAgIHNzcmM6IDEx MTEsDQo+ICAgICAgIGNvZGVjczogWw0KPiAgICAgICB7DQo+ICAgICAgICAgcGF5bG9hZFR5cGU6 IDExMSwNCj4gICAgICAgICBuYW1lOiAib3B1cyIsDQo+ICAgICAgICAgLy8gLi4uIG1vcmUgY29k ZWMgZGV0YWlscw0KPiAgICAgICB9LA0KPiAgICAgICB7DQo+ICAgICAgICAgcGF5bG9hZFR5cGU6 IDExMiwNCj4gICAgICAgICBuYW1lOiAicGNtdSIsDQo+ICAgICAgICAgLy8gLi4uIG1vcmUgY29k ZWMgZGV0YWlscw0KPiAgICAgICB9XQ0KPiAgICB9XQ0KPiAgfSwNCj4gIHsNCj4gICAgIGlkOiAi dmlkZW8xIiwNCj4gICAgIGtpbmQ6ICJ2aWRlbyIsDQo+ICAgICBmbG93czogWw0KPiAgICAgew0K PiAgICAgICBpZDogInNpbTAiLA0KPiAgICAgICB0cmFuc3BvcnRJZDogInRyYW5zcG9ydDIiLA0K PiAgICAgICBzc3JjOiAyMjIyLA0KPiAgICAgICBjb2RlY3M6IFsNCj4gICAgICAgew0KPiAgICAg ICAgIHBheWxvYWRUeXBlOiAxMjIsDQo+ICAgICAgICAgbmFtZTogInZwOCINCj4gICAgICAgICAv LyAuLi4gbW9yZSBjb2RlYyBkZXRhaWxzDQo+ICAgICAgIH1dDQo+ICAgIH0sDQo+ICAgIHsNCj4g ICAgICBpZDogInNpbTEiLA0KPiAgICAgIHRyYW5zcG9ydElkOiAidHJhbnNwb3J0MiIsDQo+ICAg ICAgc3NyYzogMjIyMywNCj4gICAgICBjb2RlY3M6IFsNCj4gICAgICB7DQo+ICAgICAgICBwYXls b2FkVHlwZTogMTIyLA0KPiAgICAgICAgbmFtZTogInZwOCIsDQo+ICAgICAgICAvLyAuLi4gbW9y ZSBjb2RlYyBkZXRhaWxzDQo+ICAgICAgfV0NCj4gICAgfSwNCj4gICAgew0KPiAgICAgIGlkOiAi c2ltMiIsDQo+ICAgICAgdHJhbnNwb3J0SWQ6ICJ0cmFuc3BvcnQyIiwNCj4gICAgICBzc3JjOiAy MjI0LA0KPiAgICAgIGNvZGVjczogWw0KPiAgICAgIHsNCj4gICAgICAgIHBheWxvYWRUeXBlOiAx MjIsDQo+ICAgICAgICBuYW1lOiAidnA4IiwNCj4gICAgICAgIC8vIC4uLiBtb3JlIGNvZGVjIGRl dGFpbHMNCj4gICAgICB9XQ0KPiAgICB9LA0KPg0KPiAgICB7DQo+ICAgICAgaWQ6ICJzaW0wZmVj IiwNCj4gICAgICB0cmFuc3BvcnRJZDogInRyYW5zcG9ydDIiLA0KPiAgICAgIHNzcmM6IDIyMjUs DQo+ICAgICAgY29kZWNzOiBbDQo+ICAgICAgew0KPiAgICAgICAgcGF5bG9hZFR5cGU6IDEyMiwN Cj4gICAgICAgIG5hbWU6ICJ2cDgiLA0KPiAgICAgICAgLy8gLi4uDQo+ICAgICAgfV0NCj4gICAg fV0sDQo+ICAgIGZsb3dHcm91cHM6IFsNCj4gICAgew0KPiAgICAgIHNlbWFudGljczogIlNJTSIs DQo+ICAgICAgc3NyY3M6IFsyMjIyLCAyMjIzLCAyMjI0XQ0KPiAgICB9LA0KPiAgICB7DQo+ICAg ICAgc2VtYW50aWNzOiAiRkVDIiwNCj4gICAgICBzc3JjczogWzIyMjIsIDIyMjVdDQo+ICAgIH1d DQo+ICB9XQ0KPiB9DQo+DQo+DQo+IENvbnN0cnVjdGl2ZSBmZWVkYmFjayBpcyB3ZWxjb21lIDop Lg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGll dGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K Pg0KDQo= --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C5986TK5EX14MBXC273r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhlIHByb2JsZW0gaXMgdGhhdCBhbGwgc29ydHMgb2YgaW50ZXJl c3RpbmcgdXNlIGNhc2VzIGFyZSBoYW1wZXJlZCBieSBoYXZpbmcgYSBnaWFudCBvYmplY3QgdGhh dCBlbmNhcHN1bGF0ZXMgZXZlcnl0aGluZyBhbmQgd2hpY2gNCiBpcyBjb250cm9sbGVkIHdpdGgg YSBwb2ludHkgU0RQIHN0aWNrIG9yIGV2ZW4gYSBzdGljayB0aGF0IGhhcyB0aGUgU0RQIGNvdmVy ZWQgaW4gdGFwZSBhbmQgZ2x1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZXJl4oCZcyBhbiBleGFtcGxlIGNh c2UgSeKAmWQgbG92ZSB0byBoYXZlIHNvbWVvbmUgc2hvdyBtZSBob3cgdG8gZG8gd2l0aCB0aGUg Y3VycmVudCBBUEk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsgT3BlbiBhIGNvbm5lY3Rpb24gYmV0d2VlbiBj bGllbnQgQSBhbmQgY2xpZW50IEIgdGhhdCB0ZXN0cyBmb3IgYSBwZWVyLXRvLXBlZXIgcGF0aCBi ZXR3ZWVuIGNsaWVudCBBIGFuZCBjbGllbnQgQiAoYnkgZG9pbmcgYSBTVFVOIGNvbm5lY3Rpdml0 eSB0ZXN0KSBidXQgd2hpY2gNCiBwcmVmZXJzIHRvIHNlbmQgbWVkaWEgdmlhIGEgcmVsYXllZCBw YXRoIChvdmVyIG15IG93biBwcml2YXRlIGZpYmVyIGJhY2tib25lKS4gPG86cD4NCjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg d2FudCB0byBkbyB0aGUgY29ubmVjdGl2aXR5IHRlc3Qgc28gdGhhdCBJIGtub3cgd2hldGhlciB3 aGVuIHRoZXJl4oCZcyBhIHBhdGggZmFpbHVyZSBJIG5lZWQgdG8gaW5zdGFudGlhdGUgYSBuZXcg cmVsYXkgcGF0aCBvciBJIGNhbiBqdXN0IGZhbGwgYmFjayB0byB0aGUNCiBJbnRlcm5ldCBwYXRo LiBPaCwgYW5kIEnigJlkIGxpa2UgdG8gY29sbGVjdCB0aGUgZGVyaXZlZCBhZGRyZXNzZXMgYW5k IHNvbWUgb3RoZXIgc3RhdHMgZnJvbSB0aGUgY29ubmVjdGl2aXR5IHRlc3Qgc28gSSBjYW4gZmVl ZCB0aGF0IGJhY2sgaW50byBteSBiaWcgZGF0YSBhbmFseXNpcyBzeXN0ZW0uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5P dGhlciB0aGFuIG9wZW5pbmcgYSBzZWNvbmQgZnVsbCBQZWVyQ29ubmVjdGlvbiBvYmplY3QsIEkg ZG9u4oCZdCBzZWUgdGhhdCBJIGhhdmUgZW5vdWdoIGNvbnRyb2wgb3ZlciB0aGUgY2FuZGlkYXRl IHNlbGVjdGlvbiwgZXZlbiBpZiBJIG1hbmdsZSB0aGUgU0RQLCBhbmQgY2VydGFpbmx5DQogbm90 IGF0IGFsbCBpZiBJIGRvbuKAmXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYXR0aGV3IEthdWZtYW48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWItYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5QZXRlciBUaGF0Y2hlcjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMTcsIDIwMTMg MTI6MjYgUE08YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBUaG9tc29uPGJyPg0KPGI+Q2M6PC9iPiAm bHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0g UHJvcG9zYWwgZm9yIGEgSlMgQVBJIGZvciBOb1BsYW4gKGFkZGluZyBtdWx0aXBsZSBzb3VyY2Vz IHdpdGhvdXQgZW5jb2RpbmcgdGhlbSBpbiBTRFApPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgSSB3YXMgZXhwZWN0aW5nIHlvdSB0byBi ZSBtb3JlIHN1cHBvcnRpdmUuICZuYnNwO0knbSBzdXJwcmlzZWQgb3V0IGhvdyB5b3VyIHdhbnQg JnF1b3Q7YWxsIG9yIG5vdGhpbmcmcXVvdDsuICZuYnNwO0knbSBhZnJhaWQgaWYgb3VyIG9wdGlv bnMgZm9yIGEgY2xlYW4gQVBJIGFyZSBhbGwgb3Igbm90aGluZywgd2UnbGwganVzdCBlbmQgdXAg d2l0aCBub3RoaW5nLiAmbmJzcDtJJ2QgcHJlZmVyIHRvIHRyeSBpbmNyZW1lbnRhbCBpbXByb3Zl bWVudHMNCiB0byB3b3JkIHRvd2FyZCAoZXZlbnR1YWxseSkgYSBjbGVhbiBBUEkuJm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB5b3UgdGhpbmsg aXQgaXMgaW1wb3NzaWJsZSB0byB3b3JrIHRvd2FyZCBhIGNsZWFuIEFQSSBpbiBhbiBpbmNyZW1l bnRhbCBhcHByb2FjaD8gJm5ic3A7SWYgeW91IHRoaW5rIGl0J3MgcG9zc2libGUsIEknZCBsaWtl IHRvIGhlYXIgeW91ciB0aG91Z2h0cyBvbiBob3cuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ5IHRoZSB3YXksIHRoZXNlIEFQSSBhZGRpdGlv bnMgd291bGQgZ3JlYXRseSBtaW5pbWl6ZSB0aGUgYW1vdW50IG9mIFNEUCBlZGl0aW5nIG5lY2Vz c2FyeSBmb3IgSlMgY2xpZW50cyB0aGF0IGRvbid0IHVzZSBTRFAgZm9yIHNpZ25hbGxpbmcuICZu YnNwO0FuZCBsYXRlciBpbmNyZW1lbnRhbCBpbXByb3ZlbWVudHMgY291bGQgcmVkdWNlIGl0IGZ1 cnRoZXIuICZuYnNwO0Fsc28sIGl0J3Mgbm8gbG9uZ2VyIG5lY2Vzc2FyeSB0bw0KIGRvIG9mZmVy L2Fuc3dlciBmb3IgYWRkaW5nIHRyYWNrcy4gJm5ic3A7SXQncyBvbmx5IHRoZSBpbnRpYWwgUGVl ckNvbm5lY3Rpb24gc2V0dXAgdGhhdCBuZWVkcyB0byBkbyBPZmZlci9BbnN3ZXIuICZuYnNwO1Nv LCBpdCBkb2Vzbid0IGluaGVyaXQgYWxsIHRoZSBwcm9ibGVtcyBxdWl0ZSBhcyBtdWNoIGFzIHlv dSBkZXNjcmliZWQuICZuYnNwO0l0IG1heSBiZSBzbGlnaHRseSBhYm9taW5hYmxlLCBidXQgSSBj ZXJ0YWlubHkgY29uc2lkZXIgaXQgbGVzcyBhYm9taW5hYmxlDQogdGhhbiB0aGUgU0RQIGVkaXRp bmcgbmVjZXNzYXJ5IHdpdGhvdXQgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9u LCBKdW4gMTcsIDIwMTMgYXQgMTE6NTcgQU0sIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJt YWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLnRo b21zb25AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWF5YmUgeW91J2QgZXhwZWN0IG1lIHRvIGJlIG1vcmUg c3VwcG9ydGl2ZSBvZiBzb21ldGhpbmcgdGhhdCBsb29rZWQ8YnI+DQpzbyBtdWNoIGxpa2UgQ1Ut UlRDLVdlYi4gJm5ic3A7SXQgaW5oZXJpdHMgYWxsIHRoZSB3b3JzdCBwcm9wZXJ0aWVzIG9mIEpT RVA8YnI+DQooT2ZmZXIvQW5zd2VyLCBTRFAgZWRpdGluZykgd2l0aCBhIHBhcnRpYWwgaW1wbGVt ZW50YXRpb24gb2YgYSBjbGVhbjxicj4NCkFQSS48YnI+DQo8YnI+DQpJdCdzIGNvbW1lbnQgMjIt bGl0ZS4gJm5ic3A7SXQncyBhbiBhYm9taW5hdGlvbi4gJm5ic3A7SWYgeW91IGFyZSBnb2luZyB0 byBkbzxicj4NCnRoaXMsIGRvIGl0IHByb3Blcmx5LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpPbiAxNyBKdW5lIDIwMTMgMDU6NTcsIFBl dGVyIFRoYXRjaGVyICZsdDs8YSBocmVmPSJtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20iIHRh cmdldD0iX2JsYW5rIj5wdGhhdGNoZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZn dDsgR29vZ2xlIGlzIGluIGZ1bGwgc3VwcG9ydCBvZiAmcXVvdDtQbGFuIEImcXVvdDsgZm9yIGVu Y29kaW5nIG11bHRpcGxlIG1lZGlhIHNvdXJjZXMgaW48YnI+DQomZ3Q7IFNEUCwgYW5kIHdvdWxk IGxpa2UgdG8gc2VlIHRoZSBQbGFuIEEgdnMuIFBsYW4gQiBkZWNpc2lvbiByZXNvbHZlZCBzb29u Ljxicj4NCiZndDsgUmVjZW50bHksIHRob3VnaCwgYSB0aGlyZCBvcHRpb24sIGNhbGxlZCAmcXVv dDtOb1BsYW4mcXVvdDsgaGFzIGJlZW4gcHJvcG9zZWQsIGJ1dCBpdDxicj4NCiZndDsgbGFja2Vk IHRoZSBkZXRhaWxzIG9mIHdoYXQgYSBKUyBBUEkgd291bGQgbG9vayBsaWtlIGZvciBOb1BsYW4u ICZuYnNwO0N1bGxlbjxicj4NCiZndDsgYXNrZWQgdG8gc2VlIHN1Y2ggYW4gQVBJIHByb3Bvc2Fs LCBhbmQgc28gSSBoYXZlIHdvcmtlZCB3aXRoIEVtaWwgdG8gbWFrZTxicj4NCiZndDsgb25lLiAm bmJzcDtIZSB3aWxsIGJlIGFkZGluZyBpdCB0byB0aGUgTm9QbGFuIGRyYWZ0LCBidXQgSSB3aWxs IGFsc28gaW5jbHVkZSBpdDxicj4NCiZndDsgaW4gdGhpcyBlbWFpbC48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBBZ2FpbiwgR29vZ2xlIGlzIGluIGZ1bGwgc3VwcG9ydCBvZiAmcXVvdDtQbGFuIEImcXVv dDsuICZuYnNwO0J1dCBpZiBQbGFuIEEgdnMuIFBsYW4gQjxicj4NCiZndDsgY2Fubm90IGJlIGRl Y2lkZWQsIHRoZW4gd2Ugc3VwcG9ydCBOb1BsYW4gd2l0aCB0aGUgZm9sbG93aW5nIGFkZGl0aW9u cyB0bzxicj4NCiZndDsgdGhlIFdlYlJUQyBKUyBBUEkgYXMgYW4gb3B0aW9uIHRoYXQgYWxsb3dz IGltcGxlbWVudGluZyBlaXRoZXIgUGxhbiBBIG9yPGJyPg0KJmd0OyBQbGFuIEIgJm5ic3A7aW4g SmF2YXNjcmlwdC4gJm5ic3A7QW5kIGV2ZW4gaWYgUGxhbiBBIHZzLiBQbGFuIEIgaXMgcmVzb2x2 ZWQsIHRoZXNlIEFQSTxicj4NCiZndDsgYWRkaXRpb25zIHdvdWxkIHN0aWxsIGJlIGEgYmlnIGlt cHJvdmVtZW50IGZvciB0aG9zZSBXZWJSVEMgYXBwbGljYXRpb25zPGJyPg0KJmd0OyB0aGF0IGRv bid0IHVzZSBTRFAgZm9yIHNpZ25hbGxpbmcuPGJyPg0KJmd0Ozxicj4NCiZndDsgSXQgaXMgYSBi aXQgbG9uZyBiZWNhdXNlIEkgaGF2ZSBhZGRlZCBtYW55IGNvbW1lbnRzIGFuZCBleGFtcGxlcywg YnV0IHRoZTxicj4NCiZndDsgYWN0dWFsbHkgYWRkaXRpb25zIG9ubHkgaW5jbHVkZSB0d28gbmV3 IG1ldGhvZHMgb24gUGVlckNvbm5lY3Rpb24gYW5kIGEgZmV3PGJyPg0KJmd0OyBuZXcgZGljdGlv bmFyaWVzLiAmbmJzcDtTbyBkb24ndCBiZSBvdmVyd2hlbG1lZCA6KS48YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEludHJvOiBUaGlzIGZvbGxvd3MgdGhlIG1vZGVsIG9m IGNyZWF0ZURhdGFDaGFubmVsLCB3aGljaCBoYXMgYSBKUyBtZXRob2Qgb248YnI+DQomZ3Q7IFBl ZXJDb25uZWN0aW9uIHRoYXQgbWFrZXMgaXQgcG9zc2libGUgdG8gYWRkIGRhdGEgY2hhbm5lbHMg d2l0aG91dCBnb2luZzxicj4NCiZndDsgdGhyb3VnaCBTRFAuICZuYnNwO0Z1cnRoZXJtb3JlLCBq dXN0IGxpa2UgY3JlYXRlRGF0YUNoYW5uZWwgYWxsb3dzIDIgd2F5cyB0bzxicj4NCiZndDsgaGFu ZGxlIG5lb2dpdGF0aW9uICh0aGUgJnF1b3Q7SSBrbm93IHdoYXQgSSdtIGRvaW5nOyAmbmJzcDtI ZXJlJ3Mgd2hhdCBJIHdhbnQgdG8gc2VuZDs8YnI+DQomZ3Q7IExldCBtZSBzaWduYWwgZXZlcnl0 aGluZyZxdW90OyBtb2RlIGFuZCB0aGUgJnF1b3Q7cGxlYXNlIHRha2UgY2FyZSBvZiBpdCBmb3Ig bWU7ICZuYnNwO3NlbmQ8YnI+DQomZ3Q7IGFuIE9QRU4gbWVzc2FnZSZxdW90OyBtb2RlKSwgdGhp cyBhbHNvIGhhcyAyIHdheXMgdG8gaGFuZGxlIG5lZ290aWF0aW9uICh0aGUgJnF1b3Q7STxicj4N CiZndDsga25vdyB3aGF0IEknbSBkb2luZzsgSGVyZSdzIHdoYXQgSSB3YW50IHRvIHNlbmQ7IExl dCBtZSBzaWduYWwgZXZlcnl0aGluZyZxdW90Ozxicj4NCiZndDsgbW9kZSBhbmQgdGhlICZxdW90 O3BsZWFzZSB0YWtlIGNhcmUgb2YgaXQgZm9yIG1lOyAmbmJzcDtzZW5kIFNEUCBiYWNrIGFuZCBm b3J0aCZxdW90Ozxicj4NCiZndDsgbW9kZSkuPGJyPg0KJmd0Ozxicj4NCiZndDsgRm9sbG93aW5n IHRoZSBzdWNjZXNzIG9mIGNyZWF0ZURhdGFDaGFubmVsLCB0aGlzIGFsbG93cyBzaW1wbGUgYXBw bGljYXRpb25zPGJyPg0KJmd0OyB0byBKdXN0IFdvcmsgYW5kIG1vcmUgYWR2YW5jZWQgYXBwbGlj YXRpb25zIHRvIGVhc2lseSBjb250cm9sIHdoYXQgdGhleSBuZWVkPGJyPg0KJmd0OyB0by4gJm5i c3A7SW4gcGFydGljdWxhciwgaXQncyBwb3NzaWJsZSB0byB1c2UgdGhpcyBBUEkgdG8gaW1wbGVt ZW50IGVpdGhlciBQbGFuIEE8YnI+DQomZ3Q7IG9yIFBsYW4gQi48YnI+DQomZ3Q7PGJyPg0KJmd0 OyAvLyBUaGUgZm9sbG93aW5nIHR3byBtZXRob2QgYXJlIGFkZGVkIHRvIFJUQ1BlZXJDb25uZWN0 aW9uPGJyPg0KJmd0OyBwYXJ0aWFsIGludGVyZmFjZSBSVENQZWVyQ29ubmVjdGlvbiB7PGJyPg0K Jmd0OyAmbmJzcDsvLyBDcmVhdGUgYSBzdHJlYW0gdGhhdCBpcyB1c2VkIHRvIHNlbmQgYSBzb3Vy Y2Ugc3RyZWFtLjxicj4NCiZndDsgJm5ic3A7Ly8gVGhlIE1lZGlhU2VuZFN0cmVhbS5kZXNjcmlw dGlvbiBjYW4gYmUgdXNlZCBmb3Igc2lnbmFsbGluZy48YnI+DQomZ3Q7ICZuYnNwOy8vIE5vIG1l ZGlhIGlzIHNlbnQgdW50aWwgYWRkU3RyZWFtKE1lZGlhU2VuZFN0cmVhbSkgaXMgY2FsbGVkLjxi cj4NCiZndDsgJm5ic3A7TG9jYWxNZWRpYVN0cmVhbSBjcmVhdGVMb2NhbFN0cmVhbShNZWRpYVN0 cmVhbSBzb3VyY2VTdHJlYW0pOzxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOy8vIENyZWF0ZSBh IHN0cmVhbSB0aGF0IGlzIHVzZWQgdG8gcmVjZWl2ZSBtZWRpYSBmcm9tIHRoZSByZW1vdGUgc2lk ZSw8YnI+DQomZ3Q7ICZuYnNwOy8vIGdpdmVuIHRoZSBwYXJhbWV0ZXJzIHNpZ25hbGxlZCBmcm9t IE1lZGFpU2VuZFN0cmVhbS5kZXNjcmlwdGlvbi48YnI+DQomZ3Q7ICZuYnNwO01lZGlhU3RyZWFt IGNyZWF0ZVJlbW90ZVN0cmVhbShNZWRpYVN0cmVhbURlc2NyaXB0aW9uIGRlc2NyaXB0aW9uKTs8 YnI+DQomZ3Q7IH08YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgaW50ZXJmYWNlIExvY2Fs TWVkaWFTdHJlYW0gaW1wbGVtZW50cyBNZWRpYVN0cmVhbSB7PGJyPg0KJmd0OyAmbmJzcDsgLy8g VGhpcyBjYW4gYmUgY2hhbmdlZCBhdCBhbnkgdGltZSwgYnV0IGVzcGVjaWFsbHkgYmVmb3JlIGNh bGxpbmc8YnI+DQomZ3Q7ICZuYnNwOyAvLyBQZWVyQ29ubmVjdGlvbi5hZGRTdHJlYW08YnI+DQom Z3Q7ICZuYnNwOyBhdHRyaWJ1dGUgTWVkaWFTdHJlYW1EZXNjcmlwdGlvbiBkZXNjcmlwdGlvbjs8 YnI+DQomZ3Q7IH08YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLy8gUmVwcmVzZW50cyB0 aGUgcGFyYW1ldGVycyB1c2VkIHRvIGVpdGhlciBzZW5kIG9yIHJlY2VpdmUgYSBzdHJlYW08YnI+ DQomZ3Q7IC8vIG92ZXIgYSBQZWVyQ29ubmVjdGlvbi48YnI+DQomZ3Q7IGRpY3Rpb25hcnkgTWVk aWFTdHJlYW1EZXNjcmlwdGlvbiB7PGJyPg0KJmd0OyAmbmJzcDsgTWVkaWFTdHJlYW1UcmFja0Rl c2NyaXB0aW9uW10gdHJhY2tzOzxicj4NCiZndDsgfTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0OyAvLyBSZXByZXNlbnRzIHRoZSBwYXJhbWV0ZXJzIHVzZWQgdG8gZWl0aGVyIHNlbmQgb3Ig cmVjZWl2ZSBhIHRyYWNrIG92ZXIgLy88YnI+DQomZ3Q7IGEgUGVlckNvbm5lY3Rpb24uICZuYnNw O0EgdHJhY2sgaGFzIG1hbnkgJnF1b3Q7Zmxvd3MmcXVvdDssIHdoaWNoIGNhbiBiZSBncm91cGVk PGJyPg0KJmd0OyAvLyB0b2dldGhlci48YnI+DQomZ3Q7IGRpY3Rpb25hcnkgTWVkaWFTdHJlYW1U cmFja0Rlc2NyaXB0aW9uIHs8YnI+DQomZ3Q7ICZuYnNwOyAvLyBTYW1lIGFzIHRoZSBNZWRpYVN0 cmVhbVRyYWNrLmlkPGJyPg0KJmd0OyAmbmJzcDsgRE9NU3RyaW5nIGlkOzxicj4NCiZndDs8YnI+ DQomZ3Q7ICZuYnNwOyAvLyBTYW1lIGFzIHRoZSBNZWRpYVN0cmVhbVRyYWNrLmtpbmQ8YnI+DQom Z3Q7ICZuYnNwOyBET01TdHJpbmcga2luZDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgLy8g QSB0cmFjayBjYW4gaGF2ZSBtYW55ICZxdW90O2Zsb3dzJnF1b3Q7LCBzdWNoIGFzIGZvciBTaW11 bGNhc3QsIEZFQywgZXRjLjxicj4NCiZndDsgJm5ic3A7IC8vIEFuZCB0aGV5IGNhbiBiZSBncm91 cGVkIGluIGFyYml0cmFyeSB3YXlzLjxicj4NCiZndDsgJm5ic3A7IE1lZGlhRmxvd0Rlc2NyaXB0 aW9uW10gZmxvd3M7PGJyPg0KJmd0OyAmbmJzcDsgTWVkaWFGbG93R3JvdXBbXSBmbG93R3JvdXBz Ozxicj4NCiZndDsgfTxicj4NCiZndDs8YnI+DQomZ3Q7IC8vIFJlcHJlc2VudHMgdGhlIHBhcmFt ZXRlcnMgdXNlZCB0byBlaXRoZXIgc2VuZCBvciByZWNlaXZlIGEgJnF1b3Q7ZmxvdyZxdW90Ozxi cj4NCiZndDsgLy8gb3ZlciBhIFBlZXJDb25uZWN0aW9uLiAmbmJzcDtBICZxdW90O2Zsb3cmcXVv dDsgaXMgYSBtZWRpYSB0aGF0IGFycml2ZXMgd2l0aCBhPGJyPg0KJmd0OyAvLyBzaW5nbGUsIHVu aXF1ZSBTU1JDLiAmbmJzcDtPbmUgdG8gbWFueSBmbG93cyB0b2dldGhlciBtYWtlIHVwIHRoZSBt ZWRpYTxicj4NCiZndDsgLy8gZm9yIGEgdHJhY2suICZuYnNwO0ZvciBleGFtcGxlLCB0aGVyZSBt YXkgYmUgU2ltdWxjYXN0LCBGRUMsIGFuZCBSVFg8YnI+DQomZ3Q7IC8vIGZsb3dzLjxicj4NCiZn dDsgZGljdGlvbmF5IE1lZGlhRmxvd0Rlc2NyaXB0aW9uIHs8YnI+DQomZ3Q7ICZuYnNwOyAvLyBU aGUgJnF1b3Q7ZmxvdyBpZCZxdW90OyBtdXN0IGJlIHVuaXF1ZSB0byB0aGUgdHJhY2ssIGJ1dCBu ZWVkIG5vdCBiZSB1bmlxdWU8YnI+DQomZ3Q7ICZuYnNwOyAvLyBvdXRzaWRlIG9mIHRoZSB0cmFj ayAodHdvIHRyYWNrcyBjb3VsZCBib3RoIGhhdmUgYSBmbG93IHdpdGggdGhlPGJyPg0KJmd0OyAm bmJzcDsgLy8gc2FtZSBmbG93IElEKS48YnI+DQomZ3Q7ICZuYnNwOyBET01TdHJpbmcgaWQ7PGJy Pg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7IC8vIEVhY2ggZmxvdyBjYW4gZ28gb3ZlciBpdHMgb3du IHRyYW5zcG9ydC4gJm5ic3A7SWYgdGhlIEpTIHNldHMgdGhpcyB0byBhPGJyPg0KJmd0OyAmbmJz cDsgLy8gdHJhbnNwb3J0SWQgdGhhdCBkb2Vzbid0IGhhdmUgYSB0cmFuc3BvcnQgc2V0dXAgYWxy ZWFkeSwgdGhlPGJyPg0KJmd0OyAmbmJzcDsgLy8gYnJvd3NlciB3aWxsIHVzZSBTRFAgbmVnb3Rp YXRpb24gdG8gc2V0dXAgYSB0cmFuc3BvcnQgdG8gYmFjayB0aGF0PGJyPg0KJmd0OyAmbmJzcDsg Ly8gdHJhbnNwb3J0SWQuICZuYnNwO0lmIFRoaXMgaXMgc2V0IHRvIGFuIE1JRCBpbiB0aGUgU0RQ LCB0aGVuIHRoYXQgTUlEJ3M8YnI+DQomZ3Q7ICZuYnNwOyAvLyB0cmFuc3BvcnQgaXMgdXNlZC48 YnI+DQomZ3Q7ICZuYnNwOyBET01TdHJpbmcgdHJhbnNwb3J0SWQ7PGJyPg0KJmd0Ozxicj4NCiZn dDsgJm5ic3A7IC8vIFRoZSBTU1JDIHVzZWQgdG8gc2VuZCB0aGUgZmxvdy48YnI+DQomZ3Q7ICZu YnNwOyB1bnNpZ25lZCBpbnQgc3NyYzs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgLy8gV2hl biB1c2VkIGFzIHJlY2VpdmUgcGFyYW1ldGVycywgdGhpcyBpbmRpY2F0ZXMgdGhlIHBvc3NpYmxl IGxpc3Q8YnI+DQomZ3Q7ICZuYnNwOyAvLyBvZiBjb2RlY3MgdGhhdCBtaWdodCBjb21lIGluIGZv ciB0aGlzIGZsb3cuICZuYnNwO0ZvciBleG1hbXBsZSwgYSBnaXZlbjxicj4NCiZndDsgJm5ic3A7 IC8vIHJlY2VpdmUgZmxvdyBjb3VsZCBiZSBzZXR1cCB0byByZWNlaXZlIGFueSBvZiBPUFVTLCBJ U0FDLCBvciBQQ01VLjxicj4NCiZndDsgJm5ic3A7IC8vIFdoZW4gdXNlZCBhcyBzZW5kIHBhcmFt ZXRlcnMsIHRoaXMgaW5kaWNhdGVzIHRoYXQgdGhlIGZpcnN0IGNvZGVjPGJyPg0KJmd0OyAmbmJz cDsgLy8gc2hvdWxkIGJlIHVzZWQsIGJ1dCB0aGUgYnJvd3NlciBjYW4gdXNlIHNlbmQgb3RoZXIg Y29kZWNzIGlmIGl0PGJyPg0KJmd0OyAmbmJzcDsgLy8gbmVlZHMgdG8gYmVjYXVzZSBvZiBlaXRo ZXIgYmFuZHdpZHRoIG9yIENQVSBjb25zdHJhaW50cy48YnI+DQomZ3Q7ICZuYnNwOyBNZWRpYUNv ZGVjRGVzY3JpcHRpb25bXSBjb2RlY3M7PGJyPg0KJmd0OyB9PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IGRpY3Rpb25hcnkgTWVkaWFGbG93R3JvdXAgezxicj4NCiZndDsgJm5ic3A7IERP TVN0cmluZyB0eXBlOyAmbmJzcDsvLyAmcXVvdDtTSU0mcXVvdDsgZm9yIFNpbXVsY2FzdCwgJnF1 b3Q7RkVDJnF1b3Q7IGZvciBGRUMsIGV0Yzxicj4NCiZndDsgJm5ic3A7IERPTVN0cmluZ1tdIGZs b3dpZHM7PGJyPg0KJmd0OyB9PGJyPg0KJmd0Ozxicj4NCiZndDsgZGljdGlvbmFyeSBNZWRpYUNv ZGVjRGVzY3JpcHRpb24gezxicj4NCiZndDsgJm5ic3A7IHVuc2lnbmVkIGJ5dGUgcGF5bG9hZFR5 cGU7PGJyPg0KJmd0OyAmbmJzcDsgRE9NU3RyaW5nIG5hbWU7PGJyPg0KJmd0OyAmbmJzcDsgdW5z aWduZWQgaW50PyBjbG9ja1JhdGU7PGJyPg0KJmd0OyAmbmJzcDsgdW5zaWduZWQgaW50PyBiaXRS YXRlOzxicj4NCiZndDsgJm5ic3A7IC8vIEEgZ3JhYiBiYWcgb2Ygb3RoZXIgZm10cCB0aGF0IHdp bGwgbmVlZCB0byBiZSBmdXJ0aGVyIGRlZmluZWQuPGJyPg0KJmd0OyAmbmJzcDsgTWVkaWFDb2Rl Y1BhcmFtW10gcGFyYW1zOzxicj4NCiZndDsgfTxicj4NCiZndDs8YnI+DQomZ3Q7IGRpY3Rpb25h cnkgTWVkaWFDb2RlY1BhcmFtIHs8YnI+DQomZ3Q7ICZuYnNwOyBET01TdHJpbmcga2V5Ozxicj4N CiZndDsgJm5ic3A7IERPTVN0cmluZyB2YWx1ZTs8YnI+DQomZ3Q7IH08YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDsgTm90ZXM6PGJyPg0KJmd0Ozxicj4NCiZndDsgLSBXaGVuIExvY2FsTWVk aWFTdHJlYW1zIGFyZSBhZGRlZCB1c2luZyBhZGRTdHJlYW0sIG9ubmVnb3RpYXRlZG5lZWRlZCBp czxicj4NCiZndDsgbm90IGNhbGxlZCwgYW5kIHRob3NlIHN0cmVhbXMgYXJlIG5ldmVyIHJlZmxl Y3RlZCBpbiBmdXR1cmUgU0RQIGV4Y2hhbmdlcy48YnI+DQomZ3Q7IEluZGVlZCwgaXQgd291bGQg YmUgaW1wb3NzaWJsZSB0byBwdXQgdGhlbSBpbiB0aGUgU0RQIHdpdGhvdXQgZmlyc3Q8YnI+DQom Z3Q7IHJlc29sdmluZyBpZiB0aGF0IHdvdWxkIGJlIFBsYW4gQSBTRFAgb3IgUGxhbiBCIFNEUC48 YnI+DQomZ3Q7PGJyPg0KJmd0OyAtIEp1c3QgbGlrZSBwaWxlcyBvZiBhdHRyaWJ1dGVzIHdvdWxk IG5lZWQgdG8gYmUgZGVmaW5lZCBmb3IgUGxhbiBBIGFuZCBmb3I8YnI+DQomZ3Q7IFBsYW4gQiwg c2ltaWxhciBhdHRyaWJ1dGVzIHdvdWxkIG5lZWQgdG8gYmUgZGVmaW5lZCBoZXJlIChMdWNraWx5 LCAmbmJzcDttdWNoPGJyPg0KJmd0OyB3b3JrIGhhcyBhbHJlYWR5IGJlZW4gZG9uZSBmaWd1cmlu ZyBvdXQgd2hhdCB0aG9zZSBwYXJhbWV0ZXJzIGFyZSA6KS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsgUHJvczo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtIEVpdGhlciBQbGFuIEEgb3IgUGxh biBCIG9yIGNvdWxkIGJlIGltcGxlbWVudGVkIGluIEphdmFzY3JpcHQgdXNpbmcgdGhpczxicj4N CiZndDsgQVBJPGJyPg0KJmd0OyAtIEl0IGV4cG9zZXMgYWxsIHRoZSBzYW1lIGZ1bmN0aW9uYWxp dHkgdG8gdGhlIEphdmFzY3JpcHQgYXMgU0RQLCBidXQgaW4gYTxicj4NCiZndDsgbXVjaCBuaWNl ciBmb3JtYXQgdGhhdCBpcyBtdWNoIGVhc2llciB0byB3b3JrIHdpdGguPGJyPg0KJmd0OyAtIEFu eSBvdGhlciBzaWduYWxsaW5nIG1lY2hhbmlzbSwgc3VjaCBhcyBKaW5nbGUgb3IgQ0xVRSBjb3Vs ZCBiZTxicj4NCiZndDsgaW1wbGVtZW50ZWQgdXNpbmcgdGhpcyBBUEkuPGJyPg0KJmd0OyAtIFRo ZXJlIGlzIGFsbW9zdCBubyByaXNrIG9mIHNpZ25hbGxpbmcgZ2xhcmUuPGJyPg0KJmd0OyAtIERl YnVnZ2luZyBlcnJvcnMgd2l0aCBtaXNjb25maWd1cmVkIGRlc2NyaXB0aW9ucyBzaG91bGQgYmUg bXVjaCBlYXNpZXI8YnI+DQomZ3Q7IHdpdGggdGhpcyB0aGFuIHdpdGggbGFyZ2UgU0RQIGJsb2Jz Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBDb25zOjxicj4NCiZndDs8YnI+DQomZ3Q7 IC0gTm93IHRoZXJlIGFyZSB0d28gc2xpZ2h0bHkgZGlmZmVyZW50IHdheXMgdG8gYWRkIHN0cmVh bXM6IGJ5IGNyZWF0aW5nIGE8YnI+DQomZ3Q7IExvY2FsTWVkaWFTdHJlYW0gZmlyc3QsIGFuZCBu b3QuICZuYnNwO1RoaXMgaXMsIGhvd2V2ZXIsIGFuYWxvZ291cyB0byBzZXR0aW5nPGJyPg0KJmd0 OyAmcXVvdDtuZWdvdGlhdGVkOiB0cnVlJnF1b3Q7IGluIGNyZWF0ZURhdGFDaGFubmVsLiAmbmJz cDtPbiB3YXkgaXMgJnF1b3Q7SnVzdCBXb3JrJnF1b3Q7LCBhbmQgdGhlPGJyPg0KJmd0OyBvdGhl ciBpcyBtb3JlIGFkdmFuY2VkIGNvbnRyb2wuPGJyPg0KJmd0Ozxicj4NCiZndDsgLSBBbGwgdGhl IG9wdGlvbnMgaW4gTWVkaWFDb2RlY0Rlc2NyaXB0aW9uIGFyZSBhIGJpdCBjb21wbGljYXRlZC4g Jm5ic3A7UmVhbGx5LDxicj4NCiZndDsgdGhpcyBpcyBvbmx5IG5lY2Vzc2FyeSBiZWNhdXNlIFBs YW4gQSByZXF1aXJlcyBiZWluZyBhYmxlIHRvIHNwZWNpZnkgY29kZWM8YnI+DQomZ3Q7IHBhcmFt ZXRlcnMgcGVyIFNTUkMsIGFuZCBzZXQgZWFjaCBmbG93IG9uIGRpZmZlcmVudCB0cmFuc3BvcnRz LiAmbmJzcDtJZiB3ZSBkaWQ8YnI+DQomZ3Q7IG5vdCBoYXZlIHRoaXMgcmVxdWlyZW1lbnQsIHdl IGNvdWxkIHNpbXBsaWZ5Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBFeGFtcGxlIFVz YWdlOjxicj4NCiZndDs8YnI+DQomZ3Q7IC8vIEltYWdpbmUgSSBoYXZlIE15QXBwLCBoYW5kbGVz IGNyZWF0aW5nIGEgUGVlckNvbm5lY3Rpb24sPGJyPg0KJmd0OyAvLyBzaWduYWxsaW5nLCBhbmQg cmVuZGVyaW5nIHN0cmVhbXMuICZuYnNwO1RoaXMgaXMgaG93IHRoZSBuZXcgQVBJIGNvdWxkIGJl PGJyPg0KJmd0OyAvLyB1c2VkLjxicj4NCiZndDsgdmFyIHBlZXJDb25uZWN0aW9uID0gTXlBcHAu Y3JlYXRlUGVlckNvbm5lY3Rpb24oKTs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAvLyBPbiBzZW5kZXIg c2lkZTo8YnI+DQomZ3Q7IHZhciBzdHJlYW0gPSBNeUFwcC5nZXRNZWRpYVN0cmVhbSgpOzxicj4N CiZndDsgdmFyIGxvY2FsU3RyZWFtID0gcGVlckNvbm5lY3Rpb24uY3JlYXRlU2VuZFN0cmVhbShz dHJlYW0pOzxicj4NCiZndDsgc2VuZFN0cmVhbS5kZXNjcmlwdGlvbiA9IE15QXBwLm1vZGlmeVN0 cmVhbShsb2NhbFN0cmVhbS5kZXNjcmlwdGlvbik8YnI+DQomZ3Q7IE15QXBwLnNpZ25hbEFkZFN0 cmVhbShsb2NhbFN0cmVhbS5kZXNjcmlwdGlvbiwgZnVuY3Rpb24ocmVzcG9uc2UpKSB7PGJyPg0K Jmd0OyAmbmJzcDsgaWYgKCFyZXNwb25zZS5yZWplY3RlZCkgezxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyAvLyBNZWRpYSB3aWxsIG5vdCBiZSBzZW50Ljxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBw ZWVyQ29ubmVjdGlvbi5hZGRTdHJlYW0obG9jYWxTdHJlYW0pOzxicj4NCiZndDsgJm5ic3A7IH08 YnI+DQomZ3Q7IH08YnI+DQomZ3Q7PGJyPg0KJmd0OyAvLyBPbiByZWNlaXZlciBzaWRlOjxicj4N CiZndDsgTXlBcHAub25BZGRTdHJlYW1TaWduYWxsZWQgPSBmdW5jdGlvbihzdHJlYW1EZXNjcmlw dGlvbikgezxicj4NCiZndDsgJm5ic3A7IHZhciBzdHJlYW0gPSBwZWVyQ29ubmVjdGlvbi5jcmVh dGVSZWNlaXZlU3RyZWFtKHN0cmVhbURlc2NyaXB0aW9uKTs8YnI+DQomZ3Q7ICZuYnNwOyBNeUFw cC5yZW5kZXJTdHJlYW0oc3RyZWFtKTs8YnI+DQomZ3Q7IH08YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsgLy8gSW4gdGhpcyBleGNoYW5nZSwgdGhlIE1lZGlhU3RyZWFtRGVzY3JpcHRpb24g c2lnbmFsbGVkIGZyb20gdGhlPGJyPg0KJmd0OyAvLyBzZW5kZXIgdG8gdGhlIHJlY2VpdmVyIG1h eSBoYXZlIGxvb2tlZCBzb21ldGhpbmcgbGlrZSB0aGlzOjxicj4NCiZndDs8YnI+DQomZ3Q7IHs8 YnI+DQomZ3Q7ICZuYnNwOyB0cmFja3M6IFs8YnI+DQomZ3Q7ICZuYnNwOyB7PGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7IGlkOiAmcXVvdDthdWRpbzEmcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7IGtpbmQ6ICZxdW90O2F1ZGlvJnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBmbG93 czogWzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBpZDogJnF1b3Q7bWFpbiZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHRyYW5zcG9ydElkOiAmcXVvdDt0cmFuc3BvcnQxJnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgc3NyYzogMTExMSw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNv ZGVjczogWzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgezxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHBheWxvYWRUeXBlOiAxMTEsPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgbmFtZTogJnF1b3Q7b3B1cyZxdW90Oyw8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvLyAuLi4gbW9yZSBjb2RlYyBkZXRhaWxzPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB9LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgezxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHBheWxvYWRUeXBlOiAx MTIsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbmFtZTogJnF1b3Q7cGNt dSZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvLyAuLi4gbW9y ZSBjb2RlYyBkZXRhaWxzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB9XTxicj4NCiZn dDsgJm5ic3A7ICZuYnNwO31dPGJyPg0KJmd0OyAmbmJzcDt9LDxicj4NCiZndDsgJm5ic3A7ezxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyBpZDogJnF1b3Q7dmlkZW8xJnF1b3Q7LDxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyBraW5kOiAmcXVvdDt2aWRlbyZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgZmxvd3M6IFs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgezxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgaWQ6ICZxdW90O3NpbTAmcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB0cmFuc3BvcnRJZDogJnF1b3Q7dHJhbnNwb3J0MiZxdW90Oyw8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNzcmM6IDIyMjIsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBjb2RlY3M6IFs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHs8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwYXlsb2FkVHlwZTogMTIyLDxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG5hbWU6ICZxdW90O3ZwOCZxdW90Ozxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC8vIC4uLiBtb3JlIGNvZGVjIGRldGFp bHM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH1dPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7fSw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwO2lkOiAmcXVvdDtzaW0xJnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0 cmFuc3BvcnRJZDogJnF1b3Q7dHJhbnNwb3J0MiZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7c3NyYzogMjIyMyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29kZWNz OiBbPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3s8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3BheWxvYWRUeXBlOiAxMjIsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtuYW1lOiAmcXVvdDt2cDgmcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsvLyAuLi4gbW9yZSBjb2RlYyBkZXRhaWxzPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwO31dPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7fSw8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDt7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lkOiAmcXVvdDtzaW0y JnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0cmFuc3BvcnRJZDogJnF1b3Q7 dHJhbnNwb3J0MiZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3NyYzogMjIy NCw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29kZWNzOiBbPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwO3s8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Bh eWxvYWRUeXBlOiAxMjIsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtuYW1l OiAmcXVvdDt2cDgmcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsv LyAuLi4gbW9yZSBjb2RlYyBkZXRhaWxzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO31d PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7fSw8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ezxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpZDogJnF1b3Q7c2ltMGZlYyZxdW90 Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHJhbnNwb3J0SWQ6ICZxdW90O3RyYW5z cG9ydDImcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NzcmM6IDIyMjUsPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvZGVjczogWzxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYXlsb2Fk VHlwZTogMTIyLDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bmFtZTogJnF1 b3Q7dnA4JnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ly8gLi4u PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO31dPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 fV0sPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Zmxvd0dyb3VwczogWzxicj4NCiZndDsgJm5ic3A7 ICZuYnNwO3s8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VtYW50aWNzOiAmcXVvdDtT SU0mcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NzcmNzOiBbMjIyMiwgMjIy MywgMjIyNF08YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt9LDxicj4NCiZndDsgJm5ic3A7ICZuYnNw O3s8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VtYW50aWNzOiAmcXVvdDtGRUMmcXVv dDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NzcmNzOiBbMjIyMiwgMjIyNV08YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDt9XTxicj4NCiZndDsgJm5ic3A7fV08YnI+DQomZ3Q7IH08YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQ29uc3RydWN0aXZlIGZlZWRiYWNrIGlzIHdlbGNv bWUgOikuPGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgcnRjd2ViIG1haWxpbmcgbGlzdDxicj4N CiZndDsgPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0 Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C5986TK5EX14MBXC273r_-- From matthew.kaufman@skype.net Mon Jun 17 18:38:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0812321F9DB4 for ; Mon, 17 Jun 2013 18:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBOTCrcGaQKj for ; Mon, 17 Jun 2013 18:38:08 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id DA0CE21F9CD5 for ; Mon, 17 Jun 2013 18:38:08 -0700 (PDT) Received: from BY2FFO11FD009.protection.gbl (10.1.15.202) by BY2FFO11HUB002.protection.gbl (10.1.14.144) with Microsoft SMTP Server (TLS) id 15.0.707.0; Tue, 18 Jun 2013 01:38:05 +0000 Received: from TK5EX14HUBC105.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.707.0 via Frontend Transport; Tue, 18 Jun 2013 01:38:04 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.171]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0136.001; Tue, 18 Jun 2013 01:37:59 +0000 From: "Matthew Kaufman (SKYPE)" To: Peter Thatcher , Martin Thomson Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) Thread-Index: AQHOa1pL3f2CtN2bTEydXd59L0Jyj5k6QmQAgAAH7oCAAGd8kA== Date: Tue, 18 Jun 2013 01:37:58 +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.75] Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C59AETK5EX14MBXC273r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(43544003)(24454002)(51704005)(377454002)(199002)(52034003)(189002)(74706001)(51856001)(66066001)(33656001)(20776003)(49866001)(55846006)(69226001)(77982001)(74366001)(15202345002)(71186001)(81542001)(16236675002)(76786001)(16406001)(44976003)(77096001)(65816001)(561944002)(63696002)(74876001)(56776001)(53806001)(6806003)(31966008)(76796001)(81342001)(76482001)(74502001)(47446002)(512874002)(79102001)(50986001)(80022001)(74662001)(47976001)(54356001)(46102001)(4396001)(54316002)(59766001)(56816003)(47736001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB002; H:TK5EX14HUBC105.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0881A7A935 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 01:38:14 -0000 --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C59AETK5EX14MBXC273r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90ZSB0aGF0IOKAnGFsbCBvciBub3RoaW5n4oCdIGRvZXNu4oCZdCBtZWFuIOKAnHRha2UgaXQg b3IgbGVhdmUgaXQgd2l0aCByZWdhcmQgdG8gdGhlIGZ1bGwgQ1UtUlRDV0VCIHByb3Bvc2FsIGZy b20gTWljcm9zb2Z04oCdLiBJdCBtZWFucyDigJxrZWVwIFNEUCBvZmZlci9hbnN3ZXIgYW5kIHRo ZSBiaWcgYmxvYiBvZiB0ZXh0IGFuZCBhbGwgdGhhdOKAnSBvciDigJxzdGFydCB3aXRoIHRoZSBD VS1SVENXRUIgcHJvcG9zYWwgYXMgYSBiYXNlIGFuZCB1c2UgY29tbXVuaXR5IGlucHV0IGFuZCBj b25zZW5zdXMgdG8gbWFrZSBpdCBpbnRvIHNvbWV0aGluZyBldmVuIGJldHRlcuKAnS4NCg0KTWF0 dGhldyBLYXVmbWFuDQoNCkZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRj d2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQZXRlciBUaGF0Y2hlcg0KU2VudDog TW9uZGF5LCBKdW5lIDE3LCAyMDEzIDEyOjI2IFBNDQpUbzogTWFydGluIFRob21zb24NCkNjOiA8 cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFByb3Bvc2FsIGZvciBhIEpT IEFQSSBmb3IgTm9QbGFuIChhZGRpbmcgbXVsdGlwbGUgc291cmNlcyB3aXRob3V0IGVuY29kaW5n IHRoZW0gaW4gU0RQKQ0KDQpZZXMsIEkgd2FzIGV4cGVjdGluZyB5b3UgdG8gYmUgbW9yZSBzdXBw b3J0aXZlLiAgSSdtIHN1cnByaXNlZCBvdXQgaG93IHlvdXIgd2FudCAiYWxsIG9yIG5vdGhpbmci LiAgSSdtIGFmcmFpZCBpZiBvdXIgb3B0aW9ucyBmb3IgYSBjbGVhbiBBUEkgYXJlIGFsbCBvciBu b3RoaW5nLCB3ZSdsbCBqdXN0IGVuZCB1cCB3aXRoIG5vdGhpbmcuICBJJ2QgcHJlZmVyIHRvIHRy eSBpbmNyZW1lbnRhbCBpbXByb3ZlbWVudHMgdG8gd29yZCB0b3dhcmQgKGV2ZW50dWFsbHkpIGEg Y2xlYW4gQVBJLg0KDQpEbyB5b3UgdGhpbmsgaXQgaXMgaW1wb3NzaWJsZSB0byB3b3JrIHRvd2Fy ZCBhIGNsZWFuIEFQSSBpbiBhbiBpbmNyZW1lbnRhbCBhcHByb2FjaD8gIElmIHlvdSB0aGluayBp dCdzIHBvc3NpYmxlLCBJJ2QgbGlrZSB0byBoZWFyIHlvdXIgdGhvdWdodHMgb24gaG93Lg0KDQoN CkJ5IHRoZSB3YXksIHRoZXNlIEFQSSBhZGRpdGlvbnMgd291bGQgZ3JlYXRseSBtaW5pbWl6ZSB0 aGUgYW1vdW50IG9mIFNEUCBlZGl0aW5nIG5lY2Vzc2FyeSBmb3IgSlMgY2xpZW50cyB0aGF0IGRv bid0IHVzZSBTRFAgZm9yIHNpZ25hbGxpbmcuICBBbmQgbGF0ZXIgaW5jcmVtZW50YWwgaW1wcm92 ZW1lbnRzIGNvdWxkIHJlZHVjZSBpdCBmdXJ0aGVyLiAgQWxzbywgaXQncyBubyBsb25nZXIgbmVj ZXNzYXJ5IHRvIGRvIG9mZmVyL2Fuc3dlciBmb3IgYWRkaW5nIHRyYWNrcy4gIEl0J3Mgb25seSB0 aGUgaW50aWFsIFBlZXJDb25uZWN0aW9uIHNldHVwIHRoYXQgbmVlZHMgdG8gZG8gT2ZmZXIvQW5z d2VyLiAgU28sIGl0IGRvZXNuJ3QgaW5oZXJpdCBhbGwgdGhlIHByb2JsZW1zIHF1aXRlIGFzIG11 Y2ggYXMgeW91IGRlc2NyaWJlZC4gIEl0IG1heSBiZSBzbGlnaHRseSBhYm9taW5hYmxlLCBidXQg SSBjZXJ0YWlubHkgY29uc2lkZXIgaXQgbGVzcyBhYm9taW5hYmxlIHRoYW4gdGhlIFNEUCBlZGl0 aW5nIG5lY2Vzc2FyeSB3aXRob3V0IGl0Lg0KDQpPbiBNb24sIEp1biAxNywgMjAxMyBhdCAxMTo1 NyBBTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFy dGluLnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpNYXliZSB5b3UnZCBleHBlY3QgbWUgdG8g YmUgbW9yZSBzdXBwb3J0aXZlIG9mIHNvbWV0aGluZyB0aGF0IGxvb2tlZA0Kc28gbXVjaCBsaWtl IENVLVJUQy1XZWIuICBJdCBpbmhlcml0cyBhbGwgdGhlIHdvcnN0IHByb3BlcnRpZXMgb2YgSlNF UA0KKE9mZmVyL0Fuc3dlciwgU0RQIGVkaXRpbmcpIHdpdGggYSBwYXJ0aWFsIGltcGxlbWVudGF0 aW9uIG9mIGEgY2xlYW4NCkFQSS4NCg0KSXQncyBjb21tZW50IDIyLWxpdGUuICBJdCdzIGFuIGFi b21pbmF0aW9uLiAgSWYgeW91IGFyZSBnb2luZyB0byBkbw0KdGhpcywgZG8gaXQgcHJvcGVybHku DQoNCk9uIDE3IEp1bmUgMjAxMyAwNTo1NywgUGV0ZXIgVGhhdGNoZXIgPHB0aGF0Y2hlckBnb29n bGUuY29tPG1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KPiBHb29nbGUgaXMg aW4gZnVsbCBzdXBwb3J0IG9mICJQbGFuIEIiIGZvciBlbmNvZGluZyBtdWx0aXBsZSBtZWRpYSBz b3VyY2VzIGluDQo+IFNEUCwgYW5kIHdvdWxkIGxpa2UgdG8gc2VlIHRoZSBQbGFuIEEgdnMuIFBs YW4gQiBkZWNpc2lvbiByZXNvbHZlZCBzb29uLg0KPiBSZWNlbnRseSwgdGhvdWdoLCBhIHRoaXJk IG9wdGlvbiwgY2FsbGVkICJOb1BsYW4iIGhhcyBiZWVuIHByb3Bvc2VkLCBidXQgaXQNCj4gbGFj a2VkIHRoZSBkZXRhaWxzIG9mIHdoYXQgYSBKUyBBUEkgd291bGQgbG9vayBsaWtlIGZvciBOb1Bs YW4uICBDdWxsZW4NCj4gYXNrZWQgdG8gc2VlIHN1Y2ggYW4gQVBJIHByb3Bvc2FsLCBhbmQgc28g SSBoYXZlIHdvcmtlZCB3aXRoIEVtaWwgdG8gbWFrZQ0KPiBvbmUuICBIZSB3aWxsIGJlIGFkZGlu ZyBpdCB0byB0aGUgTm9QbGFuIGRyYWZ0LCBidXQgSSB3aWxsIGFsc28gaW5jbHVkZSBpdA0KPiBp biB0aGlzIGVtYWlsLg0KPg0KPiBBZ2FpbiwgR29vZ2xlIGlzIGluIGZ1bGwgc3VwcG9ydCBvZiAi UGxhbiBCIi4gIEJ1dCBpZiBQbGFuIEEgdnMuIFBsYW4gQg0KPiBjYW5ub3QgYmUgZGVjaWRlZCwg dGhlbiB3ZSBzdXBwb3J0IE5vUGxhbiB3aXRoIHRoZSBmb2xsb3dpbmcgYWRkaXRpb25zIHRvDQo+ IHRoZSBXZWJSVEMgSlMgQVBJIGFzIGFuIG9wdGlvbiB0aGF0IGFsbG93cyBpbXBsZW1lbnRpbmcg ZWl0aGVyIFBsYW4gQSBvcg0KPiBQbGFuIEIgIGluIEphdmFzY3JpcHQuICBBbmQgZXZlbiBpZiBQ bGFuIEEgdnMuIFBsYW4gQiBpcyByZXNvbHZlZCwgdGhlc2UgQVBJDQo+IGFkZGl0aW9ucyB3b3Vs ZCBzdGlsbCBiZSBhIGJpZyBpbXByb3ZlbWVudCBmb3IgdGhvc2UgV2ViUlRDIGFwcGxpY2F0aW9u cw0KPiB0aGF0IGRvbid0IHVzZSBTRFAgZm9yIHNpZ25hbGxpbmcuDQo+DQo+IEl0IGlzIGEgYml0 IGxvbmcgYmVjYXVzZSBJIGhhdmUgYWRkZWQgbWFueSBjb21tZW50cyBhbmQgZXhhbXBsZXMsIGJ1 dCB0aGUNCj4gYWN0dWFsbHkgYWRkaXRpb25zIG9ubHkgaW5jbHVkZSB0d28gbmV3IG1ldGhvZHMg b24gUGVlckNvbm5lY3Rpb24gYW5kIGEgZmV3DQo+IG5ldyBkaWN0aW9uYXJpZXMuICBTbyBkb24n dCBiZSBvdmVyd2hlbG1lZCA6KS4NCj4NCj4NCj4NCj4gSW50cm86IFRoaXMgZm9sbG93cyB0aGUg bW9kZWwgb2YgY3JlYXRlRGF0YUNoYW5uZWwsIHdoaWNoIGhhcyBhIEpTIG1ldGhvZCBvbg0KPiBQ ZWVyQ29ubmVjdGlvbiB0aGF0IG1ha2VzIGl0IHBvc3NpYmxlIHRvIGFkZCBkYXRhIGNoYW5uZWxz IHdpdGhvdXQgZ29pbmcNCj4gdGhyb3VnaCBTRFAuICBGdXJ0aGVybW9yZSwganVzdCBsaWtlIGNy ZWF0ZURhdGFDaGFubmVsIGFsbG93cyAyIHdheXMgdG8NCj4gaGFuZGxlIG5lb2dpdGF0aW9uICh0 aGUgIkkga25vdyB3aGF0IEknbSBkb2luZzsgIEhlcmUncyB3aGF0IEkgd2FudCB0byBzZW5kOw0K PiBMZXQgbWUgc2lnbmFsIGV2ZXJ5dGhpbmciIG1vZGUgYW5kIHRoZSAicGxlYXNlIHRha2UgY2Fy ZSBvZiBpdCBmb3IgbWU7ICBzZW5kDQo+IGFuIE9QRU4gbWVzc2FnZSIgbW9kZSksIHRoaXMgYWxz byBoYXMgMiB3YXlzIHRvIGhhbmRsZSBuZWdvdGlhdGlvbiAodGhlICJJDQo+IGtub3cgd2hhdCBJ J20gZG9pbmc7IEhlcmUncyB3aGF0IEkgd2FudCB0byBzZW5kOyBMZXQgbWUgc2lnbmFsIGV2ZXJ5 dGhpbmciDQo+IG1vZGUgYW5kIHRoZSAicGxlYXNlIHRha2UgY2FyZSBvZiBpdCBmb3IgbWU7ICBz ZW5kIFNEUCBiYWNrIGFuZCBmb3J0aCINCj4gbW9kZSkuDQo+DQo+IEZvbGxvd2luZyB0aGUgc3Vj Y2VzcyBvZiBjcmVhdGVEYXRhQ2hhbm5lbCwgdGhpcyBhbGxvd3Mgc2ltcGxlIGFwcGxpY2F0aW9u cw0KPiB0byBKdXN0IFdvcmsgYW5kIG1vcmUgYWR2YW5jZWQgYXBwbGljYXRpb25zIHRvIGVhc2ls eSBjb250cm9sIHdoYXQgdGhleSBuZWVkDQo+IHRvLiAgSW4gcGFydGljdWxhciwgaXQncyBwb3Nz aWJsZSB0byB1c2UgdGhpcyBBUEkgdG8gaW1wbGVtZW50IGVpdGhlciBQbGFuIEENCj4gb3IgUGxh biBCLg0KPg0KPiAvLyBUaGUgZm9sbG93aW5nIHR3byBtZXRob2QgYXJlIGFkZGVkIHRvIFJUQ1Bl ZXJDb25uZWN0aW9uDQo+IHBhcnRpYWwgaW50ZXJmYWNlIFJUQ1BlZXJDb25uZWN0aW9uIHsNCj4g IC8vIENyZWF0ZSBhIHN0cmVhbSB0aGF0IGlzIHVzZWQgdG8gc2VuZCBhIHNvdXJjZSBzdHJlYW0u DQo+ICAvLyBUaGUgTWVkaWFTZW5kU3RyZWFtLmRlc2NyaXB0aW9uIGNhbiBiZSB1c2VkIGZvciBz aWduYWxsaW5nLg0KPiAgLy8gTm8gbWVkaWEgaXMgc2VudCB1bnRpbCBhZGRTdHJlYW0oTWVkaWFT ZW5kU3RyZWFtKSBpcyBjYWxsZWQuDQo+ICBMb2NhbE1lZGlhU3RyZWFtIGNyZWF0ZUxvY2FsU3Ry ZWFtKE1lZGlhU3RyZWFtIHNvdXJjZVN0cmVhbSk7DQo+DQo+ICAvLyBDcmVhdGUgYSBzdHJlYW0g dGhhdCBpcyB1c2VkIHRvIHJlY2VpdmUgbWVkaWEgZnJvbSB0aGUgcmVtb3RlIHNpZGUsDQo+ICAv LyBnaXZlbiB0aGUgcGFyYW1ldGVycyBzaWduYWxsZWQgZnJvbSBNZWRhaVNlbmRTdHJlYW0uZGVz Y3JpcHRpb24uDQo+ICBNZWRpYVN0cmVhbSBjcmVhdGVSZW1vdGVTdHJlYW0oTWVkaWFTdHJlYW1E ZXNjcmlwdGlvbiBkZXNjcmlwdGlvbik7DQo+IH0NCj4NCj4NCj4gaW50ZXJmYWNlIExvY2FsTWVk aWFTdHJlYW0gaW1wbGVtZW50cyBNZWRpYVN0cmVhbSB7DQo+ICAgLy8gVGhpcyBjYW4gYmUgY2hh bmdlZCBhdCBhbnkgdGltZSwgYnV0IGVzcGVjaWFsbHkgYmVmb3JlIGNhbGxpbmcNCj4gICAvLyBQ ZWVyQ29ubmVjdGlvbi5hZGRTdHJlYW0NCj4gICBhdHRyaWJ1dGUgTWVkaWFTdHJlYW1EZXNjcmlw dGlvbiBkZXNjcmlwdGlvbjsNCj4gfQ0KPg0KPg0KPiAvLyBSZXByZXNlbnRzIHRoZSBwYXJhbWV0 ZXJzIHVzZWQgdG8gZWl0aGVyIHNlbmQgb3IgcmVjZWl2ZSBhIHN0cmVhbQ0KPiAvLyBvdmVyIGEg UGVlckNvbm5lY3Rpb24uDQo+IGRpY3Rpb25hcnkgTWVkaWFTdHJlYW1EZXNjcmlwdGlvbiB7DQo+ ICAgTWVkaWFTdHJlYW1UcmFja0Rlc2NyaXB0aW9uW10gdHJhY2tzOw0KPiB9DQo+DQo+DQo+IC8v IFJlcHJlc2VudHMgdGhlIHBhcmFtZXRlcnMgdXNlZCB0byBlaXRoZXIgc2VuZCBvciByZWNlaXZl IGEgdHJhY2sgb3ZlciAvLw0KPiBhIFBlZXJDb25uZWN0aW9uLiAgQSB0cmFjayBoYXMgbWFueSAi Zmxvd3MiLCB3aGljaCBjYW4gYmUgZ3JvdXBlZA0KPiAvLyB0b2dldGhlci4NCj4gZGljdGlvbmFy eSBNZWRpYVN0cmVhbVRyYWNrRGVzY3JpcHRpb24gew0KPiAgIC8vIFNhbWUgYXMgdGhlIE1lZGlh U3RyZWFtVHJhY2suaWQNCj4gICBET01TdHJpbmcgaWQ7DQo+DQo+ICAgLy8gU2FtZSBhcyB0aGUg TWVkaWFTdHJlYW1UcmFjay5raW5kDQo+ICAgRE9NU3RyaW5nIGtpbmQ7DQo+DQo+ICAgLy8gQSB0 cmFjayBjYW4gaGF2ZSBtYW55ICJmbG93cyIsIHN1Y2ggYXMgZm9yIFNpbXVsY2FzdCwgRkVDLCBl dGMuDQo+ICAgLy8gQW5kIHRoZXkgY2FuIGJlIGdyb3VwZWQgaW4gYXJiaXRyYXJ5IHdheXMuDQo+ ICAgTWVkaWFGbG93RGVzY3JpcHRpb25bXSBmbG93czsNCj4gICBNZWRpYUZsb3dHcm91cFtdIGZs b3dHcm91cHM7DQo+IH0NCj4NCj4gLy8gUmVwcmVzZW50cyB0aGUgcGFyYW1ldGVycyB1c2VkIHRv IGVpdGhlciBzZW5kIG9yIHJlY2VpdmUgYSAiZmxvdyINCj4gLy8gb3ZlciBhIFBlZXJDb25uZWN0 aW9uLiAgQSAiZmxvdyIgaXMgYSBtZWRpYSB0aGF0IGFycml2ZXMgd2l0aCBhDQo+IC8vIHNpbmds ZSwgdW5pcXVlIFNTUkMuICBPbmUgdG8gbWFueSBmbG93cyB0b2dldGhlciBtYWtlIHVwIHRoZSBt ZWRpYQ0KPiAvLyBmb3IgYSB0cmFjay4gIEZvciBleGFtcGxlLCB0aGVyZSBtYXkgYmUgU2ltdWxj YXN0LCBGRUMsIGFuZCBSVFgNCj4gLy8gZmxvd3MuDQo+IGRpY3Rpb25heSBNZWRpYUZsb3dEZXNj cmlwdGlvbiB7DQo+ICAgLy8gVGhlICJmbG93IGlkIiBtdXN0IGJlIHVuaXF1ZSB0byB0aGUgdHJh Y2ssIGJ1dCBuZWVkIG5vdCBiZSB1bmlxdWUNCj4gICAvLyBvdXRzaWRlIG9mIHRoZSB0cmFjayAo dHdvIHRyYWNrcyBjb3VsZCBib3RoIGhhdmUgYSBmbG93IHdpdGggdGhlDQo+ICAgLy8gc2FtZSBm bG93IElEKS4NCj4gICBET01TdHJpbmcgaWQ7DQo+DQo+ICAgLy8gRWFjaCBmbG93IGNhbiBnbyBv dmVyIGl0cyBvd24gdHJhbnNwb3J0LiAgSWYgdGhlIEpTIHNldHMgdGhpcyB0byBhDQo+ICAgLy8g dHJhbnNwb3J0SWQgdGhhdCBkb2Vzbid0IGhhdmUgYSB0cmFuc3BvcnQgc2V0dXAgYWxyZWFkeSwg dGhlDQo+ICAgLy8gYnJvd3NlciB3aWxsIHVzZSBTRFAgbmVnb3RpYXRpb24gdG8gc2V0dXAgYSB0 cmFuc3BvcnQgdG8gYmFjayB0aGF0DQo+ICAgLy8gdHJhbnNwb3J0SWQuICBJZiBUaGlzIGlzIHNl dCB0byBhbiBNSUQgaW4gdGhlIFNEUCwgdGhlbiB0aGF0IE1JRCdzDQo+ICAgLy8gdHJhbnNwb3J0 IGlzIHVzZWQuDQo+ICAgRE9NU3RyaW5nIHRyYW5zcG9ydElkOw0KPg0KPiAgIC8vIFRoZSBTU1JD IHVzZWQgdG8gc2VuZCB0aGUgZmxvdy4NCj4gICB1bnNpZ25lZCBpbnQgc3NyYzsNCj4NCj4gICAv LyBXaGVuIHVzZWQgYXMgcmVjZWl2ZSBwYXJhbWV0ZXJzLCB0aGlzIGluZGljYXRlcyB0aGUgcG9z c2libGUgbGlzdA0KPiAgIC8vIG9mIGNvZGVjcyB0aGF0IG1pZ2h0IGNvbWUgaW4gZm9yIHRoaXMg Zmxvdy4gIEZvciBleG1hbXBsZSwgYSBnaXZlbg0KPiAgIC8vIHJlY2VpdmUgZmxvdyBjb3VsZCBi ZSBzZXR1cCB0byByZWNlaXZlIGFueSBvZiBPUFVTLCBJU0FDLCBvciBQQ01VLg0KPiAgIC8vIFdo ZW4gdXNlZCBhcyBzZW5kIHBhcmFtZXRlcnMsIHRoaXMgaW5kaWNhdGVzIHRoYXQgdGhlIGZpcnN0 IGNvZGVjDQo+ICAgLy8gc2hvdWxkIGJlIHVzZWQsIGJ1dCB0aGUgYnJvd3NlciBjYW4gdXNlIHNl bmQgb3RoZXIgY29kZWNzIGlmIGl0DQo+ICAgLy8gbmVlZHMgdG8gYmVjYXVzZSBvZiBlaXRoZXIg YmFuZHdpZHRoIG9yIENQVSBjb25zdHJhaW50cy4NCj4gICBNZWRpYUNvZGVjRGVzY3JpcHRpb25b XSBjb2RlY3M7DQo+IH0NCj4NCj4NCj4gZGljdGlvbmFyeSBNZWRpYUZsb3dHcm91cCB7DQo+ICAg RE9NU3RyaW5nIHR5cGU7ICAvLyAiU0lNIiBmb3IgU2ltdWxjYXN0LCAiRkVDIiBmb3IgRkVDLCBl dGMNCj4gICBET01TdHJpbmdbXSBmbG93aWRzOw0KPiB9DQo+DQo+IGRpY3Rpb25hcnkgTWVkaWFD b2RlY0Rlc2NyaXB0aW9uIHsNCj4gICB1bnNpZ25lZCBieXRlIHBheWxvYWRUeXBlOw0KPiAgIERP TVN0cmluZyBuYW1lOw0KPiAgIHVuc2lnbmVkIGludD8gY2xvY2tSYXRlOw0KPiAgIHVuc2lnbmVk IGludD8gYml0UmF0ZTsNCj4gICAvLyBBIGdyYWIgYmFnIG9mIG90aGVyIGZtdHAgdGhhdCB3aWxs IG5lZWQgdG8gYmUgZnVydGhlciBkZWZpbmVkLg0KPiAgIE1lZGlhQ29kZWNQYXJhbVtdIHBhcmFt czsNCj4gfQ0KPg0KPiBkaWN0aW9uYXJ5IE1lZGlhQ29kZWNQYXJhbSB7DQo+ICAgRE9NU3RyaW5n IGtleTsNCj4gICBET01TdHJpbmcgdmFsdWU7DQo+IH0NCj4NCj4NCj4gTm90ZXM6DQo+DQo+IC0g V2hlbiBMb2NhbE1lZGlhU3RyZWFtcyBhcmUgYWRkZWQgdXNpbmcgYWRkU3RyZWFtLCBvbm5lZ290 aWF0ZWRuZWVkZWQgaXMNCj4gbm90IGNhbGxlZCwgYW5kIHRob3NlIHN0cmVhbXMgYXJlIG5ldmVy IHJlZmxlY3RlZCBpbiBmdXR1cmUgU0RQIGV4Y2hhbmdlcy4NCj4gSW5kZWVkLCBpdCB3b3VsZCBi ZSBpbXBvc3NpYmxlIHRvIHB1dCB0aGVtIGluIHRoZSBTRFAgd2l0aG91dCBmaXJzdA0KPiByZXNv bHZpbmcgaWYgdGhhdCB3b3VsZCBiZSBQbGFuIEEgU0RQIG9yIFBsYW4gQiBTRFAuDQo+DQo+IC0g SnVzdCBsaWtlIHBpbGVzIG9mIGF0dHJpYnV0ZXMgd291bGQgbmVlZCB0byBiZSBkZWZpbmVkIGZv ciBQbGFuIEEgYW5kIGZvcg0KPiBQbGFuIEIsIHNpbWlsYXIgYXR0cmlidXRlcyB3b3VsZCBuZWVk IHRvIGJlIGRlZmluZWQgaGVyZSAoTHVja2lseSwgIG11Y2gNCj4gd29yayBoYXMgYWxyZWFkeSBi ZWVuIGRvbmUgZmlndXJpbmcgb3V0IHdoYXQgdGhvc2UgcGFyYW1ldGVycyBhcmUgOikuDQo+DQo+ DQo+IFByb3M6DQo+DQo+IC0gRWl0aGVyIFBsYW4gQSBvciBQbGFuIEIgb3IgY291bGQgYmUgaW1w bGVtZW50ZWQgaW4gSmF2YXNjcmlwdCB1c2luZyB0aGlzDQo+IEFQSQ0KPiAtIEl0IGV4cG9zZXMg YWxsIHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkgdG8gdGhlIEphdmFzY3JpcHQgYXMgU0RQLCBidXQg aW4gYQ0KPiBtdWNoIG5pY2VyIGZvcm1hdCB0aGF0IGlzIG11Y2ggZWFzaWVyIHRvIHdvcmsgd2l0 aC4NCj4gLSBBbnkgb3RoZXIgc2lnbmFsbGluZyBtZWNoYW5pc20sIHN1Y2ggYXMgSmluZ2xlIG9y IENMVUUgY291bGQgYmUNCj4gaW1wbGVtZW50ZWQgdXNpbmcgdGhpcyBBUEkuDQo+IC0gVGhlcmUg aXMgYWxtb3N0IG5vIHJpc2sgb2Ygc2lnbmFsbGluZyBnbGFyZS4NCj4gLSBEZWJ1Z2dpbmcgZXJy b3JzIHdpdGggbWlzY29uZmlndXJlZCBkZXNjcmlwdGlvbnMgc2hvdWxkIGJlIG11Y2ggZWFzaWVy DQo+IHdpdGggdGhpcyB0aGFuIHdpdGggbGFyZ2UgU0RQIGJsb2JzLg0KPg0KPg0KPiBDb25zOg0K Pg0KPiAtIE5vdyB0aGVyZSBhcmUgdHdvIHNsaWdodGx5IGRpZmZlcmVudCB3YXlzIHRvIGFkZCBz dHJlYW1zOiBieSBjcmVhdGluZyBhDQo+IExvY2FsTWVkaWFTdHJlYW0gZmlyc3QsIGFuZCBub3Qu ICBUaGlzIGlzLCBob3dldmVyLCBhbmFsb2dvdXMgdG8gc2V0dGluZw0KPiAibmVnb3RpYXRlZDog dHJ1ZSIgaW4gY3JlYXRlRGF0YUNoYW5uZWwuICBPbiB3YXkgaXMgIkp1c3QgV29yayIsIGFuZCB0 aGUNCj4gb3RoZXIgaXMgbW9yZSBhZHZhbmNlZCBjb250cm9sLg0KPg0KPiAtIEFsbCB0aGUgb3B0 aW9ucyBpbiBNZWRpYUNvZGVjRGVzY3JpcHRpb24gYXJlIGEgYml0IGNvbXBsaWNhdGVkLiAgUmVh bGx5LA0KPiB0aGlzIGlzIG9ubHkgbmVjZXNzYXJ5IGJlY2F1c2UgUGxhbiBBIHJlcXVpcmVzIGJl aW5nIGFibGUgdG8gc3BlY2lmeSBjb2RlYw0KPiBwYXJhbWV0ZXJzIHBlciBTU1JDLCBhbmQgc2V0 IGVhY2ggZmxvdyBvbiBkaWZmZXJlbnQgdHJhbnNwb3J0cy4gIElmIHdlIGRpZA0KPiBub3QgaGF2 ZSB0aGlzIHJlcXVpcmVtZW50LCB3ZSBjb3VsZCBzaW1wbGlmeS4NCj4NCj4NCj4gRXhhbXBsZSBV c2FnZToNCj4NCj4gLy8gSW1hZ2luZSBJIGhhdmUgTXlBcHAsIGhhbmRsZXMgY3JlYXRpbmcgYSBQ ZWVyQ29ubmVjdGlvbiwNCj4gLy8gc2lnbmFsbGluZywgYW5kIHJlbmRlcmluZyBzdHJlYW1zLiAg VGhpcyBpcyBob3cgdGhlIG5ldyBBUEkgY291bGQgYmUNCj4gLy8gdXNlZC4NCj4gdmFyIHBlZXJD b25uZWN0aW9uID0gTXlBcHAuY3JlYXRlUGVlckNvbm5lY3Rpb24oKTsNCj4NCj4gLy8gT24gc2Vu ZGVyIHNpZGU6DQo+IHZhciBzdHJlYW0gPSBNeUFwcC5nZXRNZWRpYVN0cmVhbSgpOw0KPiB2YXIg bG9jYWxTdHJlYW0gPSBwZWVyQ29ubmVjdGlvbi5jcmVhdGVTZW5kU3RyZWFtKHN0cmVhbSk7DQo+ IHNlbmRTdHJlYW0uZGVzY3JpcHRpb24gPSBNeUFwcC5tb2RpZnlTdHJlYW0obG9jYWxTdHJlYW0u ZGVzY3JpcHRpb24pDQo+IE15QXBwLnNpZ25hbEFkZFN0cmVhbShsb2NhbFN0cmVhbS5kZXNjcmlw dGlvbiwgZnVuY3Rpb24ocmVzcG9uc2UpKSB7DQo+ICAgaWYgKCFyZXNwb25zZS5yZWplY3RlZCkg ew0KPiAgICAgLy8gTWVkaWEgd2lsbCBub3QgYmUgc2VudC4NCj4gICAgIHBlZXJDb25uZWN0aW9u LmFkZFN0cmVhbShsb2NhbFN0cmVhbSk7DQo+ICAgfQ0KPiB9DQo+DQo+IC8vIE9uIHJlY2VpdmVy IHNpZGU6DQo+IE15QXBwLm9uQWRkU3RyZWFtU2lnbmFsbGVkID0gZnVuY3Rpb24oc3RyZWFtRGVz Y3JpcHRpb24pIHsNCj4gICB2YXIgc3RyZWFtID0gcGVlckNvbm5lY3Rpb24uY3JlYXRlUmVjZWl2 ZVN0cmVhbShzdHJlYW1EZXNjcmlwdGlvbik7DQo+ICAgTXlBcHAucmVuZGVyU3RyZWFtKHN0cmVh bSk7DQo+IH0NCj4NCj4NCj4gLy8gSW4gdGhpcyBleGNoYW5nZSwgdGhlIE1lZGlhU3RyZWFtRGVz Y3JpcHRpb24gc2lnbmFsbGVkIGZyb20gdGhlDQo+IC8vIHNlbmRlciB0byB0aGUgcmVjZWl2ZXIg bWF5IGhhdmUgbG9va2VkIHNvbWV0aGluZyBsaWtlIHRoaXM6DQo+DQo+IHsNCj4gICB0cmFja3M6 IFsNCj4gICB7DQo+ICAgICBpZDogImF1ZGlvMSIsDQo+ICAgICBraW5kOiAiYXVkaW8iLA0KPiAg ICAgZmxvd3M6IFsNCj4gICAgIHsNCj4gICAgICAgaWQ6ICJtYWluIiwNCj4gICAgICAgdHJhbnNw b3J0SWQ6ICJ0cmFuc3BvcnQxIiwNCj4gICAgICAgc3NyYzogMTExMSwNCj4gICAgICAgY29kZWNz OiBbDQo+ICAgICAgIHsNCj4gICAgICAgICBwYXlsb2FkVHlwZTogMTExLA0KPiAgICAgICAgIG5h bWU6ICJvcHVzIiwNCj4gICAgICAgICAvLyAuLi4gbW9yZSBjb2RlYyBkZXRhaWxzDQo+ICAgICAg IH0sDQo+ICAgICAgIHsNCj4gICAgICAgICBwYXlsb2FkVHlwZTogMTEyLA0KPiAgICAgICAgIG5h bWU6ICJwY211IiwNCj4gICAgICAgICAvLyAuLi4gbW9yZSBjb2RlYyBkZXRhaWxzDQo+ICAgICAg IH1dDQo+ICAgIH1dDQo+ICB9LA0KPiAgew0KPiAgICAgaWQ6ICJ2aWRlbzEiLA0KPiAgICAga2lu ZDogInZpZGVvIiwNCj4gICAgIGZsb3dzOiBbDQo+ICAgICB7DQo+ICAgICAgIGlkOiAic2ltMCIs DQo+ICAgICAgIHRyYW5zcG9ydElkOiAidHJhbnNwb3J0MiIsDQo+ICAgICAgIHNzcmM6IDIyMjIs DQo+ICAgICAgIGNvZGVjczogWw0KPiAgICAgICB7DQo+ICAgICAgICAgcGF5bG9hZFR5cGU6IDEy MiwNCj4gICAgICAgICBuYW1lOiAidnA4Ig0KPiAgICAgICAgIC8vIC4uLiBtb3JlIGNvZGVjIGRl dGFpbHMNCj4gICAgICAgfV0NCj4gICAgfSwNCj4gICAgew0KPiAgICAgIGlkOiAic2ltMSIsDQo+ ICAgICAgdHJhbnNwb3J0SWQ6ICJ0cmFuc3BvcnQyIiwNCj4gICAgICBzc3JjOiAyMjIzLA0KPiAg ICAgIGNvZGVjczogWw0KPiAgICAgIHsNCj4gICAgICAgIHBheWxvYWRUeXBlOiAxMjIsDQo+ICAg ICAgICBuYW1lOiAidnA4IiwNCj4gICAgICAgIC8vIC4uLiBtb3JlIGNvZGVjIGRldGFpbHMNCj4g ICAgICB9XQ0KPiAgICB9LA0KPiAgICB7DQo+ICAgICAgaWQ6ICJzaW0yIiwNCj4gICAgICB0cmFu c3BvcnRJZDogInRyYW5zcG9ydDIiLA0KPiAgICAgIHNzcmM6IDIyMjQsDQo+ICAgICAgY29kZWNz OiBbDQo+ICAgICAgew0KPiAgICAgICAgcGF5bG9hZFR5cGU6IDEyMiwNCj4gICAgICAgIG5hbWU6 ICJ2cDgiLA0KPiAgICAgICAgLy8gLi4uIG1vcmUgY29kZWMgZGV0YWlscw0KPiAgICAgIH1dDQo+ ICAgIH0sDQo+DQo+ICAgIHsNCj4gICAgICBpZDogInNpbTBmZWMiLA0KPiAgICAgIHRyYW5zcG9y dElkOiAidHJhbnNwb3J0MiIsDQo+ICAgICAgc3NyYzogMjIyNSwNCj4gICAgICBjb2RlY3M6IFsN Cj4gICAgICB7DQo+ICAgICAgICBwYXlsb2FkVHlwZTogMTIyLA0KPiAgICAgICAgbmFtZTogInZw OCIsDQo+ICAgICAgICAvLyAuLi4NCj4gICAgICB9XQ0KPiAgICB9XSwNCj4gICAgZmxvd0dyb3Vw czogWw0KPiAgICB7DQo+ICAgICAgc2VtYW50aWNzOiAiU0lNIiwNCj4gICAgICBzc3JjczogWzIy MjIsIDIyMjMsIDIyMjRdDQo+ICAgIH0sDQo+ICAgIHsNCj4gICAgICBzZW1hbnRpY3M6ICJGRUMi LA0KPiAgICAgIHNzcmNzOiBbMjIyMiwgMjIyNV0NCj4gICAgfV0NCj4gIH1dDQo+IH0NCj4NCj4N Cj4gQ29uc3RydWN0aXZlIGZlZWRiYWNrIGlzIHdlbGNvbWUgOikuDQo+DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHJ0Y3dlYiBtYWlsaW5nIGxp c3QNCj4gcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+DQoNCg== --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C59AETK5EX14MBXC273r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Tm90ZSB0aGF0IOKAnGFsbCBvciBub3RoaW5n4oCdIGRvZXNu4oCZ dCBtZWFuIOKAnHRha2UgaXQgb3IgbGVhdmUgaXQgd2l0aCByZWdhcmQgdG8gdGhlIGZ1bGwgQ1Ut UlRDV0VCIHByb3Bvc2FsIGZyb20gTWljcm9zb2Z04oCdLiBJdCBtZWFucw0KIOKAnGtlZXAgU0RQ IG9mZmVyL2Fuc3dlciBhbmQgdGhlIGJpZyBibG9iIG9mIHRleHQgYW5kIGFsbCB0aGF04oCdIG9y IOKAnHN0YXJ0IHdpdGggdGhlIENVLVJUQ1dFQiBwcm9wb3NhbCBhcyBhIGJhc2UgYW5kIHVzZSBj b21tdW5pdHkgaW5wdXQgYW5kIGNvbnNlbnN1cyB0byBtYWtlIGl0IGludG8gc29tZXRoaW5nIGV2 ZW4gYmV0dGVy4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1hdHRoZXcgS2F1Zm1hbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBl dGVyIFRoYXRjaGVyPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVuZSAxNywgMjAxMyAxMjoy NiBQTTxicj4NCjxiPlRvOjwvYj4gTWFydGluIFRob21zb248YnI+DQo8Yj5DYzo8L2I+ICZsdDty dGN3ZWJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBQcm9w b3NhbCBmb3IgYSBKUyBBUEkgZm9yIE5vUGxhbiAoYWRkaW5nIG11bHRpcGxlIHNvdXJjZXMgd2l0 aG91dCBlbmNvZGluZyB0aGVtIGluIFNEUCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBJIHdhcyBleHBlY3RpbmcgeW91IHRvIGJlIG1v cmUgc3VwcG9ydGl2ZS4gJm5ic3A7SSdtIHN1cnByaXNlZCBvdXQgaG93IHlvdXIgd2FudCAmcXVv dDthbGwgb3Igbm90aGluZyZxdW90Oy4gJm5ic3A7SSdtIGFmcmFpZCBpZiBvdXIgb3B0aW9ucyBm b3IgYSBjbGVhbiBBUEkgYXJlIGFsbCBvciBub3RoaW5nLCB3ZSdsbCBqdXN0IGVuZCB1cCB3aXRo IG5vdGhpbmcuICZuYnNwO0knZCBwcmVmZXIgdG8gdHJ5IGluY3JlbWVudGFsIGltcHJvdmVtZW50 cw0KIHRvIHdvcmQgdG93YXJkIChldmVudHVhbGx5KSBhIGNsZWFuIEFQSS4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvIHlvdSB0aGluayBpdCBp cyBpbXBvc3NpYmxlIHRvIHdvcmsgdG93YXJkIGEgY2xlYW4gQVBJIGluIGFuIGluY3JlbWVudGFs IGFwcHJvYWNoPyAmbmJzcDtJZiB5b3UgdGhpbmsgaXQncyBwb3NzaWJsZSwgSSdkIGxpa2UgdG8g aGVhciB5b3VyIHRob3VnaHRzIG9uIGhvdy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnkgdGhlIHdheSwgdGhlc2UgQVBJIGFkZGl0aW9ucyB3 b3VsZCBncmVhdGx5IG1pbmltaXplIHRoZSBhbW91bnQgb2YgU0RQIGVkaXRpbmcgbmVjZXNzYXJ5 IGZvciBKUyBjbGllbnRzIHRoYXQgZG9uJ3QgdXNlIFNEUCBmb3Igc2lnbmFsbGluZy4gJm5ic3A7 QW5kIGxhdGVyIGluY3JlbWVudGFsIGltcHJvdmVtZW50cyBjb3VsZCByZWR1Y2UgaXQgZnVydGhl ci4gJm5ic3A7QWxzbywgaXQncyBubyBsb25nZXIgbmVjZXNzYXJ5IHRvDQogZG8gb2ZmZXIvYW5z d2VyIGZvciBhZGRpbmcgdHJhY2tzLiAmbmJzcDtJdCdzIG9ubHkgdGhlIGludGlhbCBQZWVyQ29u bmVjdGlvbiBzZXR1cCB0aGF0IG5lZWRzIHRvIGRvIE9mZmVyL0Fuc3dlci4gJm5ic3A7U28sIGl0 IGRvZXNuJ3QgaW5oZXJpdCBhbGwgdGhlIHByb2JsZW1zIHF1aXRlIGFzIG11Y2ggYXMgeW91IGRl c2NyaWJlZC4gJm5ic3A7SXQgbWF5IGJlIHNsaWdodGx5IGFib21pbmFibGUsIGJ1dCBJIGNlcnRh aW5seSBjb25zaWRlciBpdCBsZXNzIGFib21pbmFibGUNCiB0aGFuIHRoZSBTRFAgZWRpdGluZyBu ZWNlc3Nhcnkgd2l0aG91dCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEp1 biAxNywgMjAxMyBhdCAxMTo1NyBBTSwgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0 bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNv bkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXliZSB5b3UnZCBleHBlY3QgbWUgdG8gYmUgbW9yZSBzdXBw b3J0aXZlIG9mIHNvbWV0aGluZyB0aGF0IGxvb2tlZDxicj4NCnNvIG11Y2ggbGlrZSBDVS1SVEMt V2ViLiAmbmJzcDtJdCBpbmhlcml0cyBhbGwgdGhlIHdvcnN0IHByb3BlcnRpZXMgb2YgSlNFUDxi cj4NCihPZmZlci9BbnN3ZXIsIFNEUCBlZGl0aW5nKSB3aXRoIGEgcGFydGlhbCBpbXBsZW1lbnRh dGlvbiBvZiBhIGNsZWFuPGJyPg0KQVBJLjxicj4NCjxicj4NCkl0J3MgY29tbWVudCAyMi1saXRl LiAmbmJzcDtJdCdzIGFuIGFib21pbmF0aW9uLiAmbmJzcDtJZiB5b3UgYXJlIGdvaW5nIHRvIGRv PGJyPg0KdGhpcywgZG8gaXQgcHJvcGVybHkuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk9uIDE3IEp1bmUgMjAxMyAwNTo1NywgUGV0ZXIg VGhhdGNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnB0aGF0Y2hlckBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBH b29nbGUgaXMgaW4gZnVsbCBzdXBwb3J0IG9mICZxdW90O1BsYW4gQiZxdW90OyBmb3IgZW5jb2Rp bmcgbXVsdGlwbGUgbWVkaWEgc291cmNlcyBpbjxicj4NCiZndDsgU0RQLCBhbmQgd291bGQgbGlr ZSB0byBzZWUgdGhlIFBsYW4gQSB2cy4gUGxhbiBCIGRlY2lzaW9uIHJlc29sdmVkIHNvb24uPGJy Pg0KJmd0OyBSZWNlbnRseSwgdGhvdWdoLCBhIHRoaXJkIG9wdGlvbiwgY2FsbGVkICZxdW90O05v UGxhbiZxdW90OyBoYXMgYmVlbiBwcm9wb3NlZCwgYnV0IGl0PGJyPg0KJmd0OyBsYWNrZWQgdGhl IGRldGFpbHMgb2Ygd2hhdCBhIEpTIEFQSSB3b3VsZCBsb29rIGxpa2UgZm9yIE5vUGxhbi4gJm5i c3A7Q3VsbGVuPGJyPg0KJmd0OyBhc2tlZCB0byBzZWUgc3VjaCBhbiBBUEkgcHJvcG9zYWwsIGFu ZCBzbyBJIGhhdmUgd29ya2VkIHdpdGggRW1pbCB0byBtYWtlPGJyPg0KJmd0OyBvbmUuICZuYnNw O0hlIHdpbGwgYmUgYWRkaW5nIGl0IHRvIHRoZSBOb1BsYW4gZHJhZnQsIGJ1dCBJIHdpbGwgYWxz byBpbmNsdWRlIGl0PGJyPg0KJmd0OyBpbiB0aGlzIGVtYWlsLjxicj4NCiZndDs8YnI+DQomZ3Q7 IEFnYWluLCBHb29nbGUgaXMgaW4gZnVsbCBzdXBwb3J0IG9mICZxdW90O1BsYW4gQiZxdW90Oy4g Jm5ic3A7QnV0IGlmIFBsYW4gQSB2cy4gUGxhbiBCPGJyPg0KJmd0OyBjYW5ub3QgYmUgZGVjaWRl ZCwgdGhlbiB3ZSBzdXBwb3J0IE5vUGxhbiB3aXRoIHRoZSBmb2xsb3dpbmcgYWRkaXRpb25zIHRv PGJyPg0KJmd0OyB0aGUgV2ViUlRDIEpTIEFQSSBhcyBhbiBvcHRpb24gdGhhdCBhbGxvd3MgaW1w bGVtZW50aW5nIGVpdGhlciBQbGFuIEEgb3I8YnI+DQomZ3Q7IFBsYW4gQiAmbmJzcDtpbiBKYXZh c2NyaXB0LiAmbmJzcDtBbmQgZXZlbiBpZiBQbGFuIEEgdnMuIFBsYW4gQiBpcyByZXNvbHZlZCwg dGhlc2UgQVBJPGJyPg0KJmd0OyBhZGRpdGlvbnMgd291bGQgc3RpbGwgYmUgYSBiaWcgaW1wcm92 ZW1lbnQgZm9yIHRob3NlIFdlYlJUQyBhcHBsaWNhdGlvbnM8YnI+DQomZ3Q7IHRoYXQgZG9uJ3Qg dXNlIFNEUCBmb3Igc2lnbmFsbGluZy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJdCBpcyBhIGJpdCBs b25nIGJlY2F1c2UgSSBoYXZlIGFkZGVkIG1hbnkgY29tbWVudHMgYW5kIGV4YW1wbGVzLCBidXQg dGhlPGJyPg0KJmd0OyBhY3R1YWxseSBhZGRpdGlvbnMgb25seSBpbmNsdWRlIHR3byBuZXcgbWV0 aG9kcyBvbiBQZWVyQ29ubmVjdGlvbiBhbmQgYSBmZXc8YnI+DQomZ3Q7IG5ldyBkaWN0aW9uYXJp ZXMuICZuYnNwO1NvIGRvbid0IGJlIG92ZXJ3aGVsbWVkIDopLjxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgSW50cm86IFRoaXMgZm9sbG93cyB0aGUgbW9kZWwgb2YgY3Jl YXRlRGF0YUNoYW5uZWwsIHdoaWNoIGhhcyBhIEpTIG1ldGhvZCBvbjxicj4NCiZndDsgUGVlckNv bm5lY3Rpb24gdGhhdCBtYWtlcyBpdCBwb3NzaWJsZSB0byBhZGQgZGF0YSBjaGFubmVscyB3aXRo b3V0IGdvaW5nPGJyPg0KJmd0OyB0aHJvdWdoIFNEUC4gJm5ic3A7RnVydGhlcm1vcmUsIGp1c3Qg bGlrZSBjcmVhdGVEYXRhQ2hhbm5lbCBhbGxvd3MgMiB3YXlzIHRvPGJyPg0KJmd0OyBoYW5kbGUg bmVvZ2l0YXRpb24gKHRoZSAmcXVvdDtJIGtub3cgd2hhdCBJJ20gZG9pbmc7ICZuYnNwO0hlcmUn cyB3aGF0IEkgd2FudCB0byBzZW5kOzxicj4NCiZndDsgTGV0IG1lIHNpZ25hbCBldmVyeXRoaW5n JnF1b3Q7IG1vZGUgYW5kIHRoZSAmcXVvdDtwbGVhc2UgdGFrZSBjYXJlIG9mIGl0IGZvciBtZTsg Jm5ic3A7c2VuZDxicj4NCiZndDsgYW4gT1BFTiBtZXNzYWdlJnF1b3Q7IG1vZGUpLCB0aGlzIGFs c28gaGFzIDIgd2F5cyB0byBoYW5kbGUgbmVnb3RpYXRpb24gKHRoZSAmcXVvdDtJPGJyPg0KJmd0 OyBrbm93IHdoYXQgSSdtIGRvaW5nOyBIZXJlJ3Mgd2hhdCBJIHdhbnQgdG8gc2VuZDsgTGV0IG1l IHNpZ25hbCBldmVyeXRoaW5nJnF1b3Q7PGJyPg0KJmd0OyBtb2RlIGFuZCB0aGUgJnF1b3Q7cGxl YXNlIHRha2UgY2FyZSBvZiBpdCBmb3IgbWU7ICZuYnNwO3NlbmQgU0RQIGJhY2sgYW5kIGZvcnRo JnF1b3Q7PGJyPg0KJmd0OyBtb2RlKS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBGb2xsb3dpbmcgdGhl IHN1Y2Nlc3Mgb2YgY3JlYXRlRGF0YUNoYW5uZWwsIHRoaXMgYWxsb3dzIHNpbXBsZSBhcHBsaWNh dGlvbnM8YnI+DQomZ3Q7IHRvIEp1c3QgV29yayBhbmQgbW9yZSBhZHZhbmNlZCBhcHBsaWNhdGlv bnMgdG8gZWFzaWx5IGNvbnRyb2wgd2hhdCB0aGV5IG5lZWQ8YnI+DQomZ3Q7IHRvLiAmbmJzcDtJ biBwYXJ0aWN1bGFyLCBpdCdzIHBvc3NpYmxlIHRvIHVzZSB0aGlzIEFQSSB0byBpbXBsZW1lbnQg ZWl0aGVyIFBsYW4gQTxicj4NCiZndDsgb3IgUGxhbiBCLjxicj4NCiZndDs8YnI+DQomZ3Q7IC8v IFRoZSBmb2xsb3dpbmcgdHdvIG1ldGhvZCBhcmUgYWRkZWQgdG8gUlRDUGVlckNvbm5lY3Rpb248 YnI+DQomZ3Q7IHBhcnRpYWwgaW50ZXJmYWNlIFJUQ1BlZXJDb25uZWN0aW9uIHs8YnI+DQomZ3Q7 ICZuYnNwOy8vIENyZWF0ZSBhIHN0cmVhbSB0aGF0IGlzIHVzZWQgdG8gc2VuZCBhIHNvdXJjZSBz dHJlYW0uPGJyPg0KJmd0OyAmbmJzcDsvLyBUaGUgTWVkaWFTZW5kU3RyZWFtLmRlc2NyaXB0aW9u IGNhbiBiZSB1c2VkIGZvciBzaWduYWxsaW5nLjxicj4NCiZndDsgJm5ic3A7Ly8gTm8gbWVkaWEg aXMgc2VudCB1bnRpbCBhZGRTdHJlYW0oTWVkaWFTZW5kU3RyZWFtKSBpcyBjYWxsZWQuPGJyPg0K Jmd0OyAmbmJzcDtMb2NhbE1lZGlhU3RyZWFtIGNyZWF0ZUxvY2FsU3RyZWFtKE1lZGlhU3RyZWFt IHNvdXJjZVN0cmVhbSk7PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7Ly8gQ3JlYXRlIGEgc3Ry ZWFtIHRoYXQgaXMgdXNlZCB0byByZWNlaXZlIG1lZGlhIGZyb20gdGhlIHJlbW90ZSBzaWRlLDxi cj4NCiZndDsgJm5ic3A7Ly8gZ2l2ZW4gdGhlIHBhcmFtZXRlcnMgc2lnbmFsbGVkIGZyb20gTWVk YWlTZW5kU3RyZWFtLmRlc2NyaXB0aW9uLjxicj4NCiZndDsgJm5ic3A7TWVkaWFTdHJlYW0gY3Jl YXRlUmVtb3RlU3RyZWFtKE1lZGlhU3RyZWFtRGVzY3JpcHRpb24gZGVzY3JpcHRpb24pOzxicj4N CiZndDsgfTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBpbnRlcmZhY2UgTG9jYWxNZWRp YVN0cmVhbSBpbXBsZW1lbnRzIE1lZGlhU3RyZWFtIHs8YnI+DQomZ3Q7ICZuYnNwOyAvLyBUaGlz IGNhbiBiZSBjaGFuZ2VkIGF0IGFueSB0aW1lLCBidXQgZXNwZWNpYWxseSBiZWZvcmUgY2FsbGlu Zzxicj4NCiZndDsgJm5ic3A7IC8vIFBlZXJDb25uZWN0aW9uLmFkZFN0cmVhbTxicj4NCiZndDsg Jm5ic3A7IGF0dHJpYnV0ZSBNZWRpYVN0cmVhbURlc2NyaXB0aW9uIGRlc2NyaXB0aW9uOzxicj4N CiZndDsgfTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAvLyBSZXByZXNlbnRzIHRoZSBw YXJhbWV0ZXJzIHVzZWQgdG8gZWl0aGVyIHNlbmQgb3IgcmVjZWl2ZSBhIHN0cmVhbTxicj4NCiZn dDsgLy8gb3ZlciBhIFBlZXJDb25uZWN0aW9uLjxicj4NCiZndDsgZGljdGlvbmFyeSBNZWRpYVN0 cmVhbURlc2NyaXB0aW9uIHs8YnI+DQomZ3Q7ICZuYnNwOyBNZWRpYVN0cmVhbVRyYWNrRGVzY3Jp cHRpb25bXSB0cmFja3M7PGJyPg0KJmd0OyB9PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 IC8vIFJlcHJlc2VudHMgdGhlIHBhcmFtZXRlcnMgdXNlZCB0byBlaXRoZXIgc2VuZCBvciByZWNl aXZlIGEgdHJhY2sgb3ZlciAvLzxicj4NCiZndDsgYSBQZWVyQ29ubmVjdGlvbi4gJm5ic3A7QSB0 cmFjayBoYXMgbWFueSAmcXVvdDtmbG93cyZxdW90Oywgd2hpY2ggY2FuIGJlIGdyb3VwZWQ8YnI+ DQomZ3Q7IC8vIHRvZ2V0aGVyLjxicj4NCiZndDsgZGljdGlvbmFyeSBNZWRpYVN0cmVhbVRyYWNr RGVzY3JpcHRpb24gezxicj4NCiZndDsgJm5ic3A7IC8vIFNhbWUgYXMgdGhlIE1lZGlhU3RyZWFt VHJhY2suaWQ8YnI+DQomZ3Q7ICZuYnNwOyBET01TdHJpbmcgaWQ7PGJyPg0KJmd0Ozxicj4NCiZn dDsgJm5ic3A7IC8vIFNhbWUgYXMgdGhlIE1lZGlhU3RyZWFtVHJhY2sua2luZDxicj4NCiZndDsg Jm5ic3A7IERPTVN0cmluZyBraW5kOzxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAvLyBBIHRy YWNrIGNhbiBoYXZlIG1hbnkgJnF1b3Q7Zmxvd3MmcXVvdDssIHN1Y2ggYXMgZm9yIFNpbXVsY2Fz dCwgRkVDLCBldGMuPGJyPg0KJmd0OyAmbmJzcDsgLy8gQW5kIHRoZXkgY2FuIGJlIGdyb3VwZWQg aW4gYXJiaXRyYXJ5IHdheXMuPGJyPg0KJmd0OyAmbmJzcDsgTWVkaWFGbG93RGVzY3JpcHRpb25b XSBmbG93czs8YnI+DQomZ3Q7ICZuYnNwOyBNZWRpYUZsb3dHcm91cFtdIGZsb3dHcm91cHM7PGJy Pg0KJmd0OyB9PGJyPg0KJmd0Ozxicj4NCiZndDsgLy8gUmVwcmVzZW50cyB0aGUgcGFyYW1ldGVy cyB1c2VkIHRvIGVpdGhlciBzZW5kIG9yIHJlY2VpdmUgYSAmcXVvdDtmbG93JnF1b3Q7PGJyPg0K Jmd0OyAvLyBvdmVyIGEgUGVlckNvbm5lY3Rpb24uICZuYnNwO0EgJnF1b3Q7ZmxvdyZxdW90OyBp cyBhIG1lZGlhIHRoYXQgYXJyaXZlcyB3aXRoIGE8YnI+DQomZ3Q7IC8vIHNpbmdsZSwgdW5pcXVl IFNTUkMuICZuYnNwO09uZSB0byBtYW55IGZsb3dzIHRvZ2V0aGVyIG1ha2UgdXAgdGhlIG1lZGlh PGJyPg0KJmd0OyAvLyBmb3IgYSB0cmFjay4gJm5ic3A7Rm9yIGV4YW1wbGUsIHRoZXJlIG1heSBi ZSBTaW11bGNhc3QsIEZFQywgYW5kIFJUWDxicj4NCiZndDsgLy8gZmxvd3MuPGJyPg0KJmd0OyBk aWN0aW9uYXkgTWVkaWFGbG93RGVzY3JpcHRpb24gezxicj4NCiZndDsgJm5ic3A7IC8vIFRoZSAm cXVvdDtmbG93IGlkJnF1b3Q7IG11c3QgYmUgdW5pcXVlIHRvIHRoZSB0cmFjaywgYnV0IG5lZWQg bm90IGJlIHVuaXF1ZTxicj4NCiZndDsgJm5ic3A7IC8vIG91dHNpZGUgb2YgdGhlIHRyYWNrICh0 d28gdHJhY2tzIGNvdWxkIGJvdGggaGF2ZSBhIGZsb3cgd2l0aCB0aGU8YnI+DQomZ3Q7ICZuYnNw OyAvLyBzYW1lIGZsb3cgSUQpLjxicj4NCiZndDsgJm5ic3A7IERPTVN0cmluZyBpZDs8YnI+DQom Z3Q7PGJyPg0KJmd0OyAmbmJzcDsgLy8gRWFjaCBmbG93IGNhbiBnbyBvdmVyIGl0cyBvd24gdHJh bnNwb3J0LiAmbmJzcDtJZiB0aGUgSlMgc2V0cyB0aGlzIHRvIGE8YnI+DQomZ3Q7ICZuYnNwOyAv LyB0cmFuc3BvcnRJZCB0aGF0IGRvZXNuJ3QgaGF2ZSBhIHRyYW5zcG9ydCBzZXR1cCBhbHJlYWR5 LCB0aGU8YnI+DQomZ3Q7ICZuYnNwOyAvLyBicm93c2VyIHdpbGwgdXNlIFNEUCBuZWdvdGlhdGlv biB0byBzZXR1cCBhIHRyYW5zcG9ydCB0byBiYWNrIHRoYXQ8YnI+DQomZ3Q7ICZuYnNwOyAvLyB0 cmFuc3BvcnRJZC4gJm5ic3A7SWYgVGhpcyBpcyBzZXQgdG8gYW4gTUlEIGluIHRoZSBTRFAsIHRo ZW4gdGhhdCBNSUQnczxicj4NCiZndDsgJm5ic3A7IC8vIHRyYW5zcG9ydCBpcyB1c2VkLjxicj4N CiZndDsgJm5ic3A7IERPTVN0cmluZyB0cmFuc3BvcnRJZDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAm bmJzcDsgLy8gVGhlIFNTUkMgdXNlZCB0byBzZW5kIHRoZSBmbG93Ljxicj4NCiZndDsgJm5ic3A7 IHVuc2lnbmVkIGludCBzc3JjOzxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAvLyBXaGVuIHVz ZWQgYXMgcmVjZWl2ZSBwYXJhbWV0ZXJzLCB0aGlzIGluZGljYXRlcyB0aGUgcG9zc2libGUgbGlz dDxicj4NCiZndDsgJm5ic3A7IC8vIG9mIGNvZGVjcyB0aGF0IG1pZ2h0IGNvbWUgaW4gZm9yIHRo aXMgZmxvdy4gJm5ic3A7Rm9yIGV4bWFtcGxlLCBhIGdpdmVuPGJyPg0KJmd0OyAmbmJzcDsgLy8g cmVjZWl2ZSBmbG93IGNvdWxkIGJlIHNldHVwIHRvIHJlY2VpdmUgYW55IG9mIE9QVVMsIElTQUMs IG9yIFBDTVUuPGJyPg0KJmd0OyAmbmJzcDsgLy8gV2hlbiB1c2VkIGFzIHNlbmQgcGFyYW1ldGVy cywgdGhpcyBpbmRpY2F0ZXMgdGhhdCB0aGUgZmlyc3QgY29kZWM8YnI+DQomZ3Q7ICZuYnNwOyAv LyBzaG91bGQgYmUgdXNlZCwgYnV0IHRoZSBicm93c2VyIGNhbiB1c2Ugc2VuZCBvdGhlciBjb2Rl Y3MgaWYgaXQ8YnI+DQomZ3Q7ICZuYnNwOyAvLyBuZWVkcyB0byBiZWNhdXNlIG9mIGVpdGhlciBi YW5kd2lkdGggb3IgQ1BVIGNvbnN0cmFpbnRzLjxicj4NCiZndDsgJm5ic3A7IE1lZGlhQ29kZWNE ZXNjcmlwdGlvbltdIGNvZGVjczs8YnI+DQomZ3Q7IH08YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgZGljdGlvbmFyeSBNZWRpYUZsb3dHcm91cCB7PGJyPg0KJmd0OyAmbmJzcDsgRE9NU3Ry aW5nIHR5cGU7ICZuYnNwOy8vICZxdW90O1NJTSZxdW90OyBmb3IgU2ltdWxjYXN0LCAmcXVvdDtG RUMmcXVvdDsgZm9yIEZFQywgZXRjPGJyPg0KJmd0OyAmbmJzcDsgRE9NU3RyaW5nW10gZmxvd2lk czs8YnI+DQomZ3Q7IH08YnI+DQomZ3Q7PGJyPg0KJmd0OyBkaWN0aW9uYXJ5IE1lZGlhQ29kZWNE ZXNjcmlwdGlvbiB7PGJyPg0KJmd0OyAmbmJzcDsgdW5zaWduZWQgYnl0ZSBwYXlsb2FkVHlwZTs8 YnI+DQomZ3Q7ICZuYnNwOyBET01TdHJpbmcgbmFtZTs8YnI+DQomZ3Q7ICZuYnNwOyB1bnNpZ25l ZCBpbnQ/IGNsb2NrUmF0ZTs8YnI+DQomZ3Q7ICZuYnNwOyB1bnNpZ25lZCBpbnQ/IGJpdFJhdGU7 PGJyPg0KJmd0OyAmbmJzcDsgLy8gQSBncmFiIGJhZyBvZiBvdGhlciBmbXRwIHRoYXQgd2lsbCBu ZWVkIHRvIGJlIGZ1cnRoZXIgZGVmaW5lZC48YnI+DQomZ3Q7ICZuYnNwOyBNZWRpYUNvZGVjUGFy YW1bXSBwYXJhbXM7PGJyPg0KJmd0OyB9PGJyPg0KJmd0Ozxicj4NCiZndDsgZGljdGlvbmFyeSBN ZWRpYUNvZGVjUGFyYW0gezxicj4NCiZndDsgJm5ic3A7IERPTVN0cmluZyBrZXk7PGJyPg0KJmd0 OyAmbmJzcDsgRE9NU3RyaW5nIHZhbHVlOzxicj4NCiZndDsgfTxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBOb3Rlczo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtIFdoZW4gTG9jYWxNZWRpYVN0 cmVhbXMgYXJlIGFkZGVkIHVzaW5nIGFkZFN0cmVhbSwgb25uZWdvdGlhdGVkbmVlZGVkIGlzPGJy Pg0KJmd0OyBub3QgY2FsbGVkLCBhbmQgdGhvc2Ugc3RyZWFtcyBhcmUgbmV2ZXIgcmVmbGVjdGVk IGluIGZ1dHVyZSBTRFAgZXhjaGFuZ2VzLjxicj4NCiZndDsgSW5kZWVkLCBpdCB3b3VsZCBiZSBp bXBvc3NpYmxlIHRvIHB1dCB0aGVtIGluIHRoZSBTRFAgd2l0aG91dCBmaXJzdDxicj4NCiZndDsg cmVzb2x2aW5nIGlmIHRoYXQgd291bGQgYmUgUGxhbiBBIFNEUCBvciBQbGFuIEIgU0RQLjxicj4N CiZndDs8YnI+DQomZ3Q7IC0gSnVzdCBsaWtlIHBpbGVzIG9mIGF0dHJpYnV0ZXMgd291bGQgbmVl ZCB0byBiZSBkZWZpbmVkIGZvciBQbGFuIEEgYW5kIGZvcjxicj4NCiZndDsgUGxhbiBCLCBzaW1p bGFyIGF0dHJpYnV0ZXMgd291bGQgbmVlZCB0byBiZSBkZWZpbmVkIGhlcmUgKEx1Y2tpbHksICZu YnNwO211Y2g8YnI+DQomZ3Q7IHdvcmsgaGFzIGFscmVhZHkgYmVlbiBkb25lIGZpZ3VyaW5nIG91 dCB3aGF0IHRob3NlIHBhcmFtZXRlcnMgYXJlIDopLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBQcm9zOjxicj4NCiZndDs8YnI+DQomZ3Q7IC0gRWl0aGVyIFBsYW4gQSBvciBQbGFuIEIg b3IgY291bGQgYmUgaW1wbGVtZW50ZWQgaW4gSmF2YXNjcmlwdCB1c2luZyB0aGlzPGJyPg0KJmd0 OyBBUEk8YnI+DQomZ3Q7IC0gSXQgZXhwb3NlcyBhbGwgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eSB0 byB0aGUgSmF2YXNjcmlwdCBhcyBTRFAsIGJ1dCBpbiBhPGJyPg0KJmd0OyBtdWNoIG5pY2VyIGZv cm1hdCB0aGF0IGlzIG11Y2ggZWFzaWVyIHRvIHdvcmsgd2l0aC48YnI+DQomZ3Q7IC0gQW55IG90 aGVyIHNpZ25hbGxpbmcgbWVjaGFuaXNtLCBzdWNoIGFzIEppbmdsZSBvciBDTFVFIGNvdWxkIGJl PGJyPg0KJmd0OyBpbXBsZW1lbnRlZCB1c2luZyB0aGlzIEFQSS48YnI+DQomZ3Q7IC0gVGhlcmUg aXMgYWxtb3N0IG5vIHJpc2sgb2Ygc2lnbmFsbGluZyBnbGFyZS48YnI+DQomZ3Q7IC0gRGVidWdn aW5nIGVycm9ycyB3aXRoIG1pc2NvbmZpZ3VyZWQgZGVzY3JpcHRpb25zIHNob3VsZCBiZSBtdWNo IGVhc2llcjxicj4NCiZndDsgd2l0aCB0aGlzIHRoYW4gd2l0aCBsYXJnZSBTRFAgYmxvYnMuPGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IENvbnM6PGJyPg0KJmd0Ozxicj4NCiZndDsgLSBO b3cgdGhlcmUgYXJlIHR3byBzbGlnaHRseSBkaWZmZXJlbnQgd2F5cyB0byBhZGQgc3RyZWFtczog YnkgY3JlYXRpbmcgYTxicj4NCiZndDsgTG9jYWxNZWRpYVN0cmVhbSBmaXJzdCwgYW5kIG5vdC4g Jm5ic3A7VGhpcyBpcywgaG93ZXZlciwgYW5hbG9nb3VzIHRvIHNldHRpbmc8YnI+DQomZ3Q7ICZx dW90O25lZ290aWF0ZWQ6IHRydWUmcXVvdDsgaW4gY3JlYXRlRGF0YUNoYW5uZWwuICZuYnNwO09u IHdheSBpcyAmcXVvdDtKdXN0IFdvcmsmcXVvdDssIGFuZCB0aGU8YnI+DQomZ3Q7IG90aGVyIGlz IG1vcmUgYWR2YW5jZWQgY29udHJvbC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtIEFsbCB0aGUgb3B0 aW9ucyBpbiBNZWRpYUNvZGVjRGVzY3JpcHRpb24gYXJlIGEgYml0IGNvbXBsaWNhdGVkLiAmbmJz cDtSZWFsbHksPGJyPg0KJmd0OyB0aGlzIGlzIG9ubHkgbmVjZXNzYXJ5IGJlY2F1c2UgUGxhbiBB IHJlcXVpcmVzIGJlaW5nIGFibGUgdG8gc3BlY2lmeSBjb2RlYzxicj4NCiZndDsgcGFyYW1ldGVy cyBwZXIgU1NSQywgYW5kIHNldCBlYWNoIGZsb3cgb24gZGlmZmVyZW50IHRyYW5zcG9ydHMuICZu YnNwO0lmIHdlIGRpZDxicj4NCiZndDsgbm90IGhhdmUgdGhpcyByZXF1aXJlbWVudCwgd2UgY291 bGQgc2ltcGxpZnkuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEV4YW1wbGUgVXNhZ2U6 PGJyPg0KJmd0Ozxicj4NCiZndDsgLy8gSW1hZ2luZSBJIGhhdmUgTXlBcHAsIGhhbmRsZXMgY3Jl YXRpbmcgYSBQZWVyQ29ubmVjdGlvbiw8YnI+DQomZ3Q7IC8vIHNpZ25hbGxpbmcsIGFuZCByZW5k ZXJpbmcgc3RyZWFtcy4gJm5ic3A7VGhpcyBpcyBob3cgdGhlIG5ldyBBUEkgY291bGQgYmU8YnI+ DQomZ3Q7IC8vIHVzZWQuPGJyPg0KJmd0OyB2YXIgcGVlckNvbm5lY3Rpb24gPSBNeUFwcC5jcmVh dGVQZWVyQ29ubmVjdGlvbigpOzxicj4NCiZndDs8YnI+DQomZ3Q7IC8vIE9uIHNlbmRlciBzaWRl Ojxicj4NCiZndDsgdmFyIHN0cmVhbSA9IE15QXBwLmdldE1lZGlhU3RyZWFtKCk7PGJyPg0KJmd0 OyB2YXIgbG9jYWxTdHJlYW0gPSBwZWVyQ29ubmVjdGlvbi5jcmVhdGVTZW5kU3RyZWFtKHN0cmVh bSk7PGJyPg0KJmd0OyBzZW5kU3RyZWFtLmRlc2NyaXB0aW9uID0gTXlBcHAubW9kaWZ5U3RyZWFt KGxvY2FsU3RyZWFtLmRlc2NyaXB0aW9uKTxicj4NCiZndDsgTXlBcHAuc2lnbmFsQWRkU3RyZWFt KGxvY2FsU3RyZWFtLmRlc2NyaXB0aW9uLCBmdW5jdGlvbihyZXNwb25zZSkpIHs8YnI+DQomZ3Q7 ICZuYnNwOyBpZiAoIXJlc3BvbnNlLnJlamVjdGVkKSB7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 IC8vIE1lZGlhIHdpbGwgbm90IGJlIHNlbnQuPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHBlZXJD b25uZWN0aW9uLmFkZFN0cmVhbShsb2NhbFN0cmVhbSk7PGJyPg0KJmd0OyAmbmJzcDsgfTxicj4N CiZndDsgfTxicj4NCiZndDs8YnI+DQomZ3Q7IC8vIE9uIHJlY2VpdmVyIHNpZGU6PGJyPg0KJmd0 OyBNeUFwcC5vbkFkZFN0cmVhbVNpZ25hbGxlZCA9IGZ1bmN0aW9uKHN0cmVhbURlc2NyaXB0aW9u KSB7PGJyPg0KJmd0OyAmbmJzcDsgdmFyIHN0cmVhbSA9IHBlZXJDb25uZWN0aW9uLmNyZWF0ZVJl Y2VpdmVTdHJlYW0oc3RyZWFtRGVzY3JpcHRpb24pOzxicj4NCiZndDsgJm5ic3A7IE15QXBwLnJl bmRlclN0cmVhbShzdHJlYW0pOzxicj4NCiZndDsgfTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0OyAvLyBJbiB0aGlzIGV4Y2hhbmdlLCB0aGUgTWVkaWFTdHJlYW1EZXNjcmlwdGlvbiBzaWdu YWxsZWQgZnJvbSB0aGU8YnI+DQomZ3Q7IC8vIHNlbmRlciB0byB0aGUgcmVjZWl2ZXIgbWF5IGhh dmUgbG9va2VkIHNvbWV0aGluZyBsaWtlIHRoaXM6PGJyPg0KJmd0Ozxicj4NCiZndDsgezxicj4N CiZndDsgJm5ic3A7IHRyYWNrczogWzxicj4NCiZndDsgJm5ic3A7IHs8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgaWQ6ICZxdW90O2F1ZGlvMSZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg a2luZDogJnF1b3Q7YXVkaW8mcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGZsb3dzOiBb PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IGlkOiAmcXVvdDttYWluJnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHJh bnNwb3J0SWQ6ICZxdW90O3RyYW5zcG9ydDEmcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBzc3JjOiAxMTExLDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29kZWNz OiBbPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB7PGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgcGF5bG9hZFR5cGU6IDExMSw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBuYW1lOiAmcXVvdDtvcHVzJnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC8vIC4uLiBtb3JlIGNvZGVjIGRldGFpbHM8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH0sPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB7 PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcGF5bG9hZFR5cGU6IDExMiw8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBuYW1lOiAmcXVvdDtwY211JnF1 b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC8vIC4uLiBtb3JlIGNv ZGVjIGRldGFpbHM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH1dPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7fV08YnI+DQomZ3Q7ICZuYnNwO30sPGJyPg0KJmd0OyAmbmJzcDt7PGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7IGlkOiAmcXVvdDt2aWRlbzEmcXVvdDssPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7IGtpbmQ6ICZxdW90O3ZpZGVvJnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyBmbG93czogWzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB7PGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBpZDogJnF1b3Q7c2ltMCZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHRyYW5zcG9ydElkOiAmcXVvdDt0cmFuc3BvcnQyJnF1b3Q7LDxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgc3NyYzogMjIyMiw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IGNvZGVjczogWzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgezxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHBheWxvYWRUeXBlOiAxMjIsPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbmFtZTogJnF1b3Q7dnA4JnF1b3Q7PGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLy8gLi4uIG1vcmUgY29kZWMgZGV0YWlsczxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfV08YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt9 LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3s8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 aWQ6ICZxdW90O3NpbTEmcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RyYW5z cG9ydElkOiAmcXVvdDt0cmFuc3BvcnQyJnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtzc3JjOiAyMjIzLDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb2RlY3M6IFs8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ezxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7cGF5bG9hZFR5cGU6IDEyMiw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO25hbWU6ICZxdW90O3ZwOCZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOy8vIC4uLiBtb3JlIGNvZGVjIGRldGFpbHM8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fV08YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt9LDxicj4NCiZndDsgJm5ic3A7 ICZuYnNwO3s8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aWQ6ICZxdW90O3NpbTImcXVv dDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RyYW5zcG9ydElkOiAmcXVvdDt0cmFu c3BvcnQyJnF1b3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzc3JjOiAyMjI0LDxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb2RlY3M6IFs8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ezxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGF5bG9h ZFR5cGU6IDEyMiw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO25hbWU6ICZx dW90O3ZwOCZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy8vIC4u LiBtb3JlIGNvZGVjIGRldGFpbHM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fV08YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDt9LDxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt7 PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lkOiAmcXVvdDtzaW0wZmVjJnF1b3Q7LDxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0cmFuc3BvcnRJZDogJnF1b3Q7dHJhbnNwb3J0 MiZxdW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3NyYzogMjIyNSw8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29kZWNzOiBbPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3s8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BheWxvYWRUeXBl OiAxMjIsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtuYW1lOiAmcXVvdDt2 cDgmcXVvdDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvLyAuLi48YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fV08YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt9XSw8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtmbG93R3JvdXBzOiBbPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ezxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZW1hbnRpY3M6ICZxdW90O1NJTSZx dW90Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3NyY3M6IFsyMjIyLCAyMjIzLCAy MjI0XTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO30sPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ezxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZW1hbnRpY3M6ICZxdW90O0ZFQyZxdW90Oyw8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3NyY3M6IFsyMjIyLCAyMjI1XTxicj4NCiZn dDsgJm5ic3A7ICZuYnNwO31dPGJyPg0KJmd0OyAmbmJzcDt9XTxicj4NCiZndDsgfTxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBDb25zdHJ1Y3RpdmUgZmVlZGJhY2sgaXMgd2VsY29tZSA6 KS48YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KJmd0 OyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2Vi QGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C59AETK5EX14MBXC273r_-- From matthew.kaufman@skype.net Mon Jun 17 18:46:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288B921F9BB5 for ; Mon, 17 Jun 2013 18:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCOTZuxc4rii for ; Mon, 17 Jun 2013 18:46:19 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id B1A1621F9BB3 for ; Mon, 17 Jun 2013 18:46:18 -0700 (PDT) Received: from BN1BFFO11FD010.protection.gbl (10.58.52.200) by BN1BFFO11HUB007.protection.gbl (10.58.53.117) with Microsoft SMTP Server (TLS) id 15.0.707.0; Tue, 18 Jun 2013 01:41:58 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD010.mail.protection.outlook.com (10.58.53.70) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 18 Jun 2013 01:41:57 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.171]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0136.001; Tue, 18 Jun 2013 01:41:56 +0000 From: "Matthew Kaufman (SKYPE)" To: Roman Shpount , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) Thread-Index: AQHOa1pL3f2CtN2bTEydXd59L0Jyj5k6QmQAgAADZACAACVgAIAACRAAgAACKICAADwiIA== Date: Tue, 18 Jun 2013 01:41:55 +0000 Message-ID: References: <51BF5F00.90705@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.75] Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C59D2TK5EX14MBXC273r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(377454002)(24454002)(199002)(47976001)(50986001)(55846006)(33656001)(76482001)(56816003)(47736001)(74876001)(16406001)(59766001)(80022001)(16236675002)(71186001)(20776003)(4396001)(53806001)(54316002)(77096001)(74366001)(6806003)(81542001)(65816001)(74502001)(74662001)(69226001)(81342001)(74706001)(66066001)(54356001)(561944002)(76786001)(79102001)(512934002)(77982001)(76796001)(46102001)(51856001)(56776001)(47446002)(31966008)(49866001)(63696002); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB007; H:TK5EX14HUBC107.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0881A7A935 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 01:46:38 -0000 --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C59D2TK5EX14MBXC273r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Inline below Matthew Kaufman From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Roman Shpount Sent: Monday, June 17, 2013 3:04 PM To: I=F1aki Baz Castillo Cc: Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sou= rces without encoding them in SDP) On Mon, Jun 17, 2013 at 5:56 PM, I=F1aki Baz Castillo > wrote: What is the aim of NoPlan? The draft says "This document does not question the use of SDP and the Offer/Answer model". Why? It should question it since it treats SDP as if it was a silly and unmanageable binary blob. It is like "we must live with SDP because it is mandatory, but let's try to ignore it as much as possible". If so, why don't ignore SDP entirely? However NoPlan is the best we have if, finally, SDP is mandated in WebRTC. I think it is time to write two lists: 1) Advantages of using SDP in WebRTC. Somebody wrote a bunch of code based on JSEP. MK: And some other people thought that using SDP offer/answer would magical= ly get full interoperability with existing SIP+SDP O/A systems. 2) Dissadvantages of using SPD in WebRTC. An unmanageable monster was created which currently stays in the way of dev= eloping new functionality (bundle), building applications (does not provide= obvious ways to implement obvious tasks, like adding an extra stream witho= ut re-negotiating all the existing ones) and even interop with existing SIP= endpoints (which was the original but now is complicated since it would re= quire a non trivial set of constraints and subsequent SDP manipulation). MK: Pretty much sums it up, including the fallacy of SIP interop. And note = that the SIP interop issue isn't just that there's no SIP systems that have= ICE (which we need to protect people from their browser) and DTLS-SRTP (wh= ich we need if we don't get SRTP w/SDES)... in fact there's a draft summari= zing many (but not all) of the *other* things that don't interoperate betwe= en the two without SDP mangling. _____________ Roman Shpount --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C59D2TK5EX14MBXC273r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Inline below

     <= /p>

    Matthew Kaufman

     <= /p>

    From: rtcweb= -bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
    Sent: Monday, June 17, 2013 3:04 PM
    To: I=F1aki Baz Castillo
    Cc: <rtcweb@ietf.org>
    Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multi= ple sources without encoding them in SDP)

     

    On Mon, Jun 17, 2013 at 5:56 PM, I=F1aki Baz Castill= o <ibc@aliax.net&= gt; wrote:


    What is the aim of NoPlan? The draft says "This document does not
    question the use of SDP and the Offer/Answer model". Why? It should question it since it treats SDP as if it was a silly and unmanageable
    binary blob. It is like "we must live with SDP because it is
    mandatory, but let's try to ignore it as much as possible". If so, why=
    don't ignore SDP entirely?

    However NoPlan is the best we have if, finally, SDP is mandated in WebRTC.<= br>
    I think it is time to write two lists:

    1) Advantages of using SDP in WebRTC.

     

    Somebody wrote a bunch of code based on JSEP.  =

     <= /p>

    MK: And some other people= thought that using SDP offer/answer would magically get full interoperabil= ity with existing SIP+SDP O/A systems.

     

    2) Dissadvantages of using SPD in WebRTC.=

     

    An unmanageable monster was created which currently = stays in the way of developing new functionality (bundle), building applica= tions (does not provide obvious ways to implement obvious tasks, like addin= g an extra stream without re-negotiating all the existing ones) and even interop with existing SIP endpoints (which= was the original but now is complicated since it would require a non trivi= al set of constraints and subsequent SDP manipulation). 

     <= /p>

    MK: Pretty much sums it u= p, including the fallacy of SIP interop. And note that the SIP interop issu= e isn’t just that there’s no SIP systems that have ICE (which we need to protect people from their browser) and DTLS-SRTP (which we need= if we don’t get SRTP w/SDES)… in fact there’s a draft su= mmarizing many (but not all) of the *other* things that don’t = interoperate between the two without SDP mangling.

     <= /p>

    _____________


    Roman Shpount

     

    --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C59D2TK5EX14MBXC273r_-- From robin@hookflash.com Mon Jun 17 19:54:40 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D086D11E80C5 for ; Mon, 17 Jun 2013 19:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eD2UDSthybY for ; Mon, 17 Jun 2013 19:54:38 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEA621F9C22 for ; Mon, 17 Jun 2013 19:54:38 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id a13so8865635iee.34 for ; Mon, 17 Jun 2013 19:54:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=7oSltqAMnlNEWENS5ngXAOhQotY79JrxTWeLKqyUnqk=; b=hO6bd4sc5s0ZHHZx9GYh/oWM07chyEl/u2bHc009IPEfkn7Nvvh+QPsRzS/pnz34jT ZfJtCBdVhMq6c0gcc2GtCr+Y/t0o5f3RNbiypCxd55dkisl/eZRSBNwjn1XgHWicfQvN TuvaPGvbIatnQH+k0uxB6QHyYFlzfO0anCt1ZY9/Yn95+wFhgE20RwdgG4STpp4lB9Ws Y4Hk6+qL/a3s1XERZFhuMPiqLv3Fn7tJHj3AHhHMd3PNaoHVcaT2eoR89/dVNM1rM2ch Kl/jPWgN8LHrwtnIalpaRLGFiRyzHjyDKa0cX8Ufvu1zFQpvR7RlHgO+ujN4ELGbAKpR CERw== X-Received: by 10.50.131.161 with SMTP id on1mr6594192igb.112.1371524077886; Mon, 17 Jun 2013 19:54:37 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id y11sm20179622igy.10.2013.06.17.19.54.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Jun 2013 19:54:36 -0700 (PDT) Message-ID: <51BFCBE9.5070406@hookflash.com> Date: Mon, 17 Jun 2013 22:54:33 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Silvia Pfeiffer References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090100000502080103010206" X-Gm-Message-State: ALoCoQlEyaBGFTHh17d5+I5Zfc4luJe03ejBRAV1kAedVlQ8cx6fTvUwo01bkVUO4J1yguVDXufA Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 02:54:41 -0000 This is a multi-part message in MIME format. --------------090100000502080103010206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I actually need access to the raw controls like SSRC, detailed ICE candidate control, encryption keying, etc, and as much control over how media should be controlled/behave as possible. Those things are extremely important for interoperability and signaling and have specific meaning for those who deal with that kind of stuff daily. However, as a JavaScript developer, you likely need a simple high level API. Why should you care about all that low level junk? It's meaningless nonsense to you. Real-Time Communication is hard because there is a lot involved, especially if there is any kind of compatibility, advanced features or network control. Nobody wants a difficult API for the sake of being difficult, especially for a sleek language like JavaScript. It's more that it's just necessary if we audio/video people want to do some really cool features that work with new or existing platforms, devices and services. But we can have the best of both worlds! There are many people who are in this RTC domain who can wrap that lower level API to give very simple and easy to understand conceptual APIs that abstract that weird funky stuff away. I'd be one of those people to offer such a simpler library (along with many others I'm sure). In some way, it's not all that dissimilar with DOM and CSS3, etc.; jQuery and jQuery UI (and other libraries) create wrappers to make access and control easier but for those who need to raw control they have it. Most people use wrappers and toolkits when they are trying to do the standard stuff, but someone put together the APIs originally to make common use cases. On a side note, I agree that SDP should go (and quickly) but it's not the format that's the problem. Granted, it is obtuse. But it's not just that; it's a monolithic do-everything offer/answer model that offers very little control and the API to control the browser's RTC is effectively via manipulation of the SDP. Yuck! Even if it were fancier and prettier JSON, it would still be an ugly do-everything monolithic object with a sketchy offer/answer model that is brittle and offered very little real-scenario controls for those whom need it. It's absolutely horrible and is in good need of quick deprecation. -Robin > Silvia Pfeiffer > 17 June, 2013 9:00 PM > Hi Peter, all, > > I'm looking at all this from the view of a JS developer and I am > really excited that there is movement in this space. Having hit my > head hard against the limitations of the current WebRTC API and being > forced to learn SDP to achieve some of the less common use cases, I'm > feeling the pain. I am therefore happy to see that there is a proposal > for a higher-level API with similarities to the Microsoft's CU-WebRTC > proposal and I hope that together with Microsoft's input this can > become a really useful API. > > What I would like to see, though, is a bit different from what you've > proposed. In particular, the MediaFlowDescription object is the one > object that I believe is supposed to enable JS developers to do "SDP > hacking" without having to understand SDP. Unfortunately, the way in > which it is currently written, this API doesn't help a JS developer > much. There are properties in that object like "ssrc" that mean > nothing unless you understand SDP. > > I would therefore like to recommend making the properties on the > MediaFlowDescription more semantic - in particular giving them better > names - such that a JS developer really doesn't have to understand SDP > to create/change media flow descriptions. Can we find better names for > id, transportId and ssrc that are more explicitly expressing what > they stand for and when a JS developer would actually change them? > > It would be nice if the MediaFlowDescription was abstract enough such > that in future it doesn't matter if SDP is actually underneath (with > offer/answer), but that's not actually my main goal. What I'm after is > an API that can be used without having to understand what is > underneath. > > Thanks for listening and HTH, > Silvia. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Peter Thatcher > 17 June, 2013 8:57 AM > Google is in full support of "Plan B" for encoding multiple media > sources in SDP, and would like to see the Plan A vs. Plan B decision > resolved soon. Recently, though, a third option, called "NoPlan" has > been proposed, but it lacked the details of what a JS API would look > like for NoPlan. Cullen asked to see such an API proposal, and so I > have worked with Emil to make one. He will be adding it to the NoPlan > draft, but I will also include it in this email. > > Again, Google is in full support of "Plan B". But if Plan A vs. Plan > B cannot be decided, then we support NoPlan with the following > additions to the WebRTC JS API as an option that allows implementing > either Plan A or Plan B in Javascript. And even if Plan A vs. Plan B > is resolved, these API additions would still be a big improvement for > those WebRTC applications that don't use SDP for signalling. > > It is a bit long because I have added many comments and examples, but > the actually additions only include two new methods on PeerConnection > and a few new dictionaries. So don't be overwhelmed :). > > > > Intro: This follows the model of createDataChannel, which has a JS > method on PeerConnection that makes it possible to add data channels > without going through SDP. Furthermore, just like createDataChannel > allows 2 ways to handle neogitation (the "I know what I'm doing; > Here's what I want to send; Let me signal everything" mode and the > "please take care of it for me; send an OPEN message" mode), this > also has 2 ways to handle negotiation (the "I know what I'm doing; > Here's what I want to send; Let me signal everything" mode and the > "please take care of it for me; send SDP back and forth" mode). > > Following the success of createDataChannel, this allows simple > applications to Just Work and more advanced applications to easily > control what they need to. In particular, it's possible to use this > API to implement either Plan A or Plan B. > > // The following two method are added to RTCPeerConnection > partial interface RTCPeerConnection { > // Create a stream that is used to send a source stream. > // The MediaSendStream.description can be used for signalling. > // No media is sent until addStream(MediaSendStream) is called. > LocalMediaStream createLocalStream(MediaStream sourceStream); > > // Create a stream that is used to receive media from the remote side, > // given the parameters signalled from MedaiSendStream.description. > MediaStream createRemoteStream(MediaStreamDescription description); > } > > > interface LocalMediaStream implements MediaStream { > // This can be changed at any time, but especially before calling > // PeerConnection.addStream > attribute MediaStreamDescription description; > } > > > // Represents the parameters used to either send or receive a stream > // over a PeerConnection. > dictionary MediaStreamDescription { > MediaStreamTrackDescription[] tracks; > } > > > // Represents the parameters used to either send or receive a track > over // a PeerConnection. A track has many "flows", which can be grouped > // together. > dictionary MediaStreamTrackDescription { > // Same as the MediaStreamTrack.id > DOMString id; > > // Same as the MediaStreamTrack.kind > DOMString kind; > > // A track can have many "flows", such as for Simulcast, FEC, etc. > // And they can be grouped in arbitrary ways. > MediaFlowDescription[] flows; > MediaFlowGroup[] flowGroups; > } > > // Represents the parameters used to either send or receive a "flow" > // over a PeerConnection. A "flow" is a media that arrives with a > // single, unique SSRC. One to many flows together make up the media > // for a track. For example, there may be Simulcast, FEC, and RTX > // flows. > dictionay MediaFlowDescription { > // The "flow id" must be unique to the track, but need not be unique > // outside of the track (two tracks could both have a flow with the > // same flow ID). > DOMString id; > > // Each flow can go over its own transport. If the JS sets this to a > // transportId that doesn't have a transport setup already, the > // browser will use SDP negotiation to setup a transport to back that > // transportId. If This is set to an MID in the SDP, then that MID's > // transport is used. > DOMString transportId; > > // The SSRC used to send the flow. > unsigned int ssrc; > > // When used as receive parameters, this indicates the possible list > // of codecs that might come in for this flow. For exmample, a given > // receive flow could be setup to receive any of OPUS, ISAC, or PCMU. > // When used as send parameters, this indicates that the first codec > // should be used, but the browser can use send other codecs if it > // needs to because of either bandwidth or CPU constraints. > MediaCodecDescription[] codecs; > } > > > dictionary MediaFlowGroup { > DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc > DOMString[] flowids; > } > > dictionary MediaCodecDescription { > unsigned byte payloadType; > DOMString name; > unsigned int? clockRate; > unsigned int? bitRate; > // A grab bag of other fmtp that will need to be further defined. > MediaCodecParam[] params; > } > > dictionary MediaCodecParam { > DOMString key; > DOMString value; > } > > > Notes: > > - When LocalMediaStreams are added using addStream, onnegotiatedneeded > is not called, and those streams are never reflected in future SDP > exchanges. Indeed, it would be impossible to put them in the SDP > without first resolving if that would be Plan A SDP or Plan B SDP. > > - Just like piles of attributes would need to be defined for Plan A > and for Plan B, similar attributes would need to be defined here > (Luckily, much work has already been done figuring out what those > parameters are :). > > > Pros: > > - Either Plan A or Plan B or could be implemented in Javascript using > this API > - It exposes all the same functionality to the Javascript as SDP, but > in a much nicer format that is much easier to work with. > - Any other signalling mechanism, such as Jingle or CLUE could be > implemented using this API. > - There is almost no risk of signalling glare. > - Debugging errors with misconfigured descriptions should be much > easier with this than with large SDP blobs. > > > Cons: > > - Now there are two slightly different ways to add streams: by > creating a LocalMediaStream first, and not. This is, however, > analogous to setting "negotiated: true" in createDataChannel. On way > is "Just Work", and the other is more advanced control. > > - All the options in MediaCodecDescription are a bit complicated. > Really, this is only necessary because Plan A requires being able to > specify codec parameters per SSRC, and set each flow on different > transports. If we did not have this requirement, we could simplify. > > > Example Usage: > > // Imagine I have MyApp, handles creating a PeerConnection, > // signalling, and rendering streams. This is how the new API could be > // used. > var peerConnection = MyApp.createPeerConnection(); > > // On sender side: > var stream = MyApp.getMediaStream(); > var localStream = peerConnection.createSendStream(stream); > sendStream.description = MyApp.modifyStream(localStream.description) > MyApp.signalAddStream(localStream.description, function(response)) { > if (!response.rejected) { > // Media will not be sent. > peerConnection.addStream(localStream); > } > } > > // On receiver side: > MyApp.onAddStreamSignalled = function(streamDescription) { > var stream = peerConnection.createReceiveStream(streamDescription); > MyApp.renderStream(stream); > } > > > // In this exchange, the MediaStreamDescription signalled from the > // sender to the receiver may have looked something like this: > > { > tracks: [ > { > id: "audio1", > kind: "audio", > flows: [ > { > id: "main", > transportId: "transport1", > ssrc: 1111, > codecs: [ > { > payloadType: 111, > name: "opus", > // ... more codec details > }, > { > payloadType: 112, > name: "pcmu", > // ... more codec details > }] > }] > }, > { > id: "video1", > kind: "video", > flows: [ > { > id: "sim0", > transportId: "transport2", > ssrc: 2222, > codecs: [ > { > payloadType: 122, > name: "vp8" > // ... more codec details > }] > }, > { > id: "sim1", > transportId: "transport2", > ssrc: 2223, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... more codec details > }] > }, > { > id: "sim2", > transportId: "transport2", > ssrc: 2224, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... more codec details > }] > }, > > { > id: "sim0fec", > transportId: "transport2", > ssrc: 2225, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... > }] > }], > flowGroups: [ > { > semantics: "SIM", > ssrcs: [2222, 2223, 2224] > }, > { > semantics: "FEC", > ssrcs: [2222, 2225] > }] > }] > } > > > Constructive feedback is welcome :). > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------090100000502080103010206 Content-Type: multipart/related; boundary="------------010705040703050208030401" --------------010705040703050208030401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    I actually need access to the raw controls like SSRC, detailed ICE candidate control, encryption keying, etc, and as much control over how media should be controlled/behave as possible. Those things are extremely important for interoperability and signaling and have specific meaning for those who deal with that kind of stuff daily.

    However, as a JavaScript developer, you likely need a simple high level API. Why should you care about all that low level junk? It's meaningless nonsense to you.

    Real-Time Communication is hard because there is a lot involved, especially if there is any kind of compatibility, advanced features or network control. Nobody wants a difficult API for the sake of being difficult, especially for a sleek language like JavaScript. It's more that it's just necessary if we audio/video people want to do some really cool features that work with new or existing platforms, devices and services.

    But we can have the best of both worlds! T    here are many people who are in this RTC domain who can wrap that lower level API to give very simple and easy to understand conceptual APIs that abstract that weird funky stuff away. I'd be one of those people to offer such a simpler library (along with many others I'm sure).

    In some way, it's not all that dissimilar with DOM and CSS3, etc.; jQuery and jQuery UI (and other libraries) create wrappers to make access and control easier but for those who need to raw control they have it. Most people use wrappers and toolkits when they are trying to do the standard stuff, but someone put together the APIs originally to make common use cases.

    On a side note, I agree that SDP should go (and quickly) but it's not the format that's the problem. Granted, it is obtuse. But it's not just that; it's a monolithic do-everything offer/answer model that offers very little control and the API to control the browser's RTC is effectively via manipulation of the SDP. Yuck! Even if it were fancier and prettier JSON, it would still be an ugly do-everything monolithic object with a sketchy offer/answer model that is brittle and offered very little real-scenario controls for those whom need it. It's absolutely horrible and is in good need of quick deprecation.

    -Robin




    17 June, 2013 9:00 PM
    Hi Peter, all,

    I'm looking at all this from the view of a JS developer and I am
    really excited that there is movement in this space. Having hit my
    head hard against the limitations of the current WebRTC API and being
    forced to learn SDP to achieve some of the less common use cases, I'm
    feeling the pain. I am therefore happy to see that there is a proposal
    for a higher-level API with similarities to the Microsoft's CU-WebRTC
    proposal and I hope that together with Microsoft's input this can
    become a really useful API.

    What I would like to see, though, is a bit different from what you've
    proposed. In particular, the MediaFlowDescription object is the one
    object that I believe is supposed to enable JS developers to do "SDP
    hacking" without having to understand SDP. Unfortunately, the way in
    which it is currently written, this API doesn't help a JS developer
    much. There are properties in that object like "ssrc" that mean
    nothing unless you understand SDP.

    I would therefore like to recommend making the properties on the
    MediaFlowDescription more semantic - in particular giving them better
    names - such that a JS developer really doesn't have to understand SDP
    to create/change media flow descriptions. Can we find better names for
    id, transportId and ssrc that are more explicitly expressing what
    they stand for and when a JS developer would actually change them?

    It would be nice if the MediaFlowDescription was abstract enough such
    that in future it doesn't matter if SDP is actually underneath (with
    offer/answer), but that's not actually my main goal. What I'm after is
    an API that can be used without having to understand what is
    underneath.

    Thanks for listening and HTH,
    Silvia.

    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    17 June, 2013 8:57 AM
    Google is in full support of "Plan B" for encoding multiple media sources in SDP, and would like to see the Plan A vs. Plan B decision resolved soon.  Recently, though, a third option, called "NoPlan" has been proposed, but it lacked the details of what a JS API would look like for NoPlan.  Cullen asked to see such an API proposal, and so I have worked with Emil to make one.  He will be adding it to the NoPlan draft, but I will also include it in this email.

    Again, Google is in full support of "Plan B".  But if Plan A vs. Plan B cannot be decided, then we support NoPlan with the following additions to the WebRTC JS API as an option that allows implementing either Plan A or Plan B  in Javascript.  And even if Plan A vs. Plan B is resolved, these API additions would still be a big improvement for those WebRTC applications that don't use SDP for signalling.

    It is a bit long because I have added many comments and examples, but the actually additions only include two new methods on PeerConnection and a few new dictionaries.  So don't be overwhelmed :).



    Intro: This follows the model of createDataChannel, which has a JS method on PeerConnection that makes it possible to add data channels without going through SDP.  Furthermore, just like createDataChannel allows 2 ways to handle neogitation (the "I know what I'm doing;  Here's what I want to send; Let me signal everything" mode and the "please take care of it for me;  send an OPEN message" mode), this also has 2 ways to handle negotiation (the "I know what I'm doing; Here's what I want to send; Let me signal everything" mode and the "please take care of it for me;  send SDP back and forth" mode). 
     
    Following the success of createDataChannel, this allows simple applications to Just Work and more advanced applications to easily control what they need to.  In particular, it's possible to use this API to implement either Plan A or Plan B.

    // The following two method are added to RTCPeerConnection
    partial interface RTCPeerConnection {
     // Create a stream that is used to send a source stream.
     // The MediaSendStream.description can be used for signalling.
     // No media is sent until addStream(MediaSendStream) is called.
     LocalMediaStream createLocalStream(MediaStream sourceStream);

     // Create a stream that is used to receive media from the remote side,
     // given the parameters signalled from MedaiSendStream.description.
     MediaStream createRemoteStream(MediaStreamDescription description);
    }


    interface LocalMediaStream implements MediaStream {
      // This can be changed at any time, but especially before calling
      // PeerConnection.addStream
      attribute MediaStreamDescription description;
    }


    // Represents the parameters used to either send or receive a stream 
    // over a PeerConnection.
    dictionary MediaStreamDescription {
      MediaStreamTrackDescription[] tracks;
    }


    // Represents the parameters used to either send or receive a track over // a PeerConnection.  A track has many "flows", which can be grouped 
    // together.
    dictionary MediaStreamTrackDescription {
      // Same as the MediaStreamTrack.id
      DOMString id;

      // Same as the MediaStreamTrack.kind
      DOMString kind;  

      // A track can have many "flows", such as for Simulcast, FEC, etc.
      // And they can be grouped in arbitrary ways.
      MediaFlowDescription[] flows;
      MediaFlowGroup[] flowGroups;
    }

    // Represents the parameters used to either send or receive a "flow" 
    // over a PeerConnection.  A "flow" is a media that arrives with a 
    // single, unique SSRC.  One to many flows together make up the media 
    // for a track.  For example, there may be Simulcast, FEC, and RTX 
    // flows.
    dictionay MediaFlowDescription {
      // The "flow id" must be unique to the track, but need not be unique 
      // outside of the track (two tracks could both have a flow with the 
      // same flow ID).
      DOMString id;

      // Each flow can go over its own transport.  If the JS sets this to a
      // transportId that doesn't have a transport setup already, the 
      // browser will use SDP negotiation to setup a transport to back that 
      // transportId.  If This is set to an MID in the SDP, then that MID's 
      // transport is used.
      DOMString transportId;

      // The SSRC used to send the flow.
      unsigned int ssrc;

      // When used as receive parameters, this indicates the possible list 
      // of codecs that might come in for this flow.  For exmample, a given 
      // receive flow could be setup to receive any of OPUS, ISAC, or PCMU.
      // When used as send parameters, this indicates that the first codec 
      // should be used, but the browser can use send other codecs if it 
      // needs to because of either bandwidth or CPU constraints.
      MediaCodecDescription[] codecs;
    }


    dictionary MediaFlowGroup {
      DOMString type;  // "SIM" for Simulcast, "FEC" for FEC, etc
      DOMString[] flowids;
    }

    dictionary MediaCodecDescription {
      unsigned byte payloadType;
      DOMString name;
      unsigned int? clockRate;
      unsigned int? bitRate;
      // A grab bag of other fmtp that will need to be further defined.
      MediaCodecParam[] params;  
    }

    dictionary MediaCodecParam {
      DOMString key;
      DOMString value;
    }


    Notes:

    - When LocalMediaStreams are added using addStream, onnegotiatedneeded is not called, and those streams are never reflected in future SDP exchanges.  Indeed, it would be impossible to put them in the SDP without first resolving if that would be Plan A SDP or Plan B SDP.

    - Just like piles of attributes would need to be defined for Plan A and for Plan B, similar attributes would need to be defined here (Luckily,  much work has already been done figuring out what those parameters are :).


    Pros:

    - Either Plan A or Plan B or could be implemented in Javascript using this API
    - It exposes all the same functionality to the Javascript as SDP, but in a much nicer format that is much easier to work with.
    - Any other signalling mechanism, such as Jingle or CLUE could be implemented using this API.
    - There is almost no risk of signalling glare.
    - Debugging errors with misconfigured descriptions should be much easier with this than with large SDP blobs.


    Cons:

    - Now there are two slightly different ways to add streams: by creating a LocalMediaStream first, and not.  This is, however, analogous to setting "negotiated: true" in createDataChannel.  On way is "Just Work", and the other is more advanced control.

    - All the options in MediaCodecDescription are a bit complicated.  Really, this is only necessary because Plan A requires being able to specify codec parameters per SSRC, and set each flow on different transports.  If we did not have this requirement, we could simplify.


    Example Usage:

    // Imagine I have MyApp, handles creating a PeerConnection,
    // signalling, and rendering streams.  This is how the new API could be 
    // used.
    var peerConnection = MyApp.createPeerConnection();

    // On sender side:
    var stream = MyApp.getMediaStream();
    var localStream = peerConnection.createSendStream(stream);
    sendStream.description = MyApp.modifyStream(localStream.description)
    MyApp.signalAddStream(localStream.description, function(response)) {
      if (!response.rejected) {
        // Media will not be sent.
        peerConnection.addStream(localStream);
      }
    }

    // On receiver side:
    MyApp.onAddStreamSignalled = function(streamDescription) {
      var stream = peerConnection.createReceiveStream(streamDescription);
      MyApp.renderStream(stream);
    }


    // In this exchange, the MediaStreamDescription signalled from the 
    // sender to the receiver may have looked something like this:

    {
      tracks: [
      {
        id: "audio1",
        kind: "audio",
        flows: [
        {
              id: "main",
          transportId: "transport1",
          ssrc: 1111,
          codecs: [
          {
            payloadType: 111,
            name: "opus",
            // ... more codec details
          },
          { 
            payloadType: 112,
            name: "pcmu",
            // ... more codec details
          }]
       }]
     },
     {
        id: "video1",
        kind: "video",
        flows: [
        {
          id: "sim0",
          transportId: "transport2",
          ssrc: 2222,
          codecs: [
          {
            payloadType: 122,
            name: "vp8"
            // ... more codec details
          }]
       },
       {
         id: "sim1",
         transportId: "transport2",
         ssrc: 2223,
         codecs: [
         {
           payloadType: 122,
           name: "vp8",
               // ... more codec details
         }]
       },
       {
         id: "sim2",
         transportId: "transport2",
         ssrc: 2224,
         codecs: [
         {
           payloadType: 122,
           name: "vp8",
               // ... more codec details
         }]
       },

       {
         id: "sim0fec",
         transportId: "transport2",
         ssrc: 2225,
         codecs: [
         {
           payloadType: 122,
           name: "vp8",
           // ...
         }]
       }],
       flowGroups: [
       {
         semantics: "SIM",
         ssrcs: [2222, 2223, 2224]
       },
       {
         semantics: "FEC",
         ssrcs: [2222, 2225]
       }]
     }]
    }


    Constructive feedback is welcome :).
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    --------------010705040703050208030401 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwBvi7xtL/ZUvifVora/u5rGG8uJ57KKaWWW SJSSWZSeWbgdAMAYAAr1sRUhRw8pM86hGVauoo8kPxO8dWMMNx4l8JaTp1rPGJYnfR4XSRPX d5Yx+Ga+XoZn72krn0VXLVy6xPV/hh4z0vxVb2l/BDYRFLlIZBDawqyNkYKuqhlPOQQcg/Sv qsJiKeJpXR81iaMsNUsO/wCGlvjF/wBD9f8A/fKf/E1fsqfYXtZ9znYrhNetfDmmmRYDK2lY kf8AiZTD8uPfkfjXm5tb6jNtHblabxsEj3/xi2p6t4QPhe8+FqBPtDW0VqLmPe0eM+apxgew znFfn2GhHm02R+iVIS5Nj5U0TQL74VfGu48PNdRR6ZrUvmW0GGPkldjjkfKeTInH92vqstr+ yqxgup8lmmG5qcpvdHN/2qf+fpP++T/jX0/Mz5qxa8JalrnxI8baZ8IPCP7vVdPtlu7+eQGE Wf2SMNIGHXcrLgjAJbC9TXkZsnVw3s49WenlsPZVfay6H2Be/DHxM+g6LqvkardtrEUOoQG2 UujvIikjzCcIe3zcgZwcV8fQw1aM+XufbvN8O6PM3qj5e+OngXW/hl8cY/EWs3V1c21tb2d1 fy7t8NkWH+rDHouN3PdiT3r3IU3QrQ5dWrNnzlas8XCT2TukcB/wjPjL/on/AIl/8FE3/wAR Xu/Xo/ys8P6rLujoPFv/ACfR8Vf+uTf+i7esJ7I7I7P1PTvCP/Ig2H/Xsv8AM1wrdBUPM/Gv /JSdF/7CGhf+lcda0/iZcf4a+Z+qVUI//9k= --------------010705040703050208030401 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------010705040703050208030401-- --------------090100000502080103010206-- From silviapfeiffer1@gmail.com Mon Jun 17 20:27:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B945321F9446 for ; Mon, 17 Jun 2013 20:27:50 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCNKaVa7RSGR for ; Mon, 17 Jun 2013 20:27:48 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 69E8221F9B29 for ; Mon, 17 Jun 2013 20:27:48 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id n9so4325685oag.8 for ; Mon, 17 Jun 2013 20:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9IhBi/l5p2eAxmiifliGFfy4yo7qMbWVCrkq4ipOj5Y=; b=a4ebkrA7aDyWMlZ4leX/d/KdR623+uUlLVUZmnG3p4nobmleHVn/mXe+8863eCrGYW VGSWLpGk59YYTMveCX+Ce053TPOd3wUwPcS/f2plPCeq876UfZorxng14rJmTX8lEr5G n01h5nbou4zLET9++rfUI8vF8T/yoXC5Su5RM7nwcumxk3JEIR6chkLmkOv/IFc5EYxu R/QQIQi4gyjzpxDGQXFhoogVHV1p0gmKf3eESQ8J+vPSQDkqHNQsAkkfHJxF+kVNJQrl JFuCoC5mfPxfjavdUrT/VtAwm/KRm+78G9j1c6JLZowfQwORCaSU2OQOemzAx1K7gt4t 9onQ== X-Received: by 10.60.162.98 with SMTP id xz2mr10714836oeb.7.1371526067972; Mon, 17 Jun 2013 20:27:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.116.71 with HTTP; Mon, 17 Jun 2013 20:27:27 -0700 (PDT) In-Reply-To: <51BFCBE9.5070406@hookflash.com> References: <51BFCBE9.5070406@hookflash.com> From: Silvia Pfeiffer Date: Tue, 18 Jun 2013 13:27:27 +1000 Message-ID: To: Robin Raymond Content-Type: multipart/related; boundary=047d7b3a97a814f4e504df654c36 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 03:27:50 -0000 --047d7b3a97a814f4e504df654c36 Content-Type: multipart/alternative; boundary=047d7b3a97a814f4e404df654c35 --047d7b3a97a814f4e404df654c35 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 18, 2013 at 12:54 PM, Robin Raymond wrote: > > I actually need access to the raw controls like SSRC, detailed ICE > candidate control, encryption keying, etc, and as much control over how > media should be controlled/behave as possible. Those things are extremely > important for interoperability and signaling and have specific meaning for > those who deal with that kind of stuff daily. > Sure - but if you need to hack SDP directly, you're already able to do that. However, as a JavaScript developer, you likely need a simple high level > API. Why should you care about all that low level junk? It's meaningless > nonsense to you. > > Real-Time Communication is hard because there is a lot involved, > especially if there is any kind of compatibility, advanced features or > network control. Nobody wants a difficult API for the sake of being > difficult, especially for a sleek language like JavaScript. It's more that > it's just necessary if we audio/video people want to do some really cool > features that work with new or existing platforms, devices and services. > > But we can have the best of both worlds! > Agreed, that's what I'm after, but not as a library, but rather as part of the WebRTC API. > There are many people who are in this RTC domain who can wrap that lower > level API to give very simple and easy to understand conceptual APIs that > abstract that weird funky stuff away. I'd be one of those people to offer > such a simpler library (along with many others I'm sure). > I think you should write a proposal! > In some way, it's not all that dissimilar with DOM and CSS3, etc.; jQuery > and jQuery UI (and other libraries) create wrappers to make access and > control easier but for those who need to raw control they have it. Most > people use wrappers and toolkits when they are trying to do the standard > stuff, but someone put together the APIs originally to make common use > cases. > jQuery was necessary because HTML did not evolve. Now that a lot of the jQuery APIs have been added to HTML directly, you can even get away pretty well without using jQuery. On a side note, I agree that SDP should go (and quickly) but it's not the > format that's the problem. Granted, it is obtuse. But it's not just that; > it's a monolithic do-everything offer/answer model that offers very little > control and the API to control the browser's RTC is effectively via > manipulation of the SDP. Yuck! Even if it were fancier and prettier JSON, > it would still be an ugly do-everything monolithic object with a sketchy > offer/answer model that is brittle and offered very little real-scenario > controls for those whom need it. It's absolutely horrible and is in good > need of quick deprecation. > Right - by providing a higher level abstraction of it, you'd enable that stuff underneath to be replaced. I don't have a good handle on SDP, so but I think what is proposed can be improved. If you have any ideas on how to, this would be a good time to help out, IMHO. Cheers, Silvia. > -Robin > > > > > Silvia Pfeiffer > 17 June, 2013 9:00 PM > Hi Peter, all, > > I'm looking at all this from the view of a JS developer and I am > really excited that there is movement in this space. Having hit my > head hard against the limitations of the current WebRTC API and being > forced to learn SDP to achieve some of the less common use cases, I'm > feeling the pain. I am therefore happy to see that there is a proposal > for a higher-level API with similarities to the Microsoft's CU-WebRTC > proposal and I hope that together with Microsoft's input this can > become a really useful API. > > What I would like to see, though, is a bit different from what you've > proposed. In particular, the MediaFlowDescription object is the one > object that I believe is supposed to enable JS developers to do "SDP > hacking" without having to understand SDP. Unfortunately, the way in > which it is currently written, this API doesn't help a JS developer > much. There are properties in that object like "ssrc" that mean > nothing unless you understand SDP. > > I would therefore like to recommend making the properties on the > MediaFlowDescription more semantic - in particular giving them better > names - such that a JS developer really doesn't have to understand SDP > to create/change media flow descriptions. Can we find better names for > id, transportId and ssrc that are more explicitly expressing what > they stand for and when a JS developer would actually change them? > > It would be nice if the MediaFlowDescription was abstract enough such > that in future it doesn't matter if SDP is actually underneath (with > offer/answer), but that's not actually my main goal. What I'm after is > an API that can be used without having to understand what is > underneath. > > Thanks for listening and HTH, > Silvia. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Peter Thatcher > 17 June, 2013 8:57 AM > Google is in full support of "Plan B" for encoding multiple media sources > in SDP, and would like to see the Plan A vs. Plan B decision resolved soon. > Recently, though, a third option, called "NoPlan" has been proposed, but > it lacked the details of what a JS API would look like for NoPlan. Cullen > asked to see such an API proposal, and so I have worked with Emil to make > one. He will be adding it to the NoPlan draft, but I will also include it > in this email. > > Again, Google is in full support of "Plan B". But if Plan A vs. Plan B > cannot be decided, then we support NoPlan with the following additions to > the WebRTC JS API as an option that allows implementing either Plan A or > Plan B in Javascript. And even if Plan A vs. Plan B is resolved, these > API additions would still be a big improvement for those WebRTC > applications that don't use SDP for signalling. > > It is a bit long because I have added many comments and examples, but the > actually additions only include two new methods on PeerConnection and a few > new dictionaries. So don't be overwhelmed :). > > > > Intro: This follows the model of createDataChannel, which has a JS method > on PeerConnection that makes it possible to add data channels without going > through SDP. Furthermore, just like createDataChannel allows 2 ways to > handle neogitation (the "I know what I'm doing; Here's what I want to > send; Let me signal everything" mode and the "please take care of it for > me; send an OPEN message" mode), this also has 2 ways to handle > negotiation (the "I know what I'm doing; Here's what I want to send; Let me > signal everything" mode and the "please take care of it for me; send SDP > back and forth" mode). > > Following the success of createDataChannel, this allows simple > applications to Just Work and more advanced applications to easily control > what they need to. In particular, it's possible to use this API to > implement either Plan A or Plan B. > > // The following two method are added to RTCPeerConnection > partial interface RTCPeerConnection { > // Create a stream that is used to send a source stream. > // The MediaSendStream.description can be used for signalling. > // No media is sent until addStream(MediaSendStream) is called. > LocalMediaStream createLocalStream(MediaStream sourceStream); > > // Create a stream that is used to receive media from the remote side, > // given the parameters signalled from MedaiSendStream.description. > MediaStream createRemoteStream(MediaStreamDescription description); > } > > > interface LocalMediaStream implements MediaStream { > // This can be changed at any time, but especially before calling > // PeerConnection.addStream > attribute MediaStreamDescription description; > } > > > // Represents the parameters used to either send or receive a stream > // over a PeerConnection. > dictionary MediaStreamDescription { > MediaStreamTrackDescription[] tracks; > } > > > // Represents the parameters used to either send or receive a track over > // a PeerConnection. A track has many "flows", which can be grouped > // together. > dictionary MediaStreamTrackDescription { > // Same as the MediaStreamTrack.id > DOMString id; > > // Same as the MediaStreamTrack.kind > DOMString kind; > > // A track can have many "flows", such as for Simulcast, FEC, etc. > // And they can be grouped in arbitrary ways. > MediaFlowDescription[] flows; > MediaFlowGroup[] flowGroups; > } > > // Represents the parameters used to either send or receive a "flow" > // over a PeerConnection. A "flow" is a media that arrives with a > // single, unique SSRC. One to many flows together make up the media > // for a track. For example, there may be Simulcast, FEC, and RTX > // flows. > dictionay MediaFlowDescription { > // The "flow id" must be unique to the track, but need not be unique > // outside of the track (two tracks could both have a flow with the > // same flow ID). > DOMString id; > > // Each flow can go over its own transport. If the JS sets this to a > // transportId that doesn't have a transport setup already, the > // browser will use SDP negotiation to setup a transport to back that > // transportId. If This is set to an MID in the SDP, then that MID's > // transport is used. > DOMString transportId; > > // The SSRC used to send the flow. > unsigned int ssrc; > > // When used as receive parameters, this indicates the possible list > // of codecs that might come in for this flow. For exmample, a given > // receive flow could be setup to receive any of OPUS, ISAC, or PCMU. > // When used as send parameters, this indicates that the first codec > // should be used, but the browser can use send other codecs if it > // needs to because of either bandwidth or CPU constraints. > MediaCodecDescription[] codecs; > } > > > dictionary MediaFlowGroup { > DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc > DOMString[] flowids; > } > > dictionary MediaCodecDescription { > unsigned byte payloadType; > DOMString name; > unsigned int? clockRate; > unsigned int? bitRate; > // A grab bag of other fmtp that will need to be further defined. > MediaCodecParam[] params; > } > > dictionary MediaCodecParam { > DOMString key; > DOMString value; > } > > > Notes: > > - When LocalMediaStreams are added using addStream, onnegotiatedneeded is > not called, and those streams are never reflected in future SDP exchanges. > Indeed, it would be impossible to put them in the SDP without first > resolving if that would be Plan A SDP or Plan B SDP. > > - Just like piles of attributes would need to be defined for Plan A and > for Plan B, similar attributes would need to be defined here (Luckily, > much work has already been done figuring out what those parameters are :). > > > Pros: > > - Either Plan A or Plan B or could be implemented in Javascript using this > API > - It exposes all the same functionality to the Javascript as SDP, but in a > much nicer format that is much easier to work with. > - Any other signalling mechanism, such as Jingle or CLUE could be > implemented using this API. > - There is almost no risk of signalling glare. > - Debugging errors with misconfigured descriptions should be much easier > with this than with large SDP blobs. > > > Cons: > > - Now there are two slightly different ways to add streams: by creating a > LocalMediaStream first, and not. This is, however, analogous to setting > "negotiated: true" in createDataChannel. On way is "Just Work", and the > other is more advanced control. > > - All the options in MediaCodecDescription are a bit complicated. Really, > this is only necessary because Plan A requires being able to specify codec > parameters per SSRC, and set each flow on different transports. If we did > not have this requirement, we could simplify. > > > Example Usage: > > // Imagine I have MyApp, handles creating a PeerConnection, > // signalling, and rendering streams. This is how the new API could be > // used. > var peerConnection = MyApp.createPeerConnection(); > > // On sender side: > var stream = MyApp.getMediaStream(); > var localStream = peerConnection.createSendStream(stream); > sendStream.description = MyApp.modifyStream(localStream.description) > MyApp.signalAddStream(localStream.description, function(response)) { > if (!response.rejected) { > // Media will not be sent. > peerConnection.addStream(localStream); > } > } > > // On receiver side: > MyApp.onAddStreamSignalled = function(streamDescription) { > var stream = peerConnection.createReceiveStream(streamDescription); > MyApp.renderStream(stream); > } > > > // In this exchange, the MediaStreamDescription signalled from the > // sender to the receiver may have looked something like this: > > { > tracks: [ > { > id: "audio1", > kind: "audio", > flows: [ > { > id: "main", > transportId: "transport1", > ssrc: 1111, > codecs: [ > { > payloadType: 111, > name: "opus", > // ... more codec details > }, > { > payloadType: 112, > name: "pcmu", > // ... more codec details > }] > }] > }, > { > id: "video1", > kind: "video", > flows: [ > { > id: "sim0", > transportId: "transport2", > ssrc: 2222, > codecs: [ > { > payloadType: 122, > name: "vp8" > // ... more codec details > }] > }, > { > id: "sim1", > transportId: "transport2", > ssrc: 2223, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... more codec details > }] > }, > { > id: "sim2", > transportId: "transport2", > ssrc: 2224, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... more codec details > }] > }, > > { > id: "sim0fec", > transportId: "transport2", > ssrc: 2225, > codecs: [ > { > payloadType: 122, > name: "vp8", > // ... > }] > }], > flowGroups: [ > { > semantics: "SIM", > ssrcs: [2222, 2223, 2224] > }, > { > semantics: "FEC", > ssrcs: [2222, 2225] > }] > }] > } > > > Constructive feedback is welcome :). > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b3a97a814f4e404df654c35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Tue, Jun 18, 2013 at 12:54 PM, Robin = Raymond <robin@hookflash.com> wrote:

    I actually need access to the raw controls like SSRC, detailed ICE=20 candidate control, encryption keying, etc, and as much control over how=20 media should be controlled/behave as possible. Those things are=20 extremely important for interoperability and signaling and have specific meaning for those who deal with that kind of stuff daily.

    Sure - but if you need to hack SDP directly, you&= #39;re already able to do that.


    However, as a JavaScript develope= r, you likely need a simple high level=20 API. Why should you care about all that low level junk? It's meaningles= s nonsense to you.

    Real-Time Communication is hard because there is a lot involved,=20 especially if there is any kind of compatibility, advanced features or=20 network control. Nobody wants a difficult API for the sake of being=20 difficult, especially for a sleek language like JavaScript. It's more= =20 that it's just necessary if we audio/video people want to do some reall= y cool features that work with new or existing platforms, devices and=20 services.

    But we can have the best of both worlds!
    Agreed, that's what I'm after, but not as a library, bu= t rather as part of the WebRTC API.
    =A0
    There are many= =20 people who are in this RTC domain who can wrap that lower level API to=20 give very simple and=20 easy to understand conceptual APIs that abstract that weird funky stuff=20 away. I'd be one of those people to offer such a simpler library (along= =20 with many others I'm sure).

    I think you should write a proposal!
    =A0
    In some way, it's not a= ll that dissimilar with DOM and CSS3, etc.;=20 jQuery and jQuery UI (and other libraries) create wrappers to make=20 access and control easier but for those who need to raw control they=20 have it. Most people use wrappers and toolkits when they are trying to=20 do the standard stuff, but someone put together the APIs originally to=20 make common use cases.

    jQu= ery was necessary because HTML did not evolve. Now that a lot of the jQuery= APIs have been added to HTML directly, you can even get away pretty well w= ithout using jQuery.

    On a side note, I agree that SDP should go (and quickly)= but it's not=20 the format that's the problem. Granted, it is obtuse. But it's not = just=20 that; it's a monolithic do-everything offer/answer model that offers=20 very little control and the API to control the browser's RTC is=20 effectively via manipulation of the SDP. Yuck! Even if it were fancier=20 and prettier JSON, it would still be an ugly do-everything monolithic=20 object with a sketchy offer/answer model that is brittle and offered=20 very little real-scenario controls for those whom need it. It's=20 absolutely horrible and is in good need of quick deprecation.

    Right - by providing a higher level abs= traction of it, you'd enable that stuff underneath to be replaced. I do= n't have a good handle on SDP, so but I think what is proposed can be i= mproved. If you have any ideas on how to, this would be a good time to help= out, IMHO.

    Cheers,
    Silvia.=A0


    -Robin




    =20 17 June, 2013=20 9:00 PM
    Hi Peter, all,

    I'm=20 looking at all this from the view of a JS developer and I am
    really=20 excited that there is movement in this space. Having hit my
    head hard against the limitations of the current WebRTC API and being
    forced=20 to learn SDP to achieve some of the less common use cases, I'm
    feeli= ng the pain. I am therefore happy to see that there is a proposal
    for a higher-level API with similarities to the Microsoft's CU-WebRTC
    pro= posal and I hope that together with Microsoft's input this can
    become a= =20 really useful API.

    What I would like to see, though, is a bit=20 different from what you've
    proposed. In particular, the=20 MediaFlowDescription object is the one
    object that I believe is=20 supposed to enable JS developers to do "SDP
    hacking" without = having=20 to understand SDP. Unfortunately, the way in
    which it is currently=20 written, this API doesn't help a JS developer
    much. There are=20 properties in that object like "ssrc" that mean
    nothing unless= you=20 understand SDP.

    I would therefore like to recommend making the=20 properties on the
    MediaFlowDescription more semantic - in particular=20 giving them better
    names - such that a JS developer really doesn't= =20 have to understand SDP
    to create/change media flow descriptions. Can=20 we find better names for
    id, transportId and ssrc that are more=20 explicitly expressing what
    they stand for and when a JS developer=20 would actually change them?

    It would be nice if the=20 MediaFlowDescription was abstract enough such
    that in future it=20 doesn't matter if SDP is actually underneath (with
    offer/answer), bu= t that's not actually my main goal. What I'm after is
    an API that= can=20 be used without having to understand what is
    underneath.

    Thanks for listening and HTH,
    Silvia.

    _______________________________________________
    rtcweb mailing list
    rtcwe= b@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    =20 17 June, 2013=20 8:57 AM
    Google is in full support of "Plan B" for encoding multiple media sourc= es in=20 SDP, and would like to see the Plan A vs. Plan B decision resolved soon. =A0Recently, though, a third option, called "NoPlan" has been pr= oposed,=20 but it lacked the details of what a JS API would look like for NoPlan.=20 =A0Cullen asked to see such an API proposal, and so I have worked with=20 Emil to make one. =A0He will be adding it to the NoPlan draft, but I will= =20 also include it in this email.

    Again, Google is in full support of "Plan B". =A0But if Plan = A vs.=20 Plan B cannot be decided, then we support NoPlan with the following=20 additions to the WebRTC JS API as an option that allows implementing=20 either Plan A or Plan B =A0in Javascript. =A0And even if Plan A vs. Plan B= =20 is resolved, these API additions would still be a big improvement for=20 those WebRTC applications that don't use SDP for signalling.

    It is a bit long because I have added many comments and examples,=20 but the actually additions only include two new methods on=20 PeerConnection and a few new dictionaries. =A0So don't be overwhelmed := ).



    Intro: This follows the= =20 model of createDataChannel, which has a JS method on PeerConnection that makes it possible to add data channels without going through SDP.=20 =A0Furthermore, just like createDataChannel allows 2 ways to handle=20 neogitation (the "I know what I'm doing; =A0Here's what I want= to send;=20 Let me signal everything" mode and the "please take care of it fo= r me;=20 =A0send an OPEN message" mode), this also has 2 ways to handle negotia= tion (the "I know what I'm doing; Here's what I want to send; Let = me signal=20 everything" mode and the "please take care of it for me; =A0send = SDP back=20 and forth" mode).=A0
    = =A0
    Following the success of=20 createDataChannel, this allows simple applications to Just Work and more advanced applications to easily control what they need to. =A0In=20 particular, it's possible to use this API to implement either Plan A or= =20 Plan B.

    // The following two method are= =20 added to RTCPeerConnection
    partial interface RTCPeerConnection {
    =A0/= / Create a stream that is used to send a source stream.
    =A0// The=20 MediaSendStream.description can be used for signalling.
    =A0// No media is sent until addStream(MediaSendStream) is called.
    =A0LocalMediaStream=20 createLocalStream(MediaStream sourceStream);

    =A0// Create a stream that is used to receive media from the remote=20 side,
    =A0// given the parameters signalled from=20 MedaiSendStream.description.
    =A0MediaStream=20 createRemoteStream(MediaStreamDescription description);
    }


    interface LocalMediaStream implements MediaStream {
    =A0 // This can be changed at any time, but especially before calling
    =A0 //= =20 PeerConnection.addStream
    =A0 attribute MediaStreamDescription= =20 description;
    }

    // Represents the parameters used to either send or receive a stream=A0
    = // over a=A0PeerConnection.
    dictio= nary=20 MediaStreamDescription {
    =A0 MediaStreamTrackDescription[] tracks;
    }


    // Represents the parameters used to either send or receive a=20 track over // a=A0PeerConnection. =A0A track has many "flows", wh= ich can be=20 grouped=A0
    // together.
    dictionary=20 MediaStreamTrackDescription {
    =A0 // Same as the MediaStreamTrack.id
    = =A0 DOMString id;

    =A0 // Same as the MediaStreamTrack.kind
    =A0=20 DOMString kind; =A0

    =A0 // A track can have many "flows", such as for Simulcast, = FEC, etc.
    =A0 // And they can be grouped in arbitrary ways.
    =A0=20 MediaFlowDescription[] flows;
    =A0 MediaFlowGroup[] flowGroups;
    }

    // Represents the parameters used to either send or receive a "flow"=A0
    // over a=A0PeerConnection. =A0A "flow" is a= =20 media that arrives with a=A0
    = // single, unique SSRC. =A0One to man= y=20 flows together make up the media=A0
    // for a track. =A0For=A0example, the= re=20 may be Simulcast, FEC, and RTX=A0
    // flows.
    dictionay MediaFlowDescription {
    =A0 // The "flow id" must be = unique to the track, but need not be unique=A0
    =A0 // outside=A0of the track (two tracks=20 could both have a flow with the=A0
    = =A0 // same flow ID).
    =A0 DOMStrin= g id;

    =A0 // Each flow can go over its own transport. =A0If the JS sets this to a =A0 // transportId that doesn't have a transport setup already, the=A0<= /font>
    =A0 // browser will use S= DP negotiation to=20 setup a transport to back that=A0
    = =A0 // transportId. =A0If=A0This is s= et to an=20 MID in the SDP, then that MID's=A0
    =A0 // transport is used.
    =A0=20 DOMString transportId;

    =A0 // The SSRC used to send the flow.
    =A0= =20 unsigned int ssrc;

    =A0= =20 // When used as receive parameters, this indicates the possible list=A0
    = =A0 // of codecs that might come in f= or=20 this flow. =A0For exmample, a given=A0
    =A0 // receive=A0flow could be setup = to=20 receive any of OPUS, ISAC, or PCMU.
    =A0 // When used as send=20 parameters, this indicates that the first codec=A0
    =A0 // should=A0be used, but the brow= ser can use send other codecs if it=A0
    =A0 // needs to because=A0of either bandwidth or CPU constraints.
    =A0 MediaCodecDescription[] codecs;
    }


    dictionary=20 MediaFlowGroup {
    =A0 DOMString type; =A0// "SIM" for Simulcast= , "FEC" for FEC, etc
    =A0 DOMString[] flowids;
    }

    dictionary=20 MediaCodecDescription {
    =A0 unsigned byte payloadType;
    =A0 DOMString= =20 name;
    =A0 unsigned int? clockRate;
    =A0 unsigned int? bitRate;    <= /div>
    =A0 // A grab bag of other fmtp that= =20 will need to be further defined.
    =A0 MediaCodecParam[] params; =A0
    }<= br>
    dictionary MediaCodecParam {
    =A0 DOMString key;
    =A0 DOMString value;
    }


    Notes:

    - When LocalMediaStreams are added using=20 addStream, onnegotiatedneeded is not called, and those streams are never reflected in future SDP exchanges. =A0Indeed, it would be impossible to=20 put them in the SDP without first resolving if that would be Plan A SDP=20 or Plan B SDP.
    =
    - Just like piles of attributes would=20 need to be defined for Plan A and for Plan B, similar attributes would=20 need to be defined here (Luckily, =A0much work has already been done=20 figuring out what those parameters are :).


    Pros:

    - Either Plan A or Plan B or could be implemented=20 in Javascript using this API
    - It exposes all the same functionality=20 to the Javascript as SDP, but in a much nicer format that is much easier to work with.
    - Any other signalling mechanism, such as Jingle or CLUE could be=20 implemented using this API.
    - There is almost no risk of signalling=20 glare.
    - Debugging errors with misconfigured descriptions should be=20 much easier with this than with large SDP blobs.


    Cons:

    - Now there are two slightly different ways to add streams: by creating a=20 LocalMediaStream first, and not. =A0This is, however, analogous to setting "negotiated: true" in createDataChannel. =A0On way is "Just= Work", and=20 the other is more advanced control.
    =
    - All the options in=20 MediaCodecDescription are a bit complicated. =A0Really, this is only=20 necessary because Plan A requires being able to specify codec parameters per SSRC, and set each flow on different transports. =A0If we did not=20 have this requirement, we could simplify.


    Example Usage:

    // Imagine I have MyApp, handles creating a PeerConnection,
    // signalling, and rendering streams. =A0This is how=20 the new API could be=A0
    // used.
    var peerConnection =3D=20 MyApp.createPeerConnection();

    // On sender side:
    var stream =3D= =20 MyApp.getMediaStream();
    var localStream =3D=20 peerConnection.createSendStream(stream);
    sendStream.description =3D MyApp.modifyStream(localStream.description)
    M= yApp.signalAddStream(localStream.description, function(response)) {
    =A0 if (!response.rejected) {
    =A0 =A0 // Media= =20 will not be sent.
    =A0 =A0 peerConnection.addStream(localStream);
    =A0 }
    }

    // On receiver side:
    MyApp.onAddStreamSignalled =3D=20 function(streamDescription) {
    =A0 var stream =3D=20 peerConnection.createReceiveStream(streamDescription);
    =A0 MyApp.renderStream(stream);
    }<= br>

    // In this exchange, the MediaStreamDescription signalled from the=A0    <= /div>
    // sender to=A0the receiver may have= =20 looked something like this:

    {
    =A0 tracks: [
    =A0 {
    =A0 =A0 i= d:=20 "audio1",
    =A0 =A0 kind: "audio",
    =A0 =A0 flows: [=
    =A0 =A0 {
    =A0 =A0 =A0=A0    id:=20 "main",
    =A0 =A0= =A0 transportId: "transport1",
    =A0 =A0 = =A0 ssrc:=20 1111,
    =A0 =A0 =A0 codecs: [<= font face=3D"courier new, monospace">
    =A0 =A0 = =A0 {
    =A0 =A0 =A0 =A0 payloadType: = 111,
    =A0 =A0 = =A0 =A0 name:=20 "opus",
    =A0 =A0 =A0 =A0 /= / ... more codec=20 details
    = =A0 =A0 =A0 },<= /span>
    =A0 =A0 =A0 {= =A0
    =A0 =A0 =A0 =A0 payloadType: 112,
    =A0 =A0 =A0 =A0 name: &q= uot;pcmu",
    =A0 =A0 =A0 =A0= =A0// ..= . more codec details
    =A0 =A0 =A0 }]<= /span>
    =A0 =A0}]
    =A0},
    =A0{<= br>    =A0 = =A0 id: "video1", =A0 =A0 = kind:=20 "video",
    <= span style=3D"font-family:'courier new',monospace">=A0 =A0 flows: [=
    = =A0 =A0 {
    =A0 =A0 =A0 id:= "sim0",
    =A0 =A0 =A0 transportId:=20 "transport2",
    =A0 =A0 = =A0 ssrc:=20 2222,
    =A0 =A0 =A0 codecs: [<= font face=3D"courier new, monospace">
    =A0 =A0 = =A0 {
    =A0 =A0 =A0 =A0 payloadType: 122,
    =A0 =A0 = =A0 =A0 name:=20 "vp8"
    =A0 =A0 =A0 =A0=A0// ... more codec details
    = =A0 =A0 =A0 }]<= /span>
    =A0 =A0},
    =A0 =A0{
    =A0 =A0 =A0i= d: "sim1",
    =A0 =A0 =A0transportId: "transport2",
    =A0 =A0 =A0ssrc: 2223,
    = =A0 =A0 =A0codecs: [
    =A0 =A0 =A0{
    =A0 =A0 =A0 =A0payloadType: 122,
    =A0 =A0 =A0 =A0name: "= ;vp8",
    =A0 =A0 =A0 =A0    // ...=20 more codec details
    =A0 =A0 = =A0}]
    =A0 =A0},
    =A0 =A0{
    =A0 =A0 =A0id: "sim2",
    =A0 =A0 =A0transp= ortId: "transport2",
    =A0 =A0 =A0ssrc: 2224,
    =A0 =A0 =A0codecs: [
    =A0 =A0 =A0{
    =A0 =A0 = =A0 =A0payloadType: 122,
    =A0 =A0 =A0 =A0name: "vp8",
    =A0 =A0 =A0 =A0    // ... mo= re codec details
    =A0 =A0 =A0}]
    =A0 =A0},

    =A0 =A0{
    =A0 =A0 =A0id: "sim0fec&= quot;,
    =A0 =A0 =A0transportId: "transport2",
    =A0 =A0 =A0ssrc: 2225,
    =A0 =A0 =A0codecs: [<= br>=A0 =A0 =A0{
    =A0 =A0 =A0=20 =A0payloadType: 122,
    =A0 =A0 =A0 =A0name: "vp8",
    =A0 =A0 = =A0 =A0// ...
    =A0 =A0 =A0}]
    =A0 =A0}],
    =A0 =A0flowGroups: [
    =A0 =A0{
    =A0 =A0 = =A0semantics: "SIM",
    =A0 =A0 =A0ssrcs: [2222, 2223, 2224]
    =A0 =A0},
    =A0 =A0{
    =A0 =A0 =A0se= mantics: "FEC",
    =A0 =A0 =A0ssrcs: [2222, 2225]
    =A0 =A0}]
    =A0}]
    }


    Constructive feedback is welcome :).
    _______________________________________________
    rtcweb mailing=20 list
    rtcweb@ietf.or= g
    https://www.ietf.org/mailman/listinfo/rtcweb

    --047d7b3a97a814f4e404df654c35-- --047d7b3a97a814f4e504df654c36 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 6b11cf39ae4323a6_0.1.1 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkI CQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkLEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAARCAAZABkDAREA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwBvi7xt L/ZUvifVora/u5rGG8uJ57KKaWWWSJSSWZSeWbgdAMAYAAr1sRUhRw8pM86hGVauoo8kPxO8dWMM Nx4l8JaTp1rPGJYnfR4XSRPXd5Yx+Ga+XoZn72krn0VXLVy6xPV/hh4z0vxVb2l/BDYRFLlIZBDa wqyNkYKuqhlPOQQcg/SvqsJiKeJpXR81iaMsNUsO/wCGlvjF/wBD9f8A/fKf/E1fsqfYXtZ9znYr hNetfDmmmRYDK2lYkf8AiZTD8uPfkfjXm5tb6jNtHblabxsEj3/xi2p6t4QPhe8+FqBPtDW0VqLm Pe0eM+apxgewznFfn2GhHm02R+iVIS5Nj5U0TQL74VfGu48PNdRR6ZrUvmW0GGPkldjjkfKeTInH 92vqstr+yqxgup8lmmG5qcpvdHN/2qf+fpP++T/jX0/Mz5qxa8JalrnxI8baZ8IPCP7vVdPtlu7+ eQGEWf2SMNIGHXcrLgjAJbC9TXkZsnVw3s49WenlsPZVfay6H2Be/DHxM+g6LqvkardtrEUOoQG2 UujvIikjzCcIe3zcgZwcV8fQw1aM+XufbvN8O6PM3qj5e+OngXW/hl8cY/EWs3V1c21tb2d1fy7t 8NkWH+rDHouN3PdiT3r3IU3QrQ5dWrNnzlas8XCT2TukcB/wjPjL/on/AIl/8FE3/wARXu/Xo/ys 8P6rLujoPFv/ACfR8Vf+uTf+i7esJ7I7I7P1PTvCP/Ig2H/Xsv8AM1wrdBUPM/Gv/JSdF/7CGhf+ lcda0/iZcf4a+Z+qVUI//9k= --047d7b3a97a814f4e504df654c36 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 6b11cf39ae4323a6_0.1.2 /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQECAQEB AQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAARCAAZABkDAREA AhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUKBwAAAAAAAAACAQME BQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAAAAAAAAAAAAADAAEEAv/E ACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oADAMBAAIRAxEAPwDuEt+gW/UL et6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJVIl7eXLCaZIGwBl3TY8epPx2+jy2 ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJ Ew/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx+a69/JSf9alIlste0VzaNpeFrcT9KKymotyi aZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mRUfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRD nu5azS8miKqjOTVkKqS/psG37fo1Fbabeg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GA cpOwBeN+U8/IkGbsiS8b7ryogmbzhbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH 4hPOI0DkjZtaJtFxuVEbIUUiyeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJ nYn9dnAQWl722p4ot37yzqnlfp6FrqbwawG8/9k= --047d7b3a97a814f4e504df654c36-- From martin.thomson@gmail.com Mon Jun 17 21:01:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8928921F95EF for ; Mon, 17 Jun 2013 21:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdfijM0Y9Dbv for ; Mon, 17 Jun 2013 21:01:29 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B54DC21F8E98 for ; Mon, 17 Jun 2013 21:01:28 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so3085032wgh.24 for ; Mon, 17 Jun 2013 21:01:27 -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=ZugIHO62YCOT1O1XrJpDpNnX29eZRd2b+I5SpXkpHqI=; b=BwU7jaQAWuYJRfRpcDN4QP06Y+wkH5x6qe+tBsPAxqESBDW73duOhl3Mohk8LEKxbr SOmZjsvC1pcI9ArzT8Z/mJWINsya6Yvk5w6SR3LboG37mothFEtBlzcvuhRkpP2l7vw8 Cv3Z4JBGR6lhIfslAPLHvjSdP5FsyQptkE4psw712QfMqeagIEsKOgOEr76zktnH6TVb +TDwxqi6ksqOrmiCEs8D2KRbuctRwiYJ9F61ryv681+3YfivYbezHwGURzT1AR4tCdMn zrq/Zw0PynR2WornGGX1FjbW/El2nEUxBVL2UNY9Af1SPlrC4kFuVnpapHvD3L5uyHgO kuNw== MIME-Version: 1.0 X-Received: by 10.194.77.99 with SMTP id r3mr1697802wjw.5.1371528087859; Mon, 17 Jun 2013 21:01:27 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 17 Jun 2013 21:01:27 -0700 (PDT) In-Reply-To: <51BFCBE9.5070406@hookflash.com> References: <51BFCBE9.5070406@hookflash.com> Date: Mon, 17 Jun 2013 21:01:27 -0700 Message-ID: From: Martin Thomson To: Robin Raymond Content-Type: multipart/alternative; boundary=047d7bfd091879f92004df65c4d9 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 04:01:29 -0000 --047d7bfd091879f92004df65c4d9 Content-Type: text/plain; charset=UTF-8 On 17 June 2013 19:54, Robin Raymond wrote: > > On a side note, I agree that SDP should go (and quickly) but it's not the > format that's the problem. Granted, it is obtuse. But it's not just that; > it's a monolithic do-everything offer/answer model that offers very little > control and the API to control the browser's RTC is effectively via > manipulation of the SDP. Yuck! Even if it were fancier and prettier JSON, > it would still be an ugly do-everything monolithic object with a sketchy > offer/answer model that is brittle and offered very little real-scenario > controls for those whom need it. It's absolutely horrible and is in good > need of quick deprecation. I think that this sums up my views on the subject. Offer/answer is at the heart of this. SDP is just the ugly wrapper that attracts all the heat. SDP isn't so bad if you are doing SAP. Of course, once you drop O/A, then you have to build something else. I made a start at that, but I caution, this approach was soundly rejected: http://lists.w3.org/Archives/Public/public-webrtc/2012Oct/att-0076/realtime-media.html No matter how right you are, the political reality is that it's not cool to raise comment 22. --047d7bfd091879f92004df65c4d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On 1= 7 June 2013 19:54, Robin Raymond <robin@hookflash.com> wro= te:

    On a side note, I agree that SDP should go (and quickly) but it's not= =20 the format that's the problem. Granted, it is obtuse. But it's not = just=20 that; it's a monolithic do-everything offer/answer model that offers=20 very little control and the API to control the browser's RTC is=20 effectively via manipulation of the SDP. Yuck! Even if it were fancier=20 and prettier JSON, it would still be an ugly do-everything monolithic=20 object with a sketchy offer/answer model that is brittle and offered=20 very little real-scenario controls for those whom need it. It's=20 absolutely horrible and is in good need of quick deprecation.
    <= /div>
    I think that this sums up my view= s on the subject.=C2=A0 Offer/answer is at the heart of this.=C2=A0 SDP is = just the ugly wrapper that attracts all the heat.=C2=A0 SDP isn't so ba= d if you are doing SAP.=C2=A0 Of course, once you drop O/A, then you have t= o build something else.=C2=A0

    I made a start at that, but I caution, this approach was soundly reject= ed: http://lists.w3.org/Archives/Public/public-webr= tc/2012Oct/att-0076/realtime-media.html

    No matter how right you are, the polit= ical reality is that it's not cool to raise comment 22.
    --047d7bfd091879f92004df65c4d9-- From pthatcher@google.com Mon Jun 17 22:28:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B9021F9DCD for ; Mon, 17 Jun 2013 22:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVVEcsnQTTNt for ; Mon, 17 Jun 2013 22:27:55 -0700 (PDT) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id E1ABA21F9DBF for ; Mon, 17 Jun 2013 22:27:54 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 4so3528721pdd.20 for ; Mon, 17 Jun 2013 22:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SwxuHeehZF0LEwL53zZdFSFe76VvQcsw5XlqbXy4AlY=; b=lRTmvaQZQVB2XCEAf4NfiHP87MyjF6lx9OMVXQDEMzzSPY65ma7AicuVN6vapKudHx CqelSqiMcqONYbgKCvFzv2xfwNSgrGQJa6nS1NJI/CShcT+aeuLn74InVKFjHhUgrCXm l3y2nngtvviMnrP7mUDJG+SmeXi8m++Ub3Um9I8HFye42vrGWibwhyy9KenC5ecMHeFA /5ThyM4RCTbRjKZBUSaQVc8t+12gsPpECHm9uQg+fmDdDLZGFeeO/CgzBINX4SpPcUan uF4T6v0RjwDcLaHvX4ySr4zcQLw9Gl2ntipUnE2VFbhYTug0RgyvgpTRu0X4+EDa4nnv Jg2g== 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=SwxuHeehZF0LEwL53zZdFSFe76VvQcsw5XlqbXy4AlY=; b=UrPrTHZYO0wrQLP9EmEJJS/fNsz5HqtuUoTG6B3GtDnM0n40VbELkO7qXX/g6Vnxkt 8POOAemHz3Nbg6VsJs/37vtZHVmLlniiQtVFBjsXsV7iuz487GtwQi9jCMIrUgA5Rp8Q tHSh9YEYa8S/WwTtWrZcKeqNeW58QqYErf3C0okEYcitx49r0BNX7nL/5Ffrk45V4RJ/ 0ogSM0ne62kwVo+NAF2sWvSrlwtUbXNcPAzRy/gyW+yIzRIvrOljIOrLjVSWHJMdSen1 VjspozzoODKJ5jC1m9JkSi9/rj2XfbQplxgJyvMZdKPVeHmGGzpT2+rw5pbBfKLddHgM t3Gw== X-Received: by 10.68.163.165 with SMTP id yj5mr8312114pbb.141.1371533274582; Mon, 17 Jun 2013 22:27:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Mon, 17 Jun 2013 22:27:13 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Mon, 17 Jun 2013 22:27:13 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b86d556a1330e04df66f9cc X-Gm-Message-State: ALoCoQmg3fY/yezEyu7BZJpXHaU89hfQ8sDAgUKaN6gwTGobKmkWD41unOeiV3GmeVs7LtFyHAN8Ajvpe0PRDcJNlmN3Wq5LejVaF8RjSep5WCk9Nb1gPYYkgwqysEMEcsxzEUPXJqKcd2xg6W7Fl5+i4F2r9SQkWv3DPj/q/qHkbP/U32SsBJoweSrOHu4JbtsbmUAIL6PY Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 05:28:00 -0000 --047d7b86d556a1330e04df66f9cc Content-Type: text/plain; charset=UTF-8 On Mon, Jun 17, 2013 at 2:56 PM, Martin Thomson wrote: > On 17 June 2013 12:26, Peter Thatcher wrote: > > Yes, I was expecting you to be more supportive. I'm surprised out how > your > > want "all or nothing". I'm afraid if our options for a clean API are > all or > > nothing, we'll just end up with nothing. I'd prefer to try incremental > > improvements to word toward (eventually) a clean API. > > Yes, I apologize if the language seemed strong, but I stand by those words. > > The problem that I see with this, and it is a problem with any > incremental approach, is that it produces two very different > interaction models for things that are approximately the same > fundamental operation. > > That is, when I add the first video track to a session I perform one > set of actions. Then, when I add subsequent tracks, it's different. > > I don't thing we have to have two different sets of actions. If a JS app chooses, it could use createLocalStream and createRemoteStream for all of its streams, and only use SDP for setting up the transport. For example, I could choose to write JS that would setup one transport with one call to createOffer/setLocalDescription/setRemoteDescription (ignore trickle ICE and ICE restarts for them moment) and bundle all media over it. That means the SDP is really just used as a way to tell the browser what ice ufrag, ice pwd, and DTLS fingerprint to use. It would look something like this (forgive me if I got the SDP slightly wrong; it's easy to get wrong): v=0 o=- 697639972863421376 2 IN IP4 127.0.0.1 s=- t=0 0 m=application 1 DTLS/SCTP 5000 c=IN IP4 0.0.0.0 a=mid:transport a=ice-ufrag:tEP42he9r6LycvmM a=ice-pwd:cKJLuvHy9pas9rdezUZB9xet a=fingerprint:sha-256 EC:E0:95:43:B7:01:49:8B:BC:21:CC:41:7F:10:FD:92:28:B8:F8:41:07:70:77:7D:7C:47:92:30:79:C4:95:9C Ignoring ICE candidates and restarts, that's all the SDP what would be needed for the whole PeerConnection (one for the local and one for the remote). The first set of streams has the same actions as the 100th set of streams, if the JS chooses. 10 lines of SDP just to setup a transport isn't quite such an abomination, is it? This also has all the purported drawbacks of comment 22 with respect > to usability, whatever they are. There must have been some because I > got a lot of heat about that when we discussed it. > > > Do you think it is impossible to work toward a clean API in an > incremental > > approach? If you think it's possible, I'd like to hear your thoughts on > > how. > > The fundamental problem in WebRTC is the Offer/Answer semantics in the > API. That's hard to remove now. I can't see an incremental change > that would remove that, and that's every bit as much of a problem as > having to deal with SDP. That's how we got to comment 22. > There are two places we currently have offer/answer: 1. To setup the transports. 2. To define the streams. And once upon a time, there was going to be 3. To define the data channels. We were able to prevent #3 and just have data channel be defined in terms of createDataChannel, and not in terms of SDP. That was good, was it not? What I'm proposing is that we do something similar for audio and video streams (#2). That way, all that you need to use SDP for would be #1 (to setup the transports). And someday, we might be able to improve that as well (perhaps a future .createTransport method). > > I know that you wanted to do some sort of object representation of > SDP. That can be done incrementally by adding to > RTCSessionDescription, or by replacing it entirely, but it doesn't > really go to the core of the problem. If you were willing to tolerate > the fact that there would be two code paths, two control surfaces that > effectively did the same things. > > > > By the way, these API additions would greatly minimize the amount of SDP > > editing necessary for JS clients that don't use SDP for signalling. And > > later incremental improvements could reduce it further. Also, it's no > > longer necessary to do offer/answer for adding tracks. It's only the > intial > > PeerConnection setup that needs to do Offer/Answer. So, it doesn't > inherit > > all the problems quite as much as you described. It may be slightly > > abominable, but I certainly consider it less abominable than the SDP > editing > > necessary without it. > > If I am forced to do SDP, I'd rather not have something else as well > unless that something else is getting me something concrete. What you > are proposing does too little to advance a cleaner API model to > justify the extra overhead that it introduces. It doesn't tackle the > hard problems. > You're not forced to do SDP, except for the transports. For defining the streams, you can avoid SDP altogether. As a WebRTC JS app developer, I know I would find working with this API much better than working with SDP munging. > > I appreciate the philosophy behind no-plan, which is not a non-plan in > any sense. It addresses a concern that we (unfortunately) didn't > really touch on in the MMUSIC call this morning. However, the > requirements of the-not-no-plan could be far more elegantly addressed > within the constraints of the current API without adding all those > extra description bits. > I'm a bit confused. Do you consider changes to SDP more elegant than dictionaries like MediaStreamTrackDescription? I would find that somewhat ironic. Or are you suggesting there's a way I can simplify all the "description bits". If there's a specific way I can simply it to make it better, I'd lover to hear it. And, thanks for your feedback. I hope my response about not requiring SDP for the first streams helps clarify. > > --Martin > --047d7b86d556a1330e04df66f9cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Mon, Jun 17, 2013 at 2:56 PM, Martin Thomson &= lt;martin.tho= mson@gmail.com> wrote:
    On 17 June 2013 12:26, Peter Thatcher &l= t;pthatcher@google.com> wrot= e:
    > Yes, I was expecting you to be more supportive. =C2=A0I'm surprise= d out how your
    > want "all or nothing". =C2=A0I'm afraid if our options f= or a clean API are all or
    > nothing, we'll just end up with nothing. =C2=A0I'd prefer to t= ry incremental
    > improvements to word toward (eventually) a clean API.

    Yes, I apologize if the language seemed strong, but I stand by those = words.

    The problem that I see with this, and it is a problem with any
    incremental approach, is that it produces two very different
    interaction models for things that are approximately the same
    fundamental operation.

    That is, when I add the first video track to a session I perform one
    set of actions. =C2=A0Then, when I add subsequent tracks, it's differen= t.


    I don't thing we have to have two = different sets of actions. =C2=A0If a JS app chooses, it could use createLo= calStream and createRemoteStream for all of its streams, and only use SDP f= or setting up the transport. =C2=A0For example, I could choose to write JS = that would setup one transport with one call to createOffer/setLocalDescrip= tion/setRemoteDescription (ignore trickle ICE and ICE restarts for them mom= ent) and bundle all media over it. =C2=A0That means the SDP is really just = used as a way to tell the browser what ice ufrag, ice pwd, and DTLS fingerp= rint to use. =C2=A0It would look something like this (forgive me if I got t= he SDP slightly wrong; =C2=A0it's easy to get wrong):

    v=3D0
    o=3D- 697639972863421376 2 IN IP4 127.0.0.1
    s=3D-
    t=3D0 0
    m=3Dapplication 1 DTLS/SCTP 5000
    c= =3DIN IP4 0.0.0.0
    a=3Dmid:transport

    a=3Dice-ufrag:tEP42he9r6LycvmM
    a=3Dice-pwd:cKJLuvHy9pas9rdezUZB9xet
    a=3Dfingerprint:= sha-256 EC:E0:95:43:B7:01:49:8B:BC:21:CC:41:7F:10:FD:92:28:B8:F8:41:07:70:7= 7:7D:7C:47:92:30:79:C4:95:9C



    Ignoring ICE candidates and= restarts, that's all the SDP what would be needed for the whole PeerCo= nnection (one for the local and one for the remote). =C2=A0The first set of= streams has the same actions as the 100th set of streams, if the JS choose= s. =C2=A0

    10 lines of SDP just to setup a transport isn't qui= te such an abomination, is it?


    This also has all the purported drawbacks of comment 22 with respect
    to usability, whatever they are. =C2=A0There must have been some because I<= br> got a lot of heat about that when we discussed it.

    > Do you think it is impossible to work toward a clean API in an increme= ntal
    > approach? =C2=A0If you think it's possible, I'd like to hear y= our thoughts on
    > how.

    The fundamental problem in WebRTC is the Offer/Answer semantics in th= e
    API. =C2=A0That's hard to remove now. =C2=A0I can't see an incremen= tal change
    that would remove that, and that's every bit as much of a problem as having to deal with SDP. =C2=A0That's how we got to comment 22.

    There are two places we currently have offer/a= nswer: 1. =C2=A0To setup the transports. =C2=A02. =C2=A0To define the strea= ms. =C2=A0And once upon a time, there was going to be 3. =C2=A0To define th= e data channels. =C2=A0We were able to prevent #3 and just have data channe= l be defined in terms of createDataChannel, and not in terms of SDP. =C2=A0= That was good, was it not? =C2=A0What I'm proposing is that we do somet= hing similar for audio and video streams (#2). =C2=A0That way, all that you= need to use SDP for would be #1 (to setup the transports). =C2=A0And somed= ay, we might be able to improve that as well (perhaps a future .createTrans= port method).

    =C2=A0

    I know that you wanted to do some sort of object representation of
    SDP. =C2=A0That can be done incrementally by adding to
    RTCSessionDescription, or by replacing it entirely, but it doesn't
    really go to the core of the problem. =C2=A0If you were willing to tolerate=
    the fact that there would be two code paths, two control surfaces that
    effectively did the same things.

    =C2=A0=

    > By the way, these API additions would greatly minimize the amount of S= DP
    > editing necessary for JS clients that don't use SDP for signalling= . =C2=A0And
    > later incremental improvements could reduce it further. =C2=A0Also, it= 's no
    > longer necessary to do offer/answer for adding tracks. =C2=A0It's = only the intial
    > PeerConnection setup that needs to do Offer/Answer. =C2=A0So, it doesn= 't inherit
    > all the problems quite as much as you described. =C2=A0It may be sligh= tly
    > abominable, but I certainly consider it less abominable than the SDP e= diting
    > necessary without it.

    If I am forced to do SDP, I'd rather not have something else as w= ell
    unless that something else is getting me something concrete. =C2=A0What you=
    are proposing does too little to advance a cleaner API model to
    justify the extra overhead that it introduces. =C2=A0It doesn't tackle = the
    hard problems.

    You're not forced to= do SDP, except for the transports. =C2=A0For defining the streams, you can= avoid SDP altogether. =C2=A0As a WebRTC JS app developer, I know I would f= ind working with this API much better than working with SDP munging.=C2=A0<= /div>
    =C2=A0

    I appreciate the philosophy behind no-plan, which is not a non-plan in
    any sense. =C2=A0It addresses a concern that we (unfortunately) didn't<= br> really touch on in the MMUSIC call this morning. =C2=A0However, the
    requirements of the-not-no-plan could be far more elegantly addressed
    within the constraints of the current API without adding all those
    extra description bits.

    I'm a bit c= onfused. =C2=A0Do you consider changes to SDP more elegant than dictionarie= s like MediaStreamTrackDescription? =C2=A0I would find that somewhat ironic= . =C2=A0Or are you suggesting there's a way I can simplify all the &quo= t;description bits". =C2=A0If there's a specific way I can simply = it to make it better, I'd lover to hear it. =C2=A0


    And, thanks for your feedback. =C2=A0I h= ope my response about not requiring SDP for the first streams helps clarify= .
    =C2=A0

    --Martin

    --047d7b86d556a1330e04df66f9cc-- From pthatcher@google.com Mon Jun 17 22:31:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797C621F9C12 for ; Mon, 17 Jun 2013 22:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf3iwDoN0bDm for ; Mon, 17 Jun 2013 22:31:26 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id DDE2721F880F for ; Mon, 17 Jun 2013 22:31:26 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp16so3528567pbb.14 for ; Mon, 17 Jun 2013 22:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FL/thb/4yoiTVKyPcgsX8d4TM0lpvK5VAYTJTsHem74=; b=n+z+ltlxZPy5HcOKdBP9qzdkzeTrkX/dAGQK7IGP9qOmd+43SmOnbI4zjra5m8mA9p IFZtwda/j8TzuP1s9cIFcrSuQYgPNOPNgU7tdssJFs8LVcpbmUz2lzNn1XYuhb3KbIZx /WJnKlHDxNiDgPqXu/NGuqJN4QvZnJed3F8DJPPs5oIK1b4opLXjaAxFsI54ijzT0vJo Lz3ci0Q98doF5MB93P/FFH9BgDn3QhHHiEI59FbdLF7yAV3+TTOINN/j5rWGpiAEx5Ml BIZWTRM/yIgaNGYt+j9t+ahVwx4K5v3a1kWH4ZmUMzLDpEbNAvfsLDO5dA5s8RK3Y0Gt ZtTA== 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=FL/thb/4yoiTVKyPcgsX8d4TM0lpvK5VAYTJTsHem74=; b=PxF+797IQ62+ghZnSugHCKQmF/aJJfV9K7/nEHkoiSgW9dYfAPbsDLoc3S0otHf6iX JmLk7gTw86isL7maoA61kR09QqbT4sQyO9TFRzHp3Y3e0fqbRTDs7DHUtLi5TKBAFw8v tcKAVkzvqfeAcoDyuQ3AYFJbWILOXg8bk8t9KRgeqgM1zB3Y01zySutNprwzV9qmwbYD tb3jNSoNw2Ri+nDyG8RKADYZhwImqd9N07xont+DHkfcXrtZnSsuJogpARqPzKA0xNUJ Eisfrs4lhawSmwEPvpqTMfEH3cWPtskuOvykY0DN2C759Z6rWrBg6xTsRr/I0B8la5RW Vyqg== X-Received: by 10.66.164.161 with SMTP id yr1mr706043pab.77.1371533486599; Mon, 17 Jun 2013 22:31:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Mon, 17 Jun 2013 22:30:46 -0700 (PDT) In-Reply-To: References: <51BFCBE9.5070406@hookflash.com> From: Peter Thatcher Date: Mon, 17 Jun 2013 22:30:46 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bacc03044500e04df670648 X-Gm-Message-State: ALoCoQkswJSSfZmTHRyLfA+pDmKHSFNR36onqMpvugZ7nnO+0a9o7cgAp29iVKVn0iRPXVZu6xph2aQDSuX8jlzd+nZnK5Mpx9DOBTBtPMaabN2HAJO9Qw8vsdsTTteCPyE0Lz/tvxhJ9QPo995aHCO3nQXTEUwqd+baMUEB2NcQPD40/gT+Fwz0FZSzM/rgSi3oXjB5he9R Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 05:31:27 -0000 --047d7bacc03044500e04df670648 Content-Type: text/plain; charset=UTF-8 As I mentioned in the previous email, I think O/A is use in two different ways: transport and streams. I believe it's mostly painful for adding streams, and less painful for establishing the transport. If we allowed adding streams without O/A, we'd have relieved more than half the pain, or at least more than half the pain I experience. And that's just what I'm proposing we allow with createLocalStream/createRemoteStream. On Mon, Jun 17, 2013 at 9:01 PM, Martin Thomson wrote: > On 17 June 2013 19:54, Robin Raymond wrote: > >> >> On a side note, I agree that SDP should go (and quickly) but it's not the >> format that's the problem. Granted, it is obtuse. But it's not just that; >> it's a monolithic do-everything offer/answer model that offers very little >> control and the API to control the browser's RTC is effectively via >> manipulation of the SDP. Yuck! Even if it were fancier and prettier JSON, >> it would still be an ugly do-everything monolithic object with a sketchy >> offer/answer model that is brittle and offered very little real-scenario >> controls for those whom need it. It's absolutely horrible and is in good >> need of quick deprecation. > > > I think that this sums up my views on the subject. Offer/answer is at the > heart of this. SDP is just the ugly wrapper that attracts all the heat. > SDP isn't so bad if you are doing SAP. Of course, once you drop O/A, then > you have to build something else. > > I made a start at that, but I caution, this approach was soundly rejected: > http://lists.w3.org/Archives/Public/public-webrtc/2012Oct/att-0076/realtime-media.html > > No matter how right you are, the political reality is that it's not cool > to raise comment 22. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7bacc03044500e04df670648 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    As I mentioned in the previous email, I think O/A is use i= n two different ways: transport and streams. =C2=A0I believe it's mostl= y painful for adding streams, and less painful for establishing the transpo= rt. =C2=A0If we allowed adding streams without O/A, we'd have relieved = more than half the pain, or at least more than half the pain I experience. = =C2=A0 And that's just what I'm proposing we allow with createLocal= Stream/createRemoteStream.


    On Mon, Jun 1= 7, 2013 at 9:01 PM, Martin Thomson <martin.thomson@gmail.com>= ; wrote:
    On 17 June 2013 19:54, Robin R= aymond <robin@hookflash.com> wrote:

    On a side note, I agree that SDP should go (and quickly) but it's not= =20 the format that's the problem. Granted, it is obtuse. But it's not = just=20 that; it's a monolithic do-everything offer/answer model that offers=20 very little control and the API to control the browser's RTC is=20 effectively via manipulation of the SDP. Yuck! Even if it were fancier=20 and prettier JSON, it would still be an ugly do-everything monolithic=20 object with a sketchy offer/answer model that is brittle and offered=20 very little real-scenario controls for those whom need it. It's=20 absolutely horrible and is in good need of quick deprecation.
    <= /div>
    I think that this sums up m= y views on the subject.=C2=A0 Offer/answer is at the heart of this.=C2=A0 S= DP is just the ugly wrapper that attracts all the heat.=C2=A0 SDP isn't= so bad if you are doing SAP.=C2=A0 Of course, once you drop O/A, then you = have to build something else.=C2=A0

    I made a start at that, but I caution, this approach was soundly reject= ed: http://lists.w3.org/Archives/= Public/public-webrtc/2012Oct/att-0076/realtime-media.html

    No matter how right you are, the polit= ical reality is that it's not cool to raise comment 22.

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


    --047d7bacc03044500e04df670648-- From pthatcher@google.com Mon Jun 17 22:34:49 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0BBD21F9E79 for ; Mon, 17 Jun 2013 22:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pH0JybnPMREg for ; Mon, 17 Jun 2013 22:34:49 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3E46B21F9DFA for ; Mon, 17 Jun 2013 22:34:49 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id xa12so3501681pbc.25 for ; Mon, 17 Jun 2013 22:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9Tsojh4OXFTjYhLlUL/0IELlKbEohL6EuBcBex7RAK8=; b=IHf3GviorCpPqGZq/JiFNiTqEX4RTfBSAmaJTfPk3EiR60qroZZ3QK0Tg//CLZqdoB fRKdt7DPqrHxkKQqFQpKQDBOHJG5YeR9GNZhTDzlzlj/ZdjFkfZrYPn7w8QaKJNBYEtK pAPIFBsOfYd97oXOJVB2hX29+AMHT0eBvyYFyqFyiHa+58EalA7WyVwn+D1HpTXB7E5F qMe1qp6juu3XN+9OltvE2kX/IPgofKNNpxtQIqfIcVMti05tjgwpFGlUdvvVl1wldZ/E aDuNN851fD3AH7Vwu7samPlNLGVTUUVnV+CUWKz2vopypeuZulgI4HXziSLu7FsSuf34 lC/Q== 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=9Tsojh4OXFTjYhLlUL/0IELlKbEohL6EuBcBex7RAK8=; b=KzQmdAqB7yQkjTmy0OqCh46s1IHoVBPWNDeSJAG/t1wRBBsz7qt5W/UYq0COP0LS5b CFjQfabfveuEm5MIZtD/zQN5tdvwnmrDhS0uKdLyKBFeqKhhwNuz9B+LauD2Cv8uwY5P SJjza3EyR6qyKKgm9J+8vMH4SddQVXBiDyCGLc7Px29m523oi4LiKQAM/mtB2QwAz/4/ RGFzjMsZZF4JBmC8/pi40/5LDOY5rzWnNKLEqptNGGD46y4im7De3rXLK16rhepUJhbQ w30uGod/JK1Fdh9PCn1OdZzR0lxk/hBYg0ZUYX/gJYv/gv8GoFpkxb22BddYxIaw5DXN vLrw== X-Received: by 10.68.1.226 with SMTP id 2mr15963365pbp.150.1371533688959; Mon, 17 Jun 2013 22:34:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Mon, 17 Jun 2013 22:34:08 -0700 (PDT) In-Reply-To: References: <51BF5F00.90705@jitsi.org> From: Peter Thatcher Date: Mon, 17 Jun 2013 22:34:08 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=bcaec5314817541c6904df6712dd X-Gm-Message-State: ALoCoQlnr5gtICT79AuuiJ0EJGql4wqc0t75oQU9Lzg1/6QXyypmwrSiChnTrLEAsaU94PRAi0st4eAtbGvDCCOipymkMmeWWpPqqsBV1H+IB1KhQ+wnB+vfzlztx9IRx18ySzb62AwgfPXptKAzE8UbWbZ7ftL2jUe3VtYEoINbmnxsh6wGMzcoAcYujTeIwyn5j0drvmky Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 05:34:49 -0000 --bcaec5314817541c6904df6712dd Content-Type: text/plain; charset=UTF-8 I like your comparison to the data channels. As I just pointed out in another email, I think it was good that we "contained the SDP monster", as you put it, with createDataChannel. One of the purposes of createLocalStream/createRemoteStream is to allow a JS app, if it chooses, to "contain the SDP monster" when adding media streams. It would still be needed for setting up the PeerConnection's transport (a monster container for a future day perhaps), but that's still significant progress in my book, and it does so with simple additions to the PeerConnection that don't attempt to blow up the WG. On Mon, Jun 17, 2013 at 5:14 PM, Bernard Aboba wrote: > > > > 2) Dissadvantages of using SDP in WebRTC. > > > Roman said: > "An unmanageable monster was created which currently stays in the way of > developing new functionality (bundle), building applications (does not > provide obvious ways to implement obvious tasks, like adding an extra > stream without re-negotiating all the existing ones) and even interop with > existing SIP endpoints (which was the original but now is complicated since > it would require a non trivial set of constraints and subsequent SDP > manipulation)." > > [BA] Hard to argue with this, but I would point out that by far the > ugliest part of the monster is the video hindquarters. While one could > argue that we have been living with the warts of SDP for audio and > therefore know the workarounds, with video there are substantial > interoperability issues, *even among vendors who utilize the same > codec*, sometimes even in relatively basic scenarios (e.g. P2P video call > with H.264/SVC). So the "multivendor legacy of interop" just doesn't exist > yet (at least, based on standards). > > So as I see it, it does represent progress that we have contained the SDP > monster's impact on the the data channel, and I welcome Peter's effort to > enable applications who don't care about SDP to minimize its usage even if > it is not eliminated entirely. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec5314817541c6904df6712dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I like your comparison to the data channels. =C2=A0As I ju= st pointed out in another email, I think it was good that we "containe= d the SDP monster", as you put it, with createDataChannel. =C2=A0One o= f the purposes of createLocalStream/createRemoteStream is to allow a JS app= , if it chooses, to "contain the SDP monster" when adding media s= treams. =C2=A0It would still be needed for setting up the PeerConnection= 9;s transport (a monster container for a future day perhaps), but that'= s still significant progress in my book, and it does so with simple additio= ns to the PeerConnection that don't attempt to blow up the WG.


    On Mon, Jun 1= 7, 2013 at 5:14 PM, Bernard Aboba <bernard_aboba@hotmail.com&g= t; wrote:
    =C2=A0
    =C2=A0
    2) Dissadvantages of using SDP in WebRTC.

    Roman said:
    "An unmanageable monster was cr= eated which currently stays in the way of developing new functionality (bun= dle), building applications (does not provide obvious ways to implement obv= ious tasks, like adding an extra stream without re-negotiating all the exis= ting ones) and even interop with existing SIP endpoints (which was the orig= inal but now is complicated since it would require a non trivial set of con= straints and subsequent SDP manipulation)."
    =C2=A0
    [BA] Hard to argue with this, but I would point= out that by far the ugliest part of the monster is the video hindquarters.= =C2=A0 While one could argue that we have been living with the warts of SDP= for audio and therefore know the workarounds, with video there are substan= tial interoperability issues, *even among vendors who utilize the same code= c*,=C2=A0sometimes even in relatively basic scenarios (e.g. P2P video call = with H.264/SVC).=C2=A0 So the "multivendor legacy of interop" jus= t doesn't exist yet (at least, based on standards).
    =C2=A0
    So as I see it, it does represent progress that we ha= ve=C2=A0contained the SDP monster's=C2=A0impact on the=C2=A0 the data c= hannel, and I welcome Peter's effort to enable applications who don'= ;t care about SDP to minimize its usage even if it is not eliminated entire= ly.=C2=A0 =C2=A0

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


    --bcaec5314817541c6904df6712dd-- From pthatcher@google.com Mon Jun 17 22:45:36 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FBF21F9963 for ; Mon, 17 Jun 2013 22:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.34 X-Spam-Level: X-Spam-Status: No, score=-1.34 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shdLtIkKoYFR for ; Mon, 17 Jun 2013 22:45:34 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id BEB2F21F8F09 for ; Mon, 17 Jun 2013 22:45:33 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id wz7so3551699pbc.37 for ; Mon, 17 Jun 2013 22:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EHwed8ig4JTvE7K/QttUerUdcEORfKlWnjUzyQNdcY0=; b=FEutrv/ZSXJ0CFrEW2kMwXgTRDvWh54TvnbMpenv9q62HB+NLPL84S2YJJQkhiP9Y1 Zlbw9xT+awSbm18O3htwLc78Ek5eSX8DVFbOEV5iA6nW7J5LTwj8Wkml9oqE29m8Bawl hrDBjjeg/TyMi9RZLdGdbIKSNlL2016eAUq07adhGjknQvCcHzcJ14Pvxcvp9sM1h9b2 sohJF7Z26PPEp9xrBZ+Lpos12JG8+2nICOyWPBM5RkxT/ggM/N5q0EBdKMGamldGe0BD uXmIMf4U+yaCF3cgSUOt7SbhySlEKyL2I7dS8BINGdVZCgDdyi1sYS9ysVnSJ7rzsg// 6yqA== 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=EHwed8ig4JTvE7K/QttUerUdcEORfKlWnjUzyQNdcY0=; b=nT6ASxndLuiH4z5uChCgefKJ2xnj6g1leB6+9OxH3+MVIgTwrhQNbJGuZd2bxsEJW3 AswfLbE9RKX84IU+8/VY4wM3b8VmO7+rG/qHsLJ4VmLZiNLQtR7Q3HgqC2RtSzqpDOvR biHVh7siRe0m1XlfFwM96sbA+w6+4cXYAb5Z0DYDesKBdMXUXURvSBDYhnpzACtRLMtV xqaXKpJWEQWQ1zG/niQLIVmC9fIPnINVfmFbW2UoVuvTWWCd6wxv18YOgTEFGJFA6Hey gERrl/OsV3WieOKILV0gEVF0aWhPB07Eas1OzsOLVsw5fosURHlFN+hqUKEv8ekH4qEC 629w== X-Received: by 10.66.83.7 with SMTP id m7mr699803pay.150.1371534333291; Mon, 17 Jun 2013 22:45:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Mon, 17 Jun 2013 22:44:53 -0700 (PDT) In-Reply-To: <57A15FAF9E58F841B2B1651FFE16D28104FB3E@GENSJZMBX01.msg.int.genesyslab.com> References: <57A15FAF9E58F841B2B1651FFE16D28104FB3E@GENSJZMBX01.msg.int.genesyslab.com> From: Peter Thatcher Date: Mon, 17 Jun 2013 22:44:53 -0700 Message-ID: To: Jim Barnett Content-Type: multipart/alternative; boundary=f46d042ef48dbbc36e04df673840 X-Gm-Message-State: ALoCoQkVn05GSfqzUSy1qS4s7WCkcEMAOrchF3vqYpWa6uROUVnG6wr4KA7WP8d0A8YrM2siAm5nOaZTwqu36XFeTfcABY5oOEjkQBfIuyEuGFhRyKJvEEzj0o0G/0WOxF3UWcfDgHRpPwwnSevd7tb4cikyBnnCck5g0Ays94r+9gG7284D5xN38SnXDpCTSlDbnb7/cHKG Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 05:45:36 -0000 --f46d042ef48dbbc36e04df673840 Content-Type: text/plain; charset=UTF-8 I need to write a more complete example, but it basically would be: var signalling = new AppSpecificSignalling(); var stream = getUserMedia(...); // For the example, imagine it's synchronous. var pc = new PeerConnection(...); var dc = pc.createDataChannel(...); pc.createOffer(function(offer) { pc.setLocalDescription(offer); signalling.swapTransportParams(offer.sdp, function(answerSdp) { pc.setRemoteDescription(new SessionDescription(answerSdp); }); }); var localStream = pc.createLocalStream(stream); signalling.addStream(localStream.description); signalling.onStreamAdded = function(remoteStreamDescription) { var remoteStream = pc.createRemoteStream(stream); // Render the remoteStream. }); And in all of this, the only SDP involved would be to setup the transport the data channel, which would then be used to BUNDLE audio and video over the same (with rtcp-mux, naturally). Something like this: v=0 o=- 697639972863421376 2 IN IP4 127.0.0.1 s=- t=0 0 m=application 1 DTLS/SCTP 5000 c=IN IP4 0.0.0.0 a=mid:transport a=ice-ufrag:tEP42he9r6LycvmM a=ice-pwd:cKJLuvHy9pas9rdezUZB9xet a=fingerprint:sha-256 EC:E0:95:43:B7:01:49:8B:BC:21:CC:41:7F:10:FD:92:28:B8:F8:41:07:70:77:7D:7C:47:92:30:79:C4:95:9C 10 lines of SDP (per side) is, relatively speaking, very small, and it really only contains three values: ice-ufrag/ice-pwd, and dtsl fingerprint. I may be missing something, but I think this would work. If anyone knows a reason why it wouldn't, I'm sure you'll let me know :). On Mon, Jun 17, 2013 at 1:07 PM, Jim Barnett wrote: > Peter,**** > > You say that only initial PeerConnection set up requires offer answer. > Where is that in your example? In the example, all we see on the > receiving side is that it calls createReceiveStream.**** > > ** ** > > **- **Jim **** > > ** ** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Peter Thatcher > *Sent:* Monday, June 17, 2013 3:26 PM > *To:* Martin Thomson > > *Cc:* > *Subject:* Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple > sources without encoding them in SDP)**** > > ** ** > > Yes, I was expecting you to be more supportive. I'm surprised out how > your want "all or nothing". I'm afraid if our options for a clean API are > all or nothing, we'll just end up with nothing. I'd prefer to try > incremental improvements to word toward (eventually) a clean API. **** > > ** ** > > Do you think it is impossible to work toward a clean API in an incremental > approach? If you think it's possible, I'd like to hear your thoughts on > how. **** > > ** ** > > ** ** > > By the way, these API additions would greatly minimize the amount of SDP > editing necessary for JS clients that don't use SDP for signalling. And > later incremental improvements could reduce it further. Also, it's no > longer necessary to do offer/answer for adding tracks. It's only the > intial PeerConnection setup that needs to do Offer/Answer. So, it doesn't > inherit all the problems quite as much as you described. It may be > slightly abominable, but I certainly consider it less abominable than the > SDP editing necessary without it.**** > > ** ** > > On Mon, Jun 17, 2013 at 11:57 AM, Martin Thomson > wrote:**** > > Maybe you'd expect me to be more supportive of something that looked > so much like CU-RTC-Web. It inherits all the worst properties of JSEP > (Offer/Answer, SDP editing) with a partial implementation of a clean > API. > > It's comment 22-lite. It's an abomination. If you are going to do > this, do it properly.**** > > > On 17 June 2013 05:57, Peter Thatcher wrote: > > Google is in full support of "Plan B" for encoding multiple media > sources in > > SDP, and would like to see the Plan A vs. Plan B decision resolved soon. > > Recently, though, a third option, called "NoPlan" has been proposed, but > it > > lacked the details of what a JS API would look like for NoPlan. Cullen > > asked to see such an API proposal, and so I have worked with Emil to make > > one. He will be adding it to the NoPlan draft, but I will also include > it > > in this email. > > > > Again, Google is in full support of "Plan B". But if Plan A vs. Plan B > > cannot be decided, then we support NoPlan with the following additions to > > the WebRTC JS API as an option that allows implementing either Plan A or > > Plan B in Javascript. And even if Plan A vs. Plan B is resolved, these > API > > additions would still be a big improvement for those WebRTC applications > > that don't use SDP for signalling. > > > > It is a bit long because I have added many comments and examples, but the > > actually additions only include two new methods on PeerConnection and a > few > > new dictionaries. So don't be overwhelmed :). > > > > > > > > Intro: This follows the model of createDataChannel, which has a JS > method on > > PeerConnection that makes it possible to add data channels without going > > through SDP. Furthermore, just like createDataChannel allows 2 ways to > > handle neogitation (the "I know what I'm doing; Here's what I want to > send; > > Let me signal everything" mode and the "please take care of it for me; > send > > an OPEN message" mode), this also has 2 ways to handle negotiation (the > "I > > know what I'm doing; Here's what I want to send; Let me signal > everything" > > mode and the "please take care of it for me; send SDP back and forth" > > mode). > > > > Following the success of createDataChannel, this allows simple > applications > > to Just Work and more advanced applications to easily control what they > need > > to. In particular, it's possible to use this API to implement either > Plan A > > or Plan B. > > > > // The following two method are added to RTCPeerConnection > > partial interface RTCPeerConnection { > > // Create a stream that is used to send a source stream. > > // The MediaSendStream.description can be used for signalling. > > // No media is sent until addStream(MediaSendStream) is called. > > LocalMediaStream createLocalStream(MediaStream sourceStream); > > > > // Create a stream that is used to receive media from the remote side, > > // given the parameters signalled from MedaiSendStream.description. > > MediaStream createRemoteStream(MediaStreamDescription description); > > } > > > > > > interface LocalMediaStream implements MediaStream { > > // This can be changed at any time, but especially before calling > > // PeerConnection.addStream > > attribute MediaStreamDescription description; > > } > > > > > > // Represents the parameters used to either send or receive a stream > > // over a PeerConnection. > > dictionary MediaStreamDescription { > > MediaStreamTrackDescription[] tracks; > > } > > > > > > // Represents the parameters used to either send or receive a track over > // > > a PeerConnection. A track has many "flows", which can be grouped > > // together. > > dictionary MediaStreamTrackDescription { > > // Same as the MediaStreamTrack.id > > DOMString id; > > > > // Same as the MediaStreamTrack.kind > > DOMString kind; > > > > // A track can have many "flows", such as for Simulcast, FEC, etc. > > // And they can be grouped in arbitrary ways. > > MediaFlowDescription[] flows; > > MediaFlowGroup[] flowGroups; > > } > > > > // Represents the parameters used to either send or receive a "flow" > > // over a PeerConnection. A "flow" is a media that arrives with a > > // single, unique SSRC. One to many flows together make up the media > > // for a track. For example, there may be Simulcast, FEC, and RTX > > // flows. > > dictionay MediaFlowDescription { > > // The "flow id" must be unique to the track, but need not be unique > > // outside of the track (two tracks could both have a flow with the > > // same flow ID). > > DOMString id; > > > > // Each flow can go over its own transport. If the JS sets this to a > > // transportId that doesn't have a transport setup already, the > > // browser will use SDP negotiation to setup a transport to back that > > // transportId. If This is set to an MID in the SDP, then that MID's > > // transport is used. > > DOMString transportId; > > > > // The SSRC used to send the flow. > > unsigned int ssrc; > > > > // When used as receive parameters, this indicates the possible list > > // of codecs that might come in for this flow. For exmample, a given > > // receive flow could be setup to receive any of OPUS, ISAC, or PCMU. > > // When used as send parameters, this indicates that the first codec > > // should be used, but the browser can use send other codecs if it > > // needs to because of either bandwidth or CPU constraints. > > MediaCodecDescription[] codecs; > > } > > > > > > dictionary MediaFlowGroup { > > DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc > > DOMString[] flowids; > > } > > > > dictionary MediaCodecDescription { > > unsigned byte payloadType; > > DOMString name; > > unsigned int? clockRate; > > unsigned int? bitRate; > > // A grab bag of other fmtp that will need to be further defined. > > MediaCodecParam[] params; > > } > > > > dictionary MediaCodecParam { > > DOMString key; > > DOMString value; > > } > > > > > > Notes: > > > > - When LocalMediaStreams are added using addStream, onnegotiatedneeded is > > not called, and those streams are never reflected in future SDP > exchanges. > > Indeed, it would be impossible to put them in the SDP without first > > resolving if that would be Plan A SDP or Plan B SDP. > > > > - Just like piles of attributes would need to be defined for Plan A and > for > > Plan B, similar attributes would need to be defined here (Luckily, much > > work has already been done figuring out what those parameters are :). > > > > > > Pros: > > > > - Either Plan A or Plan B or could be implemented in Javascript using > this > > API > > - It exposes all the same functionality to the Javascript as SDP, but in > a > > much nicer format that is much easier to work with. > > - Any other signalling mechanism, such as Jingle or CLUE could be > > implemented using this API. > > - There is almost no risk of signalling glare. > > - Debugging errors with misconfigured descriptions should be much easier > > with this than with large SDP blobs. > > > > > > Cons: > > > > - Now there are two slightly different ways to add streams: by creating a > > LocalMediaStream first, and not. This is, however, analogous to setting > > "negotiated: true" in createDataChannel. On way is "Just Work", and the > > other is more advanced control. > > > > - All the options in MediaCodecDescription are a bit complicated. > Really, > > this is only necessary because Plan A requires being able to specify > codec > > parameters per SSRC, and set each flow on different transports. If we > did > > not have this requirement, we could simplify. > > > > > > Example Usage: > > > > // Imagine I have MyApp, handles creating a PeerConnection, > > // signalling, and rendering streams. This is how the new API could be > > // used. > > var peerConnection = MyApp.createPeerConnection(); > > > > // On sender side: > > var stream = MyApp.getMediaStream(); > > var localStream = peerConnection.createSendStream(stream); > > sendStream.description = MyApp.modifyStream(localStream.description) > > MyApp.signalAddStream(localStream.description, function(response)) { > > if (!response.rejected) { > > // Media will not be sent. > > peerConnection.addStream(localStream); > > } > > } > > > > // On receiver side: > > MyApp.onAddStreamSignalled = function(streamDescription) { > > var stream = peerConnection.createReceiveStream(streamDescription); > > MyApp.renderStream(stream); > > } > > > > > > // In this exchange, the MediaStreamDescription signalled from the > > // sender to the receiver may have looked something like this: > > > > { > > tracks: [ > > { > > id: "audio1", > > kind: "audio", > > flows: [ > > { > > id: "main", > > transportId: "transport1", > > ssrc: 1111, > > codecs: [ > > { > > payloadType: 111, > > name: "opus", > > // ... more codec details > > }, > > { > > payloadType: 112, > > name: "pcmu", > > // ... more codec details > > }] > > }] > > }, > > { > > id: "video1", > > kind: "video", > > flows: [ > > { > > id: "sim0", > > transportId: "transport2", > > ssrc: 2222, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8" > > // ... more codec details > > }] > > }, > > { > > id: "sim1", > > transportId: "transport2", > > ssrc: 2223, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... more codec details > > }] > > }, > > { > > id: "sim2", > > transportId: "transport2", > > ssrc: 2224, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... more codec details > > }] > > }, > > > > { > > id: "sim0fec", > > transportId: "transport2", > > ssrc: 2225, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... > > }] > > }], > > flowGroups: [ > > { > > semantics: "SIM", > > ssrcs: [2222, 2223, 2224] > > }, > > { > > semantics: "FEC", > > ssrcs: [2222, 2225] > > }] > > }] > > } > > > > > > Constructive feedback is welcome :). > >**** > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > >**** > > ** ** > --f46d042ef48dbbc36e04df673840 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I need to write a more complete example, but it basically = would be:

    var signalling =3D new AppSpecificSignalling()= ;
    var stream =3D getUserMedia(...); =C2=A0// For the example, ima= gine it's synchronous.
    var pc =3D new PeerConnection(...);
    var dc =3D pc.createData= Channel(...);
    pc.createOffer(function(offer) {
    =C2=A0 p= c.setLocalDescription(offer);
    =C2=A0 signalling.swapTransportPara= ms(offer.sdp, function(answerSdp) {
    =C2=A0 =C2=A0 pc.setRemoteDescription(new SessionDescription(answerSdp= );
    =C2=A0 });
    });
    var localStream =3D pc.crea= teLocalStream(stream);
    signalling.addStream(localStream.descripti= on);
    signalling.onStreamAdded =3D function(remoteStreamDescription) {
    = =C2=A0 var remoteStream =3D pc.createRemoteStream(stream);
    =C2=A0= // Render the remoteStream.
    });

    And in = all of this, the only SDP involved would be to setup the transport the data= channel, which would then be used to BUNDLE audio and video over the same = (with rtcp-mux, naturally). =C2=A0Something like this:

    v=3D0 o=3D- 697639972863421376 2 IN IP4 127.0.0.1
    s=3D-
    t=3D0 0
    m=3Dappl= ication 1 DTLS/SCTP 5000
    c=3DIN IP4 0.0.0.0
    a=3Dmid:transport    <= /p>

    a=3Dice-ufrag:tEP42he9r6LycvmM
    a=3Dice-pwd:cKJLuvHy9pas9rdezUZB9xet
    a=3Dfingerprint:sha-256 EC:E0:95:43= :B7:01:49:8B:BC:21:CC:41:7F:10:FD:92:28:B8:F8:41:07:70:77:7D:7C:47:92:30:79= :C4:95:9C



    10 lines of SDP (per side) is,= relatively speaking, very small, and it really only contains three values:= ice-ufrag/ice-pwd, and dtsl fingerprint. =C2=A0

    I= may be missing something, but I think this would work. =C2=A0If anyone kno= ws a reason why it wouldn't, I'm sure you'll let me know :).



    On Mon, Jun 17, 2013 at 1:07 PM, Jim Barnett <= Jim.Barnett= @genesyslab.com> wrote:

    Peter,

    You say that only initial PeerConnection set up requires offer answer. = =C2=A0=C2=A0Where is that in your example?=C2=A0 In the example, all we see on the receiving side is that it calls createReceiveStream.<= /span>

    =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 Peter Thatcher
    Sent: Monday, June 17, 2013 3:26 PM
    To: Martin Thomson


    Cc: <rtcweb@= ietf.org>
    Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multi= ple sources without encoding them in SDP)

    =C2=A0

    Yes, I was expecting you to be more supportive. =C2= =A0I'm surprised out how your want "all or nothing". =C2=A0I&= #39;m afraid if our options for a clean API are all or nothing, we'll j= ust end up with nothing. =C2=A0I'd prefer to try incremental improvemen= ts to word toward (eventually) a clean API.=C2=A0

    =C2=A0

    Do you think it is impossible to work toward a clean= API in an incremental approach? =C2=A0If you think it's possible, I= 9;d like to hear your thoughts on how.=C2=A0

    =C2=A0

    =C2=A0

    By the way, these API additions would greatly minimi= ze the amount of SDP editing necessary for JS clients that don't use SD= P for signalling. =C2=A0And later incremental improvements could reduce it = further. =C2=A0Also, it's no longer necessary to do offer/answer for adding tracks. =C2=A0It's only the intial PeerConn= ection setup that needs to do Offer/Answer. =C2=A0So, it doesn't inheri= t all the problems quite as much as you described. =C2=A0It may be slightly= abominable, but I certainly consider it less abominable than the SDP editing necessary without it.

    =C2=A0<= /p>

    On Mon, Jun 17, 2013 at 11:57 AM, Martin Thomson <= ;martin.thoms= on@gmail.com> wrote:

    Maybe you'd expect me to be more supportive of s= omething that looked
    so much like CU-RTC-Web. =C2=A0It inherits all the worst properties of JSEP=
    (Offer/Answer, SDP editing) with a partial implementation of a clean
    API.

    It's comment 22-lite. =C2=A0It's an abomination. =C2=A0If you are g= oing to do
    this, do it properly.


    On 17 June 2013 05:57, Peter Thatcher <pthatcher@google.com> wrote:
    > Google is in full support of "Plan B" for encoding multiple = media sources in
    > SDP, and would like to see the Plan A vs. Plan B decision resolved soo= n.
    > Recently, though, a third option, called "NoPlan" has been p= roposed, but it
    > lacked the details of what a JS API would look like for NoPlan. =C2=A0= Cullen
    > asked to see such an API proposal, and so I have worked with Emil to m= ake
    > one. =C2=A0He will be adding it to the NoPlan draft, but I will also i= nclude it
    > in this email.
    >
    > Again, Google is in full support of "Plan B". =C2=A0But if P= lan A vs. Plan B
    > cannot be decided, then we support NoPlan with the following additions= to
    > the WebRTC JS API as an option that allows implementing either Plan A = or
    > Plan B =C2=A0in Javascript. =C2=A0And even if Plan A vs. Plan B is res= olved, these API
    > additions would still be a big improvement for those WebRTC applicatio= ns
    > that don't use SDP for signalling.
    >
    > It is a bit long because I have added many comments and examples, but = the
    > actually additions only include two new methods on PeerConnection and = a few
    > new dictionaries. =C2=A0So don't be overwhelmed :).
    >
    >
    >
    > Intro: This follows the model of createDataChannel, which has a JS met= hod on
    > PeerConnection that makes it possible to add data channels without goi= ng
    > through SDP. =C2=A0Furthermore, just like createDataChannel allows 2 w= ays to
    > handle neogitation (the "I know what I'm doing; =C2=A0Here= 9;s what I want to send;
    > Let me signal everything" mode and the "please take care of = it for me; =C2=A0send
    > an OPEN message" mode), this also has 2 ways to handle negotiatio= n (the "I
    > know what I'm doing; Here's what I want to send; Let me signal= everything"
    > mode and the "please take care of it for me; =C2=A0send SDP back = and forth"
    > mode).
    >
    > Following the success of createDataChannel, this allows simple applica= tions
    > to Just Work and more advanced applications to easily control what the= y need
    > to. =C2=A0In particular, it's possible to use this API to implemen= t either Plan A
    > or Plan B.
    >
    > // The following two method are added to RTCPeerConnection
    > partial interface RTCPeerConnection {
    > =C2=A0// Create a stream that is used to send a source stream.
    > =C2=A0// The MediaSendStream.description can be used for signalling. > =C2=A0// No media is sent until addStream(MediaSendStream) is called.<= br> > =C2=A0LocalMediaStream createLocalStream(MediaStream sourceStream); >
    > =C2=A0// Create a stream that is used to receive media from the remote= side,
    > =C2=A0// given the parameters signalled from MedaiSendStream.descripti= on.
    > =C2=A0MediaStream createRemoteStream(MediaStreamDescription descriptio= n);
    > }
    >
    >
    > interface LocalMediaStream implements MediaStream {
    > =C2=A0 // This can be changed at any time, but especially before calli= ng
    > =C2=A0 // PeerConnection.addStream
    > =C2=A0 attribute MediaStreamDescription description;
    > }
    >
    >
    > // Represents the parameters used to either send or receive a stream > // over a PeerConnection.
    > dictionary MediaStreamDescription {
    > =C2=A0 MediaStreamTrackDescription[] tracks;
    > }
    >
    >
    > // Represents the parameters used to either send or receive a track ov= er //
    > a PeerConnection. =C2=A0A track has many "flows", which can = be grouped
    > // together.
    > dictionary MediaStreamTrackDescription {
    > =C2=A0 // Same as the MediaStreamTrack.id
    > =C2=A0 DOMString id;
    >
    > =C2=A0 // Same as the MediaStreamTrack.kind
    > =C2=A0 DOMString kind;
    >
    > =C2=A0 // A track can have many "flows", such as for Simulca= st, FEC, etc.
    > =C2=A0 // And they can be grouped in arbitrary ways.
    > =C2=A0 MediaFlowDescription[] flows;
    > =C2=A0 MediaFlowGroup[] flowGroups;
    > }
    >
    > // Represents the parameters used to either send or receive a "fl= ow"
    > // over a PeerConnection. =C2=A0A "flow" is a media that arr= ives with a
    > // single, unique SSRC. =C2=A0One to many flows together make up the m= edia
    > // for a track. =C2=A0For example, there may be Simulcast, FEC, and RT= X
    > // flows.
    > dictionay MediaFlowDescription {
    > =C2=A0 // The "flow id" must be unique to the track, but nee= d not be unique
    > =C2=A0 // outside of the track (two tracks could both have a flow with= the
    > =C2=A0 // same flow ID).
    > =C2=A0 DOMString id;
    >
    > =C2=A0 // Each flow can go over its own transport. =C2=A0If the JS set= s this to a
    > =C2=A0 // transportId that doesn't have a transport setup already,= the
    > =C2=A0 // browser will use SDP negotiation to setup a transport to bac= k that
    > =C2=A0 // transportId. =C2=A0If This is set to an MID in the SDP, then= that MID's
    > =C2=A0 // transport is used.
    > =C2=A0 DOMString transportId;
    >
    > =C2=A0 // The SSRC used to send the flow.
    > =C2=A0 unsigned int ssrc;
    >
    > =C2=A0 // When used as receive parameters, this indicates the possible= list
    > =C2=A0 // of codecs that might come in for this flow. =C2=A0For exmamp= le, a given
    > =C2=A0 // receive flow could be setup to receive any of OPUS, ISAC, or= PCMU.
    > =C2=A0 // When used as send parameters, this indicates that the first = codec
    > =C2=A0 // should be used, but the browser can use send other codecs if= it
    > =C2=A0 // needs to because of either bandwidth or CPU constraints.
    > =C2=A0 MediaCodecDescription[] codecs;
    > }
    >
    >
    > dictionary MediaFlowGroup {
    > =C2=A0 DOMString type; =C2=A0// "SIM" for Simulcast, "F= EC" for FEC, etc
    > =C2=A0 DOMString[] flowids;
    > }
    >
    > dictionary MediaCodecDescription {
    > =C2=A0 unsigned byte payloadType;
    > =C2=A0 DOMString name;
    > =C2=A0 unsigned int? clockRate;
    > =C2=A0 unsigned int? bitRate;
    > =C2=A0 // A grab bag of other fmtp that will need to be further define= d.
    > =C2=A0 MediaCodecParam[] params;
    > }
    >
    > dictionary MediaCodecParam {
    > =C2=A0 DOMString key;
    > =C2=A0 DOMString value;
    > }
    >
    >
    > Notes:
    >
    > - When LocalMediaStreams are added using addStream, onnegotiatedneeded= is
    > not called, and those streams are never reflected in future SDP exchan= ges.
    > Indeed, it would be impossible to put them in the SDP without first > resolving if that would be Plan A SDP or Plan B SDP.
    >
    > - Just like piles of attributes would need to be defined for Plan A an= d for
    > Plan B, similar attributes would need to be defined here (Luckily, =C2= =A0much
    > work has already been done figuring out what those parameters are :).<= br> >
    >
    > Pros:
    >
    > - Either Plan A or Plan B or could be implemented in Javascript using = this
    > API
    > - It exposes all the same functionality to the Javascript as SDP, but = in a
    > much nicer format that is much easier to work with.
    > - Any other signalling mechanism, such as Jingle or CLUE could be
    > implemented using this API.
    > - There is almost no risk of signalling glare.
    > - Debugging errors with misconfigured descriptions should be much easi= er
    > with this than with large SDP blobs.
    >
    >
    > Cons:
    >
    > - Now there are two slightly different ways to add streams: by creatin= g a
    > LocalMediaStream first, and not. =C2=A0This is, however, analogous to = setting
    > "negotiated: true" in createDataChannel. =C2=A0On way is &qu= ot;Just Work", and the
    > other is more advanced control.
    >
    > - All the options in MediaCodecDescription are a bit complicated. =C2= =A0Really,
    > this is only necessary because Plan A requires being able to specify c= odec
    > parameters per SSRC, and set each flow on different transports. =C2=A0= If we did
    > not have this requirement, we could simplify.
    >
    >
    > Example Usage:
    >
    > // Imagine I have MyApp, handles creating a PeerConnection,
    > // signalling, and rendering streams. =C2=A0This is how the new API co= uld be
    > // used.
    > var peerConnection =3D MyApp.createPeerConnection();
    >
    > // On sender side:
    > var stream =3D MyApp.getMediaStream();
    > var localStream =3D peerConnection.createSendStream(stream);
    > sendStream.description =3D MyApp.modifyStream(localStream.description)=
    > MyApp.signalAddStream(localStream.description, function(response)) { > =C2=A0 if (!response.rejected) {
    > =C2=A0 =C2=A0 // Media will not be sent.
    > =C2=A0 =C2=A0 peerConnection.addStream(localStream);
    > =C2=A0 }
    > }
    >
    > // On receiver side:
    > MyApp.onAddStreamSignalled =3D function(streamDescription) {
    > =C2=A0 var stream =3D peerConnection.createReceiveStream(streamDescrip= tion);
    > =C2=A0 MyApp.renderStream(stream);
    > }
    >
    >
    > // In this exchange, the MediaStreamDescription signalled from the
    > // sender to the receiver may have looked something like this:
    >
    > {
    > =C2=A0 tracks: [
    > =C2=A0 {
    > =C2=A0 =C2=A0 id: "audio1",
    > =C2=A0 =C2=A0 kind: "audio",
    > =C2=A0 =C2=A0 flows: [
    > =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 id: "main",
    > =C2=A0 =C2=A0 =C2=A0 transportId: "transport1",
    > =C2=A0 =C2=A0 =C2=A0 ssrc: 1111,
    > =C2=A0 =C2=A0 =C2=A0 codecs: [
    > =C2=A0 =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 111,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 name: "opus",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 },
    > =C2=A0 =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 112,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 name: "pcmu",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 }]
    > =C2=A0 =C2=A0}]
    > =C2=A0},
    > =C2=A0{
    > =C2=A0 =C2=A0 id: "video1",
    > =C2=A0 =C2=A0 kind: "video",
    > =C2=A0 =C2=A0 flows: [
    > =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 id: "sim0",
    > =C2=A0 =C2=A0 =C2=A0 transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0 ssrc: 2222,
    > =C2=A0 =C2=A0 =C2=A0 codecs: [
    > =C2=A0 =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 name: "vp8"
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 }]
    > =C2=A0 =C2=A0},
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0id: "sim1",
    > =C2=A0 =C2=A0 =C2=A0transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0ssrc: 2223,
    > =C2=A0 =C2=A0 =C2=A0codecs: [
    > =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "vp8",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0// ... more codec details
    > =C2=A0 =C2=A0 =C2=A0}]
    > =C2=A0 =C2=A0},
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0id: "sim2",
    > =C2=A0 =C2=A0 =C2=A0transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0ssrc: 2224,
    > =C2=A0 =C2=A0 =C2=A0codecs: [
    > =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "vp8",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0// ... more codec details
    > =C2=A0 =C2=A0 =C2=A0}]
    > =C2=A0 =C2=A0},
    >
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0id: "sim0fec",
    > =C2=A0 =C2=A0 =C2=A0transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0ssrc: 2225,
    > =C2=A0 =C2=A0 =C2=A0codecs: [
    > =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "vp8",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0// ...
    > =C2=A0 =C2=A0 =C2=A0}]
    > =C2=A0 =C2=A0}],
    > =C2=A0 =C2=A0flowGroups: [
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0semantics: "SIM",
    > =C2=A0 =C2=A0 =C2=A0ssrcs: [2222, 2223, 2224]
    > =C2=A0 =C2=A0},
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0semantics: "FEC",
    > =C2=A0 =C2=A0 =C2=A0ssrcs: [2222, 2225]
    > =C2=A0 =C2=A0}]
    > =C2=A0}]
    > }
    >
    >
    > Constructive feedback is welcome :).
    >

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

    =C2=A0


    --f46d042ef48dbbc36e04df673840-- From pthatcher@google.com Mon Jun 17 22:49:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3DEA21F9DCE for ; Mon, 17 Jun 2013 22:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1S6Nh2hxfHK for ; Mon, 17 Jun 2013 22:48:59 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id C25BC21F9DCD for ; Mon, 17 Jun 2013 22:48:59 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id um15so3529073pbc.10 for ; Mon, 17 Jun 2013 22:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tdWPjvqM1/f5Jq9xYBnWfyGv5dvuctPlf1wd/XmgtyM=; b=AfZIduBzlUrzRuhWBhN/Ripp4/JxynknZ6GvIGbREMZZEFtTZPuN1iCCyDSUjAhhng uhRfP3C7uCXbX+GO675pR5sijN304kKND62f+iI9JaRfGXTF7gOslzP+IC96gwlEpmym p5zAN8bUJnAaUSdJYuSjskWoUERcMlIHvDCj03CJ6+o8DagK4M5zU7zJiY3s2AN9NeT7 6t+oTEjD5ip9ItFMZ3AeqOOVML61oO8xH6y5/VHMx9136GvDqha7YMp8N4qAsMedO+9v NNenlLZvJCpqeGQ0B585M95Jj7f3P8jPNsDT9gIKt2E7zmYjYcllHQ79DSv2YPhP+Q5T ZzMg== 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=tdWPjvqM1/f5Jq9xYBnWfyGv5dvuctPlf1wd/XmgtyM=; b=Jl6bY2MB5pq5DpjWyB8IZ3sE61NfDqZJbKgvybsOT7rL7NIzB+wuSqreIgw4fT14Hp Cc9wPvxUAEBDmkm+005RaV4JwsJGIYl6M/UDdI/x8Zo5Xtd5hymqRbJV17HKa+FcHGwS WZEUsvJmSjywohti5pYPo4ati0nduwlH0AU8+fXSWeYtlaJoxKDn2P/B2FPrN/0gCu1i l1OcIHnetLFmUjbCDPJkHsYmgIGONimqbxGkefmTBOkkJoB+dcOyre4O6rJEece6DqUJ jew89Wkr1XruThz3BWtluDnJjdBXuSD7dggSfSmm0BcxScKuwEpqkjPJD3CD7W9MgcsW E9SA== X-Received: by 10.68.69.108 with SMTP id d12mr15786420pbu.187.1371534539338; Mon, 17 Jun 2013 22:48:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Mon, 17 Jun 2013 22:48:19 -0700 (PDT) In-Reply-To: References: <51BF5F00.90705@jitsi.org> From: Peter Thatcher Date: Mon, 17 Jun 2013 22:48:19 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=0015174989ee03db0a04df674579 X-Gm-Message-State: ALoCoQldaf+n4xNec71dbBVmWqazrLsQ6JoShuf8Zv+ht9SSykgQEOewBH4Tj+h+rbC2IiK57WHrT05G/u99cYqOZcwj4ZyJQnQX8HBAu8n9FELyl2cKvN9zKdp6EsTwJDMnYU6n0TU1teWel1epAvDZH4m+JSuRaxx4xmfRGoYjJep/0vXVXfGPkIIGf+hzitPcXep4Y9QP Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 05:49:00 -0000 --0015174989ee03db0a04df674579 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We're being very explicit that this isn't intended to blow up the WG like comment 22 does. It's merely adding two methods to PeerConnection that allows JS apps to optionally avoid the issues of adding many media streams to SDP. We're focusing on making the smallest change that can bring the biggest value, not rewriting all of WebRTC from scratch. On Mon, Jun 17, 2013 at 2:56 PM, I=C3=B1aki Baz Castillo wr= ote: > 2013/6/17 Martin Thomson : > > On 17 June 2013 12:09, Emil Ivov wrote: > >> So here's your chance: could you please share your view of how this > would > >> look if done properly? > > > > Actually, it would look very similar to this. For everything. No SDP > > anywhere. It's comment 22. > > > > It's in the archives of the webrtc list: > > > http://lists.w3.org/Archives/Public/public-webrtc/2012Oct/att-0076/realti= me-media.html > > +1 > > > What is the aim of NoPlan? The draft says "This document does not > question the use of SDP and the Offer/Answer model". Why? It should > question it since it treats SDP as if it was a silly and unmanageable > binary blob. It is like "we must live with SDP because it is > mandatory, but let's try to ignore it as much as possible". If so, why > don't ignore SDP entirely? > > However NoPlan is the best we have if, finally, SDP is mandated in WebRTC= . > > I think it is time to write two lists: > > 1) Advantages of using SDP in WebRTC. > > 2) Dissadvantages of using SPD in WebRTC. > > > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0015174989ee03db0a04df674579 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    We're being very explicit that this isn't intended= to blow up the WG like comment 22 does. =C2=A0It's merely adding two m= ethods to PeerConnection that allows JS apps to optionally avoid the issues= of adding many media streams to SDP. =C2=A0We're focusing on making th= e smallest change that can bring the biggest value, not rewriting all of We= bRTC from scratch.


    On Mon, Jun 1= 7, 2013 at 2:56 PM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wr= ote:
    2013/6/17 Martin Thomson <ma= rtin.thomson@gmail.com>:
    > On 17 June 2013 12:09, Emil Ivov <emcho@jitsi.org> wrote:
    >> So here's your chance: could you please share your view of how= this would
    >> look if done properly?
    >
    > Actually, it would look very similar to this. =C2=A0For everything. = =C2=A0No SDP
    > anywhere. =C2=A0It's comment 22.
    >
    > It's in the archives of the webrtc list:
    > http://lists.w3.org/Archives= /Public/public-webrtc/2012Oct/att-0076/realtime-media.html

    +1


    What is the aim of NoPlan? The draft says "This document does not
    question the use of SDP and the Offer/Answer model". Why? It should question it since it treats SDP as if it was a silly and unmanageable
    binary blob. It is like "we must live with SDP because it is
    mandatory, but let's try to ignore it as much as possible". If so,= why
    don't ignore SDP entirely?

    However NoPlan is the best we have if, finally, SDP is mandated in WebRTC.<= br>
    I think it is time to write two lists:

    1) Advantages of using SDP in WebRTC.

    2) Dissadvantages of using SPD in WebRTC.


    --
    I=C3=B1aki Baz Castillo
    <ibc@aliax.net>
    _____________________________= __________________
    rtcweb mailing list
    rtcweb@ietf.org
    = https://www.ietf.org/mailman/listinfo/rtcweb

    --0015174989ee03db0a04df674579-- From emil@sip-communicator.org Mon Jun 17 23:17:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A0A21F9ADA for ; Mon, 17 Jun 2013 23:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsU2e0Iy3v0s for ; Mon, 17 Jun 2013 23:17:13 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2F73621F9A42 for ; Mon, 17 Jun 2013 23:17:12 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b12so3082583wgh.19 for ; Mon, 17 Jun 2013 23:17:11 -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=Us2hfQdYkQEa2tDb6JoWxJV813FiRPInMlPn7+lBm68=; b=eWTPIgIRCv9ggneOhO5e0zkIrZtxb05z+ZQuWL6UFmCYwtQa/v0VffJ2JIDh7g9sl9 HXIrv7y1LmqmyU1ZXa4dN2F+hzesYZqMhaTj+t0aZCSYo3wlTd48pw31e9MffIkNoM2L 2BEYMg+4RE1t7qKJOh2VQCawHRo0L2sOL/Tq5qVAbeCu3atwGMF3CBNg6f8AAOAYPBdq p9OUZYj0ADR7DNDpjTUE+W3n3VlOqT/2nKkwFsuMYfmYkZfvJoKZYRKVG66vheJ2oKHu 8yb/HU35gU1ArGZaX8ooAg96KxLdkfpKkVUnQlk8qHKSkMbNCw2tdkapkrodI4iMpBNX ZZRQ== X-Received: by 10.180.75.110 with SMTP id b14mr6729349wiw.6.1371536231926; Mon, 17 Jun 2013 23:17:11 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:898c:abd3:25f1:23ca]) by mx.google.com with ESMTPSA id ay7sm26388337wib.9.2013.06.17.23.17.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Jun 2013 23:17:11 -0700 (PDT) Message-ID: <51BFFB65.2020203@jitsi.org> Date: Tue, 18 Jun 2013 08:17:09 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Silvia Pfeiffer References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlWIIvh44p0W82Ip86+VHt72ik3AgXw1Xi+UVVbuno2bJG01o4CjMbcMr1aPrtZG8Z5iGtC Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 06:17:14 -0000 Hey Silvia, On 18.06.13, 03:00, Silvia Pfeiffer wrote: > What I would like to see, though, is a bit different from what you've > proposed. In particular, the MediaFlowDescription object is the one > object that I believe is supposed to enable JS developers to do "SDP > hacking" without having to understand SDP. Unfortunately, the way in > which it is currently written, this API doesn't help a JS developer > much. There are properties in that object like "ssrc" that mean > nothing unless you understand SDP. SSRC is really just a flow identifier and it actually comes from RTP, not SDP. Using SSRCs is important because they are the only way to refer to an RTP flow. Any other identifier (such as an MSID) would have to be mapped to an SSRC. Such a mapping could only happen in SDP and would have to be updated when new streams are added which brings us back to over-reliance on SDP Offer/Answer, which is what No Plan is trying to alleviate. Emil -- https://jitsi.org From silviapfeiffer1@gmail.com Mon Jun 17 23:25:26 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF1F21F9CB8 for ; Mon, 17 Jun 2013 23:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vps+yk6QwfhJ for ; Mon, 17 Jun 2013 23:25:26 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7735F21F9CB7 for ; Mon, 17 Jun 2013 23:25:26 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id fb19so4155571obc.37 for ; Mon, 17 Jun 2013 23:25: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:from:date:message-id:subject:to :cc:content-type; bh=zH/XXsh9Np8Qq0nIDlVrKmcazgHy8RmNFYxzhBZWWVs=; b=FNrCPrkJ70Jprqo6AT4CcdR0qZEwUOoO5FXDGSbSYSarOQ/M4YkNBczpxZjn1SBm7i PrKxIgGVl/l65WTIZq1Cwhd4Y6RG/wZgl3xWmMO1HdlESdqroQ58ci28lvpjpMOu6yxo aUQdSfjQsX/XOwymMYZqFjqQ4d3bTLjaFSie1xILa0hGtD+Bp2uBSsNgYt51StL415EG l55geuXIB5k1YKlITTUlRlAEmlFcx3GeyPvxNilpf6/IQcBVUEnI1I3O4WV1iHHsA6U2 pyRJTpnxgImT+Gkek9OfESeYORv5XcZOxamJjEhgps7mYn1woOQqoaHeJes2qKmk+Bva H/5g== X-Received: by 10.60.94.113 with SMTP id db17mr11081496oeb.62.1371536726053; Mon, 17 Jun 2013 23:25:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.116.71 with HTTP; Mon, 17 Jun 2013 23:25:05 -0700 (PDT) In-Reply-To: <51BFFB65.2020203@jitsi.org> References: <51BFFB65.2020203@jitsi.org> From: Silvia Pfeiffer Date: Tue, 18 Jun 2013 16:25:05 +1000 Message-ID: To: Emil Ivov Content-Type: text/plain; charset=ISO-8859-1 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 06:25:27 -0000 On Tue, Jun 18, 2013 at 4:17 PM, Emil Ivov wrote: > Hey Silvia, > > > On 18.06.13, 03:00, Silvia Pfeiffer wrote: >> >> What I would like to see, though, is a bit different from what you've >> proposed. In particular, the MediaFlowDescription object is the one >> object that I believe is supposed to enable JS developers to do "SDP >> hacking" without having to understand SDP. Unfortunately, the way in >> which it is currently written, this API doesn't help a JS developer >> much. There are properties in that object like "ssrc" that mean >> nothing unless you understand SDP. > > > SSRC is really just a flow identifier and it actually comes from RTP, not > SDP. OK, could we call it rtpflowId or mediaflowId or peerflowId or something? And what exactly are the other identifiers? (You will notice that I am really naive wrt SDP, sorry!) Thanks, Silvia. From harald@alvestrand.no Tue Jun 18 01:11:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF8621F9446 for ; Tue, 18 Jun 2013 01:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iS66P6eLJ4gv for ; Tue, 18 Jun 2013 01:11:47 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC8221F9944 for ; Tue, 18 Jun 2013 01:11:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3D1B139E057 for ; Tue, 18 Jun 2013 10:11:44 +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 ernyNKj0GbTM for ; Tue, 18 Jun 2013 10:11:38 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 569F539E03B for ; Tue, 18 Jun 2013 10:11:38 +0200 (CEST) Message-ID: <51C01639.5050501@alvestrand.no> Date: Tue, 18 Jun 2013 10:11:37 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1447FA0C20ED5147A1AA0EF02890A64B1C2FC071@ESESSMB209.ericsson.se> <57A15FAF9E58F841B2B1651FFE16D28104C918@GENSJZMBX01.msg.int.genesyslab.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020701000808000504050507" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:11:53 -0000 This is a multi-part message in MIME format. --------------020701000808000504050507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 06/17/2013 06:20 PM, Peter Thatcher wrote: > > > > On Mon, Jun 17, 2013 at 8:21 AM, Jim Barnett > > wrote: > > What can you modify in a LocalMediaStream by editing its > description? Can you add a video track to it? That would imply > calling gUM, and you'd have to thread it's success and failure > callbacks up to the editing operation. Or is the track list > fixed, so that you can only tweak transport info by editing the > LocalMediaStream's description? > > > If the JS calls gUM to get a second MediaStreamTrack (say, for > screencast), it could simply call createLocalStream again to add it, > in a different LocalMediaStream, and the remote end would get a second > MediaStream by calling createRemoteStream. Why would you want more > than one video MediaStreamTrack in MediaStream at the same time? > > In general, before you start sending or receiving, you can edit > everything side of the MediaStreamTrackDescription: change the ssrcs, > codecs, transport, video resolution to send with, what repair flows to > include, whether to use simulcast, etc. Basically, anything on a > track level. This raises an interesting issue: Anything the user is allowed to set, the UA has to assume that the user can get wrong. So we need to have error handling for AddLocalStream saying "sorry, this is impossible". Perennial question: Exception or callback? > > But I don't really see a use case where you would need to add tracks > to a MediaStreamTrackDescription, other than when parsing signalling > and building the MediaStreamTrackDescription to send down into > createRemoteStream. Perhaps if we had a use case, we could define > such support. But otherwise, I'd say it's not allowed. > > > -Jim > > *From:*rtcweb-bounces@ietf.org > [mailto:rtcweb-bounces@ietf.org ] *On > Behalf Of *Peter Thatcher > *Sent:* Monday, June 17, 2013 11:13 AM > *To:* Stefan Håkansson LK > *Cc:* > > *Subject:* Re: [rtcweb] Proposal for a JS API for NoPlan (adding > multiple sources without encoding them in SDP) > > Answers: > > On Mon, Jun 17, 2013 at 6:58 AM, Stefan Håkansson LK > > wrote: > > A couple of questions (to help me understand) in-line //Stefan > > > On 2013-06-17 14:57, Peter Thatcher wrote: > > Google is in full support of "Plan B" for encoding multiple media > > sources in SDP, and would like to see the Plan A vs. Plan B decision > > resolved soon. Recently, though, a third option, called "NoPlan" has > > been proposed, but it lacked the details of what a JS API would look > > like for NoPlan. Cullen asked to see such an API proposal, and so I > > have worked with Emil to make one. He will be adding it to the NoPlan > > draft, but I will also include it in this email. > > > > Again, Google is in full support of "Plan B". But if Plan A vs. Plan B > > cannot be decided, then we support NoPlan with the following additions > > to the WebRTC JS API as an option that allows implementing either Plan A > > or Plan B in Javascript. And even if Plan A vs. Plan B is resolved, > > these API additions would still be a big improvement for those WebRTC > > applications that don't use SDP for signalling. > > > > It is a bit long because I have added many comments and examples, but > > the actually additions only include two new methods on PeerConnection > > and a few new dictionaries. So don't be overwhelmed :). > > > > > > > > Intro: This follows the model of createDataChannel, which has a JS > > method on PeerConnection that makes it possible to add data channels > > without going through SDP. Furthermore, just like createDataChannel > > allows 2 ways to handle neogitation (the "I know what I'm doing; Here's > > what I want to send; Let me signal everything" mode and the "please take > > care of it for me; send an OPEN message" mode), this also has 2 ways to > > handle negotiation (the "I know what I'm doing; Here's what I want to > > send; Let me signal everything" mode and the "please take care of it for > > me; send SDP back and forth" mode). > > > > Following the success of createDataChannel, this allows simple > > applications to Just Work and more advanced applications to easily > > control what they need to. In particular, it's possible to use this API > > to implement either Plan A or Plan B. > > > > // The following two method are added to RTCPeerConnection > > partial interface RTCPeerConnection { > > // Create a stream that is used to send a source stream. > > // The MediaSendStream.description can be used for signalling. > > // No media is sent until addStream(MediaSendStream) is called. > > LocalMediaStream createLocalStream(MediaStream sourceStream); > > > > // Create a stream that is used to receive media from the remote side, > > // given the parameters signalled from MedaiSendStream.description. > > MediaStream createRemoteStream(MediaStreamDescription description); > > } > > what would happen if the application adds or removes a track from > sourceStream (I'm thinking on how what would impact the created > LocalMediaStream and the MediaStream at the remote end)? > > Good question. I'd have to think about it some more, but off the bat, > I'd say that on the sender side, adding or removing tracks from the > source MediaStream would have no effect on what is sent. In other > words, it's as if the source MediaStream were cloned when > createLocalStream was called. If you want to modify the LocalStream, > you have to go through the .description. On the receiver side, it > would look like any other received MediaStream: if you remove the > track, it just doesn't play out anymore. > > > > > > > interface LocalMediaStream implements MediaStream { > > // This can be changed at any time, but especially before calling > > // PeerConnection.addStream > > attribute MediaStreamDescription description; > > } > > > > > > // Represents the parameters used to either send or receive a stream > > // over a PeerConnection. > > dictionary MediaStreamDescription { > > MediaStreamTrackDescription[] tracks; > > } > > > > > > // Represents the parameters used to either send or receive a > track over > > // a PeerConnection. A track has many "flows", which can be grouped > > // together. > > dictionary MediaStreamTrackDescription { > > // Same as the MediaStreamTrack.id > > DOMString id; > > > > // Same as the MediaStreamTrack.kind > > DOMString kind; > > > > // A track can have many "flows", such as for Simulcast, FEC, > etc. > > // And they can be grouped in arbitrary ways. > > MediaFlowDescription[] flows; > > MediaFlowGroup[] flowGroups; > > } > > > > // Represents the parameters used to either send or receive a "flow" > > // over a PeerConnection. A "flow" is a media that arrives with a > > // single, unique SSRC. One to many flows together make up the > media > > // for a track. For example, there may be Simulcast, FEC, and RTX > > // flows. > > dictionay MediaFlowDescription { > > // The "flow id" must be unique to the track, but need not be > unique > > // outside of the track (two tracks could both have a flow > with the > > // same flow ID). > > DOMString id; > > > > // Each flow can go over its own transport. If the JS sets > this to a > > // transportId that doesn't have a transport setup already, the > > // browser will use SDP negotiation to setup a transport to > back that > > // transportId. If This is set to an MID in the SDP, then > that MID's > > // transport is used. > > DOMString transportId; > > Where from do you get transportId (e.g. if you want to re-use one)? > > First, the browser would fill it in via createLocalStream. So in > almost all cases, the JS would not need to set it. In very advanced > applications that want to do tricky things with transports, then the > value should be the MID for that transport found in the SDP, as it > says in the comment. > > > > > > // The SSRC used to send the flow. > > unsigned int ssrc; > > > > // When used as receive parameters, this indicates the > possible list > > // of codecs that might come in for this flow. For exmample, > a given > > // receive flow could be setup to receive any of OPUS, ISAC, > or PCMU. > > // When used as send parameters, this indicates that the > first codec > > // should be used, but the browser can use send other codecs > if it > > // needs to because of either bandwidth or CPU constraints. > > MediaCodecDescription[] codecs; > > } > > > > > > dictionary MediaFlowGroup { > > DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc > > DOMString[] flowids; > > } > > > > dictionary MediaCodecDescription { > > unsigned byte payloadType; > > DOMString name; > > unsigned int? clockRate; > > unsigned int? bitRate; > > // A grab bag of other fmtp that will need to be further defined. > > MediaCodecParam[] params; > > } > > > > dictionary MediaCodecParam { > > DOMString key; > > DOMString value; > > } > > > > > > Notes: > > > > - When LocalMediaStreams are added using addStream, > onnegotiatedneeded > > is not called, and those streams are never reflected in future SDP > > exchanges. Indeed, it would be impossible to put them in the SDP > > without first resolving if that would be Plan A SDP or Plan B SDP. > > > > - Just like piles of attributes would need to be defined for > Plan A and > > for Plan B, similar attributes would need to be defined here > (Luckily, > > much work has already been done figuring out what those > parameters are :). > > > > > > Pros: > > > > - Either Plan A or Plan B or could be implemented in Javascript > using > > this API > > - It exposes all the same functionality to the Javascript as > SDP, but in > > a much nicer format that is much easier to work with. > > - Any other signalling mechanism, such as Jingle or CLUE could be > > implemented using this API. > > - There is almost no risk of signalling glare. > > - Debugging errors with misconfigured descriptions should be > much easier > > with this than with large SDP blobs. > > > > > > Cons: > > > > - Now there are two slightly different ways to add streams: by > creating > > a LocalMediaStream first, and not. This is, however, analogous to > > setting "negotiated: true" in createDataChannel. On way is > "Just Work", > > and the other is more advanced control. > > > > - All the options in MediaCodecDescription are a bit complicated. > > Really, this is only necessary because Plan A requires being > able to > > specify codec parameters per SSRC, and set each flow on different > > transports. If we did not have this requirement, we could simplify. > > > > > > Example Usage: > > > > // Imagine I have MyApp, handles creating a PeerConnection, > > // signalling, and rendering streams. This is how the new API > could be > > // used. > > var peerConnection = MyApp.createPeerConnection(); > > > > // On sender side: > > var stream = MyApp.getMediaStream(); > > var localStream = peerConnection.createSendStream(stream); > > sendStream.description = MyApp.modifyStream(localStream.description) > > Should it say "localStream.description"? > > Yes. There was a last-minute rename and I missed a spot. Anywhere you > see "sendStream", it should be "localStream". > > > > MyApp.signalAddStream(localStream.description, function(response)) { > > if (!response.rejected) { > > // Media will not be sent. > > peerConnection.addStream(localStream); > > } > > } > > > > // On receiver side: > > MyApp.onAddStreamSignalled = function(streamDescription) { > > var stream = > peerConnection.createReceiveStream(streamDescription); > > MyApp.renderStream(stream); > > } > > > > > > // In this exchange, the MediaStreamDescription signalled from the > > // sender to the receiver may have looked something like this: > > > > { > > tracks: [ > > { > > id: "audio1", > > kind: "audio", > > flows: [ > > { > > id: "main", > > transportId: "transport1", > > ssrc: 1111, > > codecs: [ > > { > > payloadType: 111, > > name: "opus", > > // ... more codec details > > }, > > { > > payloadType: 112, > > name: "pcmu", > > // ... more codec details > > }] > > }] > > }, > > { > > id: "video1", > > kind: "video", > > flows: [ > > { > > id: "sim0", > > transportId: "transport2", > > ssrc: 2222, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8" > > // ... more codec details > > }] > > }, > > { > > id: "sim1", > > transportId: "transport2", > > ssrc: 2223, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... more codec details > > }] > > }, > > { > > id: "sim2", > > transportId: "transport2", > > ssrc: 2224, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... more codec details > > }] > > }, > > > > { > > id: "sim0fec", > > transportId: "transport2", > > ssrc: 2225, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... > > }] > > }], > > flowGroups: [ > > { > > semantics: "SIM", > > ssrcs: [2222, 2223, 2224] > > }, > > { > > semantics: "FEC", > > ssrcs: [2222, 2225] > > }] > > }] > > } > > > > > > Constructive feedback is welcome :). > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------020701000808000504050507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    On 06/17/2013 06:20 PM, Peter Thatcher wrote:



    On Mon, Jun 17, 2013 at 8:21 AM, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:

    What can you modify in a LocalMediaStream by editing its description?  Can you add a video track to it?  That would imply calling gUM, and you’d  have to thread it’s success and failure callbacks up to the editing operation.  Or is the track list fixed, so that you can only tweak transport info by editing the LocalMediaStream’s description?

     


    If the JS calls gUM to get a second MediaStreamTrack (say, for screencast), it could simply call createLocalStream again to add it, in a different LocalMediaStream, and the remote end would get a second MediaStream by calling createRemoteStream.  Why would you want more than one video MediaStreamTrack in MediaStream at the same time?

    In general, before you start sending or receiving, you can edit everything side of the MediaStreamTrackDescription:  change the ssrcs, codecs, transport, video resolution to send with, what repair flows to include, whether to use simulcast, etc.  Basically, anything on a track level.

    This raises an interesting issue: Anything the user is allowed to set, the UA has to assume that the user can get wrong. So we need to have error handling for AddLocalStream saying "sorry, this is impossible".

    Perennial question: Exception or callback?


    But I don't really see a use case where you would need to add tracks to a MediaStreamTrackDescription, other than when parsing signalling and building the MediaStreamTrackDescription to send down into createRemoteStream.  Perhaps if we had a use case, we could define such support.  But otherwise, I'd say it's not allowed.


    -          Jim

     

    From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Peter Thatcher
    Sent: Monday, June 17, 2013 11:13 AM
    To: Stefan Håkansson LK
    Cc: <rtcweb@ietf.org>
    Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

     

    Answers:

     

    On Mon, Jun 17, 2013 at 6:58 AM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote:

    A couple of questions (to help me understand) in-line //Stefan


    On 2013-06-17 14:57, Peter Thatcher wrote:
    > Google is in full support of "Plan B" for encoding multiple media
    > sources in SDP, and would like to see the Plan A vs. Plan B decision
    > resolved soon.  Recently, though, a third option, called "NoPlan" has
    > been proposed, but it lacked the details of what a JS API would look
    > like for NoPlan.  Cullen asked to see such an API proposal, and so I
    > have worked with Emil to make one.  He will be adding it to the NoPlan
    > draft, but I will also include it in this email.
    >
    > Again, Google is in full support of "Plan B".  But if Plan A vs. Plan B
    > cannot be decided, then we support NoPlan with the following additions
    > to the WebRTC JS API as an option that allows implementing either Plan A
    > or Plan B  in Javascript.  And even if Plan A vs. Plan B is resolved,
    > these API additions would still be a big improvement for those WebRTC
    > applications that don't use SDP for signalling.
    >
    > It is a bit long because I have added many comments and examples, but
    > the actually additions only include two new methods on PeerConnection
    > and a few new dictionaries.  So don't be overwhelmed :).
    >
    >
    >
    > Intro: This follows the model of createDataChannel, which has a JS
    > method on PeerConnection that makes it possible to add data channels
    > without going through SDP.  Furthermore, just like createDataChannel
    > allows 2 ways to handle neogitation (the "I know what I'm doing;  Here's
    > what I want to send; Let me signal everything" mode and the "please take
    > care of it for me;  send an OPEN message" mode), this also has 2 ways to
    > handle negotiation (the "I know what I'm doing; Here's what I want to
    > send; Let me signal everything" mode and the "please take care of it for
    > me;  send SDP back and forth" mode).
    >
    > Following the success of createDataChannel, this allows simple
    > applications to Just Work and more advanced applications to easily
    > control what they need to.  In particular, it's possible to use this API
    > to implement either Plan A or Plan B.
    >
    > // The following two method are added to RTCPeerConnection
    > partial interface RTCPeerConnection {
    >   // Create a stream that is used to send a source stream.
    >   // The MediaSendStream.description can be used for signalling.
    >   // No media is sent until addStream(MediaSendStream) is called.
    >   LocalMediaStream createLocalStream(MediaStream sourceStream);
    >
    >   // Create a stream that is used to receive media from the remote side,
    >   // given the parameters signalled from MedaiSendStream.description.
    >   MediaStream createRemoteStream(MediaStreamDescription description);
    > }

    what would happen if the application adds or removes a track from
    sourceStream (I'm thinking on how what would impact the created
    LocalMediaStream and the MediaStream at the remote end)?

     

     

    Good question.  I'd have to think about it some more, but off the bat, I'd say that on the sender side, adding or removing tracks from the source MediaStream would have no effect on what is sent.  In other words, it's as if the source MediaStream were cloned when createLocalStream was called.  If you want to modify the LocalStream, you have to go through the .description.   On the receiver side, it would look like any other received MediaStream: if you remove the track, it just doesn't play out anymore.

     

     

    >
    >
    > interface LocalMediaStream implements MediaStream {
    >    // This can be changed at any time, but especially before calling
    >    // PeerConnection.addStream
    >    attribute MediaStreamDescription description;
    > }
    >
    >
    > // Represents the parameters used to either send or receive a stream
    > // over a PeerConnection.
    > dictionary MediaStreamDescription {
    >    MediaStreamTrackDescription[] tracks;
    > }
    >
    >
    > // Represents the parameters used to either send or receive a track over
    > // a PeerConnection.  A track has many "flows", which can be grouped
    > // together.
    > dictionary MediaStreamTrackDescription {
    >    // Same as the MediaStreamTrack.id
    >    DOMString id;
    >
    >    // Same as the MediaStreamTrack.kind
    >    DOMString kind;
    >
    >    // A track can have many "flows", such as for Simulcast, FEC, etc.
    >    // And they can be grouped in arbitrary ways.
    >    MediaFlowDescription[] flows;
    >    MediaFlowGroup[] flowGroups;
    > }
    >
    > // Represents the parameters used to either send or receive a "flow"
    > // over a PeerConnection.  A "flow" is a media that arrives with a
    > // single, unique SSRC.  One to many flows together make up the media
    > // for a track.  For example, there may be Simulcast, FEC, and RTX
    > // flows.
    > dictionay MediaFlowDescription {
    >    // The "flow id" must be unique to the track, but need not be unique
    >    // outside of the track (two tracks could both have a flow with the
    >    // same flow ID).
    >    DOMString id;
    >
    >    // Each flow can go over its own transport.  If the JS sets this to a
    >    // transportId that doesn't have a transport setup already, the
    >    // browser will use SDP negotiation to setup a transport to back that
    >    // transportId.  If This is set to an MID in the SDP, then that MID's
    >    // transport is used.
    >    DOMString transportId;

    Where from do you get transportId (e.g. if you want to re-use one)?

     

    First, the browser would fill it in via createLocalStream.  So in almost all cases, the JS would not need to set it.  In very advanced applications that want to do tricky things with transports, then the value should be the MID for that transport found in the SDP, as it says in the comment. 

     


    >
    >    // The SSRC used to send the flow.
    >    unsigned int ssrc;
    >
    >    // When used as receive parameters, this indicates the possible list
    >    // of codecs that might come in for this flow.  For exmample, a given
    >    // receive flow could be setup to receive any of OPUS, ISAC, or PCMU.
    >    // When used as send parameters, this indicates that the first codec
    >    // should be used, but the browser can use send other codecs if it
    >    // needs to because of either bandwidth or CPU constraints.
    >    MediaCodecDescription[] codecs;
    > }
    >
    >
    > dictionary MediaFlowGroup {
    >    DOMString type;  // "SIM" for Simulcast, "FEC" for FEC, etc
    >    DOMString[] flowids;
    > }
    >
    > dictionary MediaCodecDescription {
    >    unsigned byte payloadType;
    >    DOMString name;
    >    unsigned int? clockRate;
    >    unsigned int? bitRate;
    >    // A grab bag of other fmtp that will need to be further defined.
    >    MediaCodecParam[] params;
    > }
    >
    > dictionary MediaCodecParam {
    >    DOMString key;
    >    DOMString value;
    > }
    >
    >
    > Notes:
    >
    > - When LocalMediaStreams are added using addStream, onnegotiatedneeded
    > is not called, and those streams are never reflected in future SDP
    > exchanges.  Indeed, it would be impossible to put them in the SDP
    > without first resolving if that would be Plan A SDP or Plan B SDP.
    >
    > - Just like piles of attributes would need to be defined for Plan A and
    > for Plan B, similar attributes would need to be defined here (Luckily,
    >   much work has already been done figuring out what those parameters are :).
    >
    >
    > Pros:
    >
    > - Either Plan A or Plan B or could be implemented in Javascript using
    > this API
    > - It exposes all the same functionality to the Javascript as SDP, but in
    > a much nicer format that is much easier to work with.
    > - Any other signalling mechanism, such as Jingle or CLUE could be
    > implemented using this API.
    > - There is almost no risk of signalling glare.
    > - Debugging errors with misconfigured descriptions should be much easier
    > with this than with large SDP blobs.
    >
    >
    > Cons:
    >
    > - Now there are two slightly different ways to add streams: by creating
    > a LocalMediaStream first, and not.  This is, however, analogous to
    > setting "negotiated: true" in createDataChannel.  On way is "Just Work",
    > and the other is more advanced control.
    >
    > - All the options in MediaCodecDescription are a bit complicated.
    >   Really, this is only necessary because Plan A requires being able to
    > specify codec parameters per SSRC, and set each flow on different
    > transports.  If we did not have this requirement, we could simplify.
    >
    >
    > Example Usage:
    >
    > // Imagine I have MyApp, handles creating a PeerConnection,
    > // signalling, and rendering streams.  This is how the new API could be
    > // used.
    > var peerConnection = MyApp.createPeerConnection();
    >
    > // On sender side:
    > var stream = MyApp.getMediaStream();
    > var localStream = peerConnection.createSendStream(stream);
    > sendStream.description = MyApp.modifyStream(localStream.description)

    Should it say "localStream.description"?

     

    Yes. There was a last-minute rename and I missed a spot.  Anywhere you see "sendStream", it should be "localStream".

     


    > MyApp.signalAddStream(localStream.description, function(response)) {
    >    if (!response.rejected) {
    >      // Media will not be sent.
    >      peerConnection.addStream(localStream);
    >    }
    > }
    >
    > // On receiver side:
    > MyApp.onAddStreamSignalled = function(streamDescription) {
    >    var stream = peerConnection.createReceiveStream(streamDescription);
    >    MyApp.renderStream(stream);
    > }
    >
    >
    > // In this exchange, the MediaStreamDescription signalled from the
    > // sender to the receiver may have looked something like this:
    >
    > {
    >    tracks: [
    >    {
    >      id: "audio1",
    >      kind: "audio",
    >      flows: [
    >      {
    > id: "main",
    >        transportId: "transport1",
    >        ssrc: 1111,
    >        codecs: [
    >        {
    >          payloadType: 111,
    >          name: "opus",
    >          // ... more codec details
    >        },
    >        {
    >          payloadType: 112,
    >          name: "pcmu",
    > // ... more codec details
    >        }]
    >     }]
    >   },
    >   {
    >      id: "video1",
    >      kind: "video",
    >      flows: [
    >      {
    >        id: "sim0",
    >        transportId: "transport2",
    >        ssrc: 2222,
    >        codecs: [
    >        {
    >          payloadType: 122,
    >          name: "vp8"
    > // ... more codec details
    >        }]
    >     },
    >     {
    >       id: "sim1",
    >       transportId: "transport2",
    >       ssrc: 2223,
    >       codecs: [
    >       {
    >         payloadType: 122,
    >         name: "vp8",
    > // ... more codec details
    >       }]
    >     },
    >     {
    >       id: "sim2",
    >       transportId: "transport2",
    >       ssrc: 2224,
    >       codecs: [
    >       {
    >         payloadType: 122,
    >         name: "vp8",
    > // ... more codec details
    >       }]
    >     },
    >
    >     {
    >       id: "sim0fec",
    >       transportId: "transport2",
    >       ssrc: 2225,
    >       codecs: [
    >       {
    >         payloadType: 122,
    >         name: "vp8",
    >         // ...
    >       }]
    >     }],
    >     flowGroups: [
    >     {
    >       semantics: "SIM",
    >       ssrcs: [2222, 2223, 2224]
    >     },
    >     {
    >       semantics: "FEC",
    >       ssrcs: [2222, 2225]
    >     }]
    >   }]
    > }
    >
    >
    > Constructive feedback is welcome :).

     




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

    --------------020701000808000504050507-- From prvs=4881ea1215=stefan.lk.hakansson@ericsson.com Tue Jun 18 01:27:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D305521F9CA8 for ; Tue, 18 Jun 2013 01:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.124 X-Spam-Level: X-Spam-Status: No, score=-4.124 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAJ1xj6gK8IB for ; Tue, 18 Jun 2013 01:27:50 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id C748821F9CB7 for ; Tue, 18 Jun 2013 01:27:48 -0700 (PDT) X-AuditID: c1b4fb38-b7fa16d0000027dd-57-51c01a0375cc Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 39.ED.10205.30A10C15; Tue, 18 Jun 2013 10:27:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Tue, 18 Jun 2013 10:27:46 +0200 From: =?Windows-1252?Q?Stefan_H=E5kansson_LK?= To: Peter Thatcher Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) Thread-Index: AQHOa1pIfKQNX7+x70mEbzKV/FqHgg== Date: Tue, 18 Jun 2013 08:27:46 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2FC3F0@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C2FC071@ESESSMB209.ericsson.se> <57A15FAF9E58F841B2B1651FFE16D28104C918@GENSJZMBX01.msg.int.genesyslab.com> 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyM+JvrS6z1IFAg+6H4hZNV6exWFxb/prV Yu2/dnYHZo+lbzvYPBZsKvVYsuQnUwBzFLdNUmJJWXBmep6+XQJ3xrMJ85gLVvQwVrQvu8/Y wHg2uYuRk0NCwETi/snLTBC2mMSFe+vZQGwhgaOMEv1XbSDsRYwS//96dTFycLAJBEs0/XUD CYsIaEpMntzMCmIzC4RKzDy7hh2kRFggX2LCs3AQU0SgQOLQTkaIaj2J3iuzwWwWAVWJpW82 gy3lFfCVmDOjAWgKF9CiD0wSUz9NBLuAEeia76fWMEGMF5e49WQ+1JUCEkv2nGeGsEUlXj7+ xwphK0rsPNvODFFvIPH+3HwoW1ti2cLXzBDLBCVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZV jBzFqcVJuelGBpsYgdFxcMtvix2Ml//aHGKU5mBREuf9dGpXoJBAemJJanZqakFqUXxRaU5q 8SFGJg5OEMEl1cBY5SP/3U5dfqZK+aTEBbyvjA/xNfEs8DjVz+ndyVzbcPuB4YVVsY7bH/q4 /X6uc+P6KsG3IiIP5Nduvf3/z2vLb9lzFG/b8p/x3pldcWZL1JnlHy5zWIkyNu669V9oMcPU TekbLjlEXjy4z8HyIb/Ey3m1B1jOhUSuM/Z7zBevoDQj0ywh4wqHEktxRqKhFnNRcSIA1KM+ nmECAAA= Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:27:55 -0000 On 2013-06-17 18:21, Peter Thatcher wrote:=0A= >=0A= >=0A= >=0A= > On Mon, Jun 17, 2013 at 8:21 AM, Jim Barnett > wrote:=0A= >=0A= > What can you modify in a LocalMediaStream by editing its=0A= > description? Can you add a video track to it? That would imply=0A= > calling gUM, and you=92d have to thread it=92s success and failure= =0A= > callbacks up to the editing operation. Or is the track list fixed,= =0A= > so that you can only tweak transport info by editing the=0A= > LocalMediaStream=92s description?____=0A= >=0A= > __=0A= >=0A= >=0A= > If the JS calls gUM to get a second MediaStreamTrack (say, for=0A= > screencast), it could simply call createLocalStream again to add it, in= =0A= > a different LocalMediaStream, and the remote end would get a second=0A= > MediaStream by calling createRemoteStream. Why would you want more than= =0A= > one video MediaStreamTrack in MediaStream at the same time?=0A= =0A= I think there are use-cases for that, especially if keep the notion of =0A= that sync is maintained within a MediaStream but not across different MS's.= =0A= =0A= You could easily imagine that you have two cameras capturing the same =0A= speaker. You'd want lip sync when rendering at a remote peer regardless =0A= of which video that is played.=0A= =0A= >=0A= > In general, before you start sending or receiving, you can edit=0A= > everything side of the MediaStreamTrackDescription: change the ssrcs,=0A= > codecs, transport, video resolution to send with, what repair flows to=0A= > include, whether to use simulcast, etc. Basically, anything on a track= =0A= > level.=0A= >=0A= > But I don't really see a use case where you would need to add tracks to= =0A= > a MediaStreamTrackDescription,=0A= =0A= I agree - but that is obvious (a MediaStreamTrackDescription describes =0A= exactly one MediaStreamTrack). But there are use-cases for adding tracks = =0A= to a MediaStream description.=0A= =0A= > other than when parsing signalling and=0A= > building the MediaStreamTrackDescription to send down into=0A= > createRemoteStream. Perhaps if we had a use case, we could define such= =0A= > support. But otherwise, I'd say it's not allowed.=0A= >=0A= >=0A= > -__Jim____=0A= >=0A= > __ __=0A= >=0A= > *From:*rtcweb-bounces@ietf.org =0A= > [mailto:rtcweb-bounces@ietf.org ] *On=0A= > Behalf Of *Peter Thatcher=0A= > *Sent:* Monday, June 17, 2013 11:13 AM=0A= > *To:* Stefan H=E5kansson LK=0A= > *Cc:* >=0A= > *Subject:* Re: [rtcweb] Proposal for a JS API for NoPlan (adding=0A= > multiple sources without encoding them in SDP)____=0A= >=0A= > __ __=0A= >=0A= > Answers:____=0A= >=0A= > __ __=0A= >=0A= > On Mon, Jun 17, 2013 at 6:58 AM, Stefan H=E5kansson LK=0A= > > wrote:____=0A= >=0A= > A couple of questions (to help me understand) in-line //Stefan____=0A= >=0A= >=0A= > On 2013-06-17 14:57, Peter Thatcher wrote:=0A= > > Google is in full support of "Plan B" for encoding multiple media=0A= > > sources in SDP, and would like to see the Plan A vs. Plan B decision= =0A= > > resolved soon. Recently, though, a third option, called "NoPlan" has= =0A= > > been proposed, but it lacked the details of what a JS API would look= =0A= > > like for NoPlan. Cullen asked to see such an API proposal, and so I= =0A= > > have worked with Emil to make one. He will be adding it to the NoPlan= =0A= > > draft, but I will also include it in this email.=0A= > >=0A= > > Again, Google is in full support of "Plan B". But if Plan A vs. Plan = B=0A= > > cannot be decided, then we support NoPlan with the following additions= =0A= > > to the WebRTC JS API as an option that allows implementing either Plan= A=0A= > > or Plan B in Javascript. And even if Plan A vs. Plan B is resolved,= =0A= > > these API additions would still be a big improvement for those WebRTC= =0A= > > applications that don't use SDP for signalling.=0A= > >=0A= > > It is a bit long because I have added many comments and examples, but= =0A= > > the actually additions only include two new methods on PeerConnection= =0A= > > and a few new dictionaries. So don't be overwhelmed :).=0A= > >=0A= > >=0A= > >=0A= > > Intro: This follows the model of createDataChannel, which has a JS=0A= > > method on PeerConnection that makes it possible to add data channels= =0A= > > without going through SDP. Furthermore, just like createDataChannel= =0A= > > allows 2 ways to handle neogitation (the "I know what I'm doing; Here= 's=0A= > > what I want to send; Let me signal everything" mode and the "please ta= ke=0A= > > care of it for me; send an OPEN message" mode), this also has 2 ways = to=0A= > > handle negotiation (the "I know what I'm doing; Here's what I want to= =0A= > > send; Let me signal everything" mode and the "please take care of it f= or=0A= > > me; send SDP back and forth" mode).=0A= > >=0A= > > Following the success of createDataChannel, this allows simple=0A= > > applications to Just Work and more advanced applications to easily=0A= > > control what they need to. In particular, it's possible to use this A= PI=0A= > > to implement either Plan A or Plan B.=0A= > >=0A= > > // The following two method are added to RTCPeerConnection=0A= > > partial interface RTCPeerConnection {=0A= > > // Create a stream that is used to send a source stream.=0A= > > // The MediaSendStream.description can be used for signalling.=0A= > > // No media is sent until addStream(MediaSendStream) is called.=0A= > > LocalMediaStream createLocalStream(MediaStream sourceStream);=0A= > >=0A= > > // Create a stream that is used to receive media from the remote sid= e,=0A= > > // given the parameters signalled from MedaiSendStream.description.= =0A= > > MediaStream createRemoteStream(MediaStreamDescription description);= =0A= > > }____=0A= >=0A= > what would happen if the application adds or removes a track from=0A= > sourceStream (I'm thinking on how what would impact the created=0A= > LocalMediaStream and the MediaStream at the remote end)?____=0A= >=0A= > __ __=0A= >=0A= > __ __=0A= >=0A= > Good question. I'd have to think about it some more, but off the bat,=0A= > I'd say that on the sender side, adding or removing tracks from the=0A= > source MediaStream would have no effect on what is sent. In other=0A= > words, it's as if the source MediaStream were cloned when=0A= > createLocalStream was called. If you want to modify the LocalStream,=0A= > you have to go through the .description. On the receiver side, it=0A= > would look like any other received MediaStream: if you remove the track,= =0A= > it just doesn't play out anymore.____=0A= >=0A= > __ __=0A= >=0A= > ____=0A= >=0A= > >=0A= > >=0A= > > interface LocalMediaStream implements MediaStream {=0A= > > // This can be changed at any time, but especially before calli= ng=0A= > > // PeerConnection.addStream=0A= > > attribute MediaStreamDescription description;=0A= > > }=0A= > >=0A= > >=0A= > > // Represents the parameters used to either send or receive a stre= am=0A= > > // over a PeerConnection.=0A= > > dictionary MediaStreamDescription {=0A= > > MediaStreamTrackDescription[] tracks;=0A= > > }=0A= > >=0A= > >=0A= > > // Represents the parameters used to either send or receive a=0A= > track over=0A= > > // a PeerConnection. A track has many "flows", which can be group= ed=0A= > > // together.=0A= > > dictionary MediaStreamTrackDescription {=0A= > > // Same as the MediaStreamTrack.id=0A= > > DOMString id;=0A= > >=0A= > > // Same as the MediaStreamTrack.kind=0A= > > DOMString kind;=0A= > >=0A= > > // A track can have many "flows", such as for Simulcast, FEC, e= tc.=0A= > > // And they can be grouped in arbitrary ways.=0A= > > MediaFlowDescription[] flows;=0A= > > MediaFlowGroup[] flowGroups;=0A= > > }=0A= > >=0A= > > // Represents the parameters used to either send or receive a "flo= w"=0A= > > // over a PeerConnection. A "flow" is a media that arrives with a= =0A= > > // single, unique SSRC. One to many flows together make up the me= dia=0A= > > // for a track. For example, there may be Simulcast, FEC, and RTX= =0A= > > // flows.=0A= > > dictionay MediaFlowDescription {=0A= > > // The "flow id" must be unique to the track, but need not be= =0A= > unique=0A= > > // outside of the track (two tracks could both have a flow=0A= > with the=0A= > > // same flow ID).=0A= > > DOMString id;=0A= > >=0A= > > // Each flow can go over its own transport. If the JS sets=0A= > this to a=0A= > > // transportId that doesn't have a transport setup already, the= =0A= > > // browser will use SDP negotiation to setup a transport to=0A= > back that=0A= > > // transportId. If This is set to an MID in the SDP, then=0A= > that MID's=0A= > > // transport is used.=0A= > > DOMString transportId;____=0A= >=0A= > Where from do you get transportId (e.g. if you want to re-use one)?__= __=0A= >=0A= > __ __=0A= >=0A= > First, the browser would fill it in via createLocalStream. So in almost= =0A= > all cases, the JS would not need to set it. In very advanced=0A= > applications that want to do tricky things with transports, then the=0A= > value should be the MID for that transport found in the SDP, as it says= =0A= > in the comment. ____=0A= >=0A= > ____=0A= >=0A= >=0A= > >=0A= > > // The SSRC used to send the flow.=0A= > > unsigned int ssrc;=0A= > >=0A= > > // When used as receive parameters, this indicates the=0A= > possible list=0A= > > // of codecs that might come in for this flow. For exmample,= =0A= > a given=0A= > > // receive flow could be setup to receive any of OPUS, ISAC,=0A= > or PCMU.=0A= > > // When used as send parameters, this indicates that the first= =0A= > codec=0A= > > // should be used, but the browser can use send other codecs if= it=0A= > > // needs to because of either bandwidth or CPU constraints.=0A= > > MediaCodecDescription[] codecs;=0A= > > }=0A= > >=0A= > >=0A= > > dictionary MediaFlowGroup {=0A= > > DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc=0A= > > DOMString[] flowids;=0A= > > }=0A= > >=0A= > > dictionary MediaCodecDescription {=0A= > > unsigned byte payloadType;=0A= > > DOMString name;=0A= > > unsigned int? clockRate;=0A= > > unsigned int? bitRate;=0A= > > // A grab bag of other fmtp that will need to be further define= d.=0A= > > MediaCodecParam[] params;=0A= > > }=0A= > >=0A= > > dictionary MediaCodecParam {=0A= > > DOMString key;=0A= > > DOMString value;=0A= > > }=0A= > >=0A= > >=0A= > > Notes:=0A= > >=0A= > > - When LocalMediaStreams are added using addStream,=0A= > onnegotiatedneeded=0A= > > is not called, and those streams are never reflected in future SDP= =0A= > > exchanges. Indeed, it would be impossible to put them in the SDP= =0A= > > without first resolving if that would be Plan A SDP or Plan B SDP.= =0A= > >=0A= > > - Just like piles of attributes would need to be defined for Plan= =0A= > A and=0A= > > for Plan B, similar attributes would need to be defined here=0A= > (Luckily,=0A= > > much work has already been done figuring out what those=0A= > parameters are :).=0A= > >=0A= > >=0A= > > Pros:=0A= > >=0A= > > - Either Plan A or Plan B or could be implemented in Javascript us= ing=0A= > > this API=0A= > > - It exposes all the same functionality to the Javascript as SDP,= =0A= > but in=0A= > > a much nicer format that is much easier to work with.=0A= > > - Any other signalling mechanism, such as Jingle or CLUE could be= =0A= > > implemented using this API.=0A= > > - There is almost no risk of signalling glare.=0A= > > - Debugging errors with misconfigured descriptions should be much= =0A= > easier=0A= > > with this than with large SDP blobs.=0A= > >=0A= > >=0A= > > Cons:=0A= > >=0A= > > - Now there are two slightly different ways to add streams: by=0A= > creating=0A= > > a LocalMediaStream first, and not. This is, however, analogous to= =0A= > > setting "negotiated: true" in createDataChannel. On way is "Just= =0A= > Work",=0A= > > and the other is more advanced control.=0A= > >=0A= > > - All the options in MediaCodecDescription are a bit complicated.= =0A= > > Really, this is only necessary because Plan A requires being=0A= > able to=0A= > > specify codec parameters per SSRC, and set each flow on different= =0A= > > transports. If we did not have this requirement, we could simplif= y.=0A= > >=0A= > >=0A= > > Example Usage:=0A= > >=0A= > > // Imagine I have MyApp, handles creating a PeerConnection,=0A= > > // signalling, and rendering streams. This is how the new API=0A= > could be=0A= > > // used.=0A= > > var peerConnection =3D MyApp.createPeerConnection();=0A= > >=0A= > > // On sender side:=0A= > > var stream =3D MyApp.getMediaStream();=0A= > > var localStream =3D peerConnection.createSendStream(stream);=0A= > > sendStream.description =3D=0A= > MyApp.modifyStream(localStream.description)____=0A= >=0A= > Should it say "localStream.description"?____=0A= >=0A= > __ __=0A= >=0A= > Yes. There was a last-minute rename and I missed a spot. Anywhere you=0A= > see "sendStream", it should be "localStream".____=0A= >=0A= > ____=0A= >=0A= >=0A= > > MyApp.signalAddStream(localStream.description, function(response))= {=0A= > > if (!response.rejected) {=0A= > > // Media will not be sent.=0A= > > peerConnection.addStream(localStream);=0A= > > }=0A= > > }=0A= > >=0A= > > // On receiver side:=0A= > > MyApp.onAddStreamSignalled =3D function(streamDescription) {=0A= > > var stream =3D=0A= > peerConnection.createReceiveStream(streamDescription);=0A= > > MyApp.renderStream(stream);=0A= > > }=0A= > >=0A= > >=0A= > > // In this exchange, the MediaStreamDescription signalled from the= =0A= > > // sender to the receiver may have looked something like this:=0A= > >=0A= > > {=0A= > > tracks: [=0A= > > {=0A= > > id: "audio1",=0A= > > kind: "audio",=0A= > > flows: [=0A= > > {=0A= > > id: "main",=0A= > > transportId: "transport1",=0A= > > ssrc: 1111,=0A= > > codecs: [=0A= > > {=0A= > > payloadType: 111,=0A= > > name: "opus",=0A= > > // ... more codec details=0A= > > },=0A= > > {=0A= > > payloadType: 112,=0A= > > name: "pcmu",=0A= > > // ... more codec details=0A= > > }]=0A= > > }]=0A= > > },=0A= > > {=0A= > > id: "video1",=0A= > > kind: "video",=0A= > > flows: [=0A= > > {=0A= > > id: "sim0",=0A= > > transportId: "transport2",=0A= > > ssrc: 2222,=0A= > > codecs: [=0A= > > {=0A= > > payloadType: 122,=0A= > > name: "vp8"=0A= > > // ... more codec details=0A= > > }]=0A= > > },=0A= > > {=0A= > > id: "sim1",=0A= > > transportId: "transport2",=0A= > > ssrc: 2223,=0A= > > codecs: [=0A= > > {=0A= > > payloadType: 122,=0A= > > name: "vp8",=0A= > > // ... more codec details=0A= > > }]=0A= > > },=0A= > > {=0A= > > id: "sim2",=0A= > > transportId: "transport2",=0A= > > ssrc: 2224,=0A= > > codecs: [=0A= > > {=0A= > > payloadType: 122,=0A= > > name: "vp8",=0A= > > // ... more codec details=0A= > > }]=0A= > > },=0A= > >=0A= > > {=0A= > > id: "sim0fec",=0A= > > transportId: "transport2",=0A= > > ssrc: 2225,=0A= > > codecs: [=0A= > > {=0A= > > payloadType: 122,=0A= > > name: "vp8",=0A= > > // ...=0A= > > }]=0A= > > }],=0A= > > flowGroups: [=0A= > > {=0A= > > semantics: "SIM",=0A= > > ssrcs: [2222, 2223, 2224]=0A= > > },=0A= > > {=0A= > > semantics: "FEC",=0A= > > ssrcs: [2222, 2225]=0A= > > }]=0A= > > }]=0A= > > }=0A= > >=0A= > >=0A= > > Constructive feedback is welcome :).____=0A= >=0A= > __ __=0A= >=0A= >=0A= =0A= From ibc@aliax.net Tue Jun 18 01:31:23 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20F321F9992 for ; Tue, 18 Jun 2013 01:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRZYXXSWVWah for ; Tue, 18 Jun 2013 01:31:22 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 66E1621F8F5C for ; Tue, 18 Jun 2013 01:31:22 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so2013117qae.20 for ; Tue, 18 Jun 2013 01:31:21 -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=CR1LSk65tYF7soiLGpc+oL2MiDfqEQSDo9Bn8zmhgcc=; b=PjX2FpHOOyf/3+Q8EF1sm1zIlfxOoETvfeSYZ1JhsCCZLB40z9fBNbNY/vQDUD2FV+ oC8+QymjtWH0LM0SdBJwhktcCfXg7oOllvqZ92/2AL+QzVESkNu84/MRHAtyped94Su5 0S57LnJpeGUM5pLgQ6b9BVxjdTB1XaQbqXKHE5txdOoT3DDtxLzofjp7wdcSwc39SXe/ kZy2QW7cBWWpuSip12EoyTK+5Z8fuz7HamNeuv96T6FytkWMRvsqIlxyMgzAuZNXTUAA hfM/9PfY4IWVevnY/EW35SV6Xb7K93jfe0qyQl2V14FCZX+fxVTigUu44Ml0roFoyNM7 o/FA== X-Received: by 10.229.149.198 with SMTP id u6mr8288698qcv.20.1371544281830; Tue, 18 Jun 2013 01:31:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Tue, 18 Jun 2013 01:31:00 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 18 Jun 2013 10:31:00 +0200 Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkMM8dDoXlPz5s24D/8XY+ADE+mtGZIgnh7L2uiJUnIJbZkADH/sagoKbAVR1QAY1l1lL5X Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:31:23 -0000 2013/6/18 Peter Thatcher : > That means the > SDP is really just used as a way to tell the browser what ice ufrag, ice > pwd, and DTLS fingerprint to use. And do we really need SDP for that? mandatory? > It would look something like this > (forgive me if I got the SDP slightly wrong; it's easy to get wrong): > > v=3D0 Unneeded line v. > o=3D- 697639972863421376 2 IN IP4 127.0.0.1 Unneeded line o. > s=3D- > t=3D0 0 Unneeded lines s and t. > m=3Dapplication 1 DTLS/SCTP 5000 Why is this required at all? > c=3DIN IP4 0.0.0.0 Anti-useful c line. > a=3Dmid:transport What else can it be? > a=3Dice-ufrag:tEP42he9r6LycvmM > a=3Dice-pwd:cKJLuvHy9pas9rdezUZB9xet > a=3Dfingerprint:sha-256 > EC:E0:95:43:B7:01:49:8B:BC:21:CC:41:7F:10:FD:92:28:B8:F8:41:07:70:77:7D:7= C:47:92:30:79:C4:95:9C Finally we get 3 useful fields (related to ICE and encryption). And are we going to mandate SDP O/A for this? really? I really hope NOT. > Ignoring ICE candidates and restarts, that's all the SDP what would be > needed for the whole PeerConnection (one for the local and one for the > remote). And WHY do we need to *mandate* SDP for that? Why don't we define a IceData object, something that can be serialized in JSON to be sent to the remote peer in any custom way? Why should we deal with blob strings in an old-school format? > 10 lines of SDP just to setup a transport isn't quite such an abomination= , > is it? Yes, because we don't need those 10 lines, but just 3 string values. > You're not forced to do SDP, except for the transports. For defining the > streams, you can avoid SDP altogether. As a WebRTC JS app developer, I k= now > I would find working with this API much better than working with SDP > munging. And what is the advantage of mandating usage of SDP for the transport (over letting the user communicate it to the browser via API by passing some JS object?). Regards. -- I=C3=B1aki Baz Castillo From harald@alvestrand.no Tue Jun 18 01:39:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E39F21F9D92 for ; Tue, 18 Jun 2013 01:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.998 X-Spam-Level: X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKuvzpRdc5sO for ; Tue, 18 Jun 2013 01:38:57 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CA89621F9D28 for ; Tue, 18 Jun 2013 01:38:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F12139E0FA for ; Tue, 18 Jun 2013 10:38:54 +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 zA53pQia5zKz for ; Tue, 18 Jun 2013 10:38:49 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0A4DF39E04C for ; Tue, 18 Jun 2013 10:38:48 +0200 (CEST) Message-ID: <51C01C98.8020608@alvestrand.no> Date: Tue, 18 Jun 2013 10:38:48 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <57A15FAF9E58F841B2B1651FFE16D28104FB3E@GENSJZMBX01.msg.int.genesyslab.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030308010002020009000305" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:39:02 -0000 This is a multi-part message in MIME format. --------------030308010002020009000305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/18/2013 07:44 AM, Peter Thatcher wrote: > I need to write a more complete example, but it basically would be: > > var signalling = new AppSpecificSignalling(); > var stream = getUserMedia(...); // For the example, imagine it's > synchronous. > var pc = new PeerConnection(...); > var dc = pc.createDataChannel(...); > pc.createOffer(function(offer) { > pc.setLocalDescription(offer); > signalling.swapTransportParams(offer.sdp, function(answerSdp) { > pc.setRemoteDescription(new SessionDescription(answerSdp); > }); > }); > var localStream = pc.createLocalStream(stream); > signalling.addStream(localStream.description); > signalling.onStreamAdded = function(remoteStreamDescription) { > var remoteStream = pc.createRemoteStream(stream); > // Render the remoteStream. > }); > > And in all of this, the only SDP involved would be to setup the > transport the data channel, which would then be used to BUNDLE audio > and video over the same (with rtcp-mux, naturally). Something like this: > > v=0 o=- 697639972863421376 2 IN IP4 127.0.0.1 > s=- > t=0 0 > m=application 1 DTLS/SCTP 5000 > c=IN IP4 0.0.0.0 > a=mid:transport > > a=ice-ufrag:tEP42he9r6LycvmM > a=ice-pwd:cKJLuvHy9pas9rdezUZB9xet > a=fingerprint:sha-256 > EC:E0:95:43:B7:01:49:8B:BC:21:CC:41:7F:10:FD:92:28:B8:F8:41:07:70:77:7D:7C:47:92:30:79:C4:95:9C > > > > 10 lines of SDP (per side) is, relatively speaking, very small, and it > really only contains three values: ice-ufrag/ice-pwd, and dtsl > fingerprint. > > I may be missing something, but I think this would work. If anyone > knows a reason why it wouldn't, I'm sure you'll let me know :). At the risk of adding some more complexity: if both sides add the offerToReceiveVideo=true constraint, the SDP will also include M-lines for audio and video, indicating supported codecs, which allows the initial offer/answer to supply information that allows the UA to check that the parameters to the addLocalStream / addRemoteStream calls actually make sense in context, that payload type numbers actually mean what they're supposed to mean, and so on. You know, what SDP was originally designed for.... > > > > On Mon, Jun 17, 2013 at 1:07 PM, Jim Barnett > > wrote: > > Peter, > > You say that only initial PeerConnection set up requires offer > answer. Where is that in your example? In the example, all we > see on the receiving side is that it calls createReceiveStream. > > -Jim > > *From:*rtcweb-bounces@ietf.org > [mailto:rtcweb-bounces@ietf.org ] > *On Behalf Of *Peter Thatcher > *Sent:* Monday, June 17, 2013 3:26 PM > *To:* Martin Thomson > > > *Cc:* > > *Subject:* Re: [rtcweb] Proposal for a JS API for NoPlan (adding > multiple sources without encoding them in SDP) > > Yes, I was expecting you to be more supportive. I'm surprised out > how your want "all or nothing". I'm afraid if our options for a > clean API are all or nothing, we'll just end up with nothing. I'd > prefer to try incremental improvements to word toward (eventually) > a clean API. > > Do you think it is impossible to work toward a clean API in an > incremental approach? If you think it's possible, I'd like to > hear your thoughts on how. > > By the way, these API additions would greatly minimize the amount > of SDP editing necessary for JS clients that don't use SDP for > signalling. And later incremental improvements could reduce it > further. Also, it's no longer necessary to do offer/answer for > adding tracks. It's only the intial PeerConnection setup that > needs to do Offer/Answer. So, it doesn't inherit all the problems > quite as much as you described. It may be slightly abominable, > but I certainly consider it less abominable than the SDP editing > necessary without it. > > On Mon, Jun 17, 2013 at 11:57 AM, Martin Thomson > > wrote: > > Maybe you'd expect me to be more supportive of something that looked > so much like CU-RTC-Web. It inherits all the worst properties of JSEP > (Offer/Answer, SDP editing) with a partial implementation of a clean > API. > > It's comment 22-lite. It's an abomination. If you are going to do > this, do it properly. > > > On 17 June 2013 05:57, Peter Thatcher > wrote: > > Google is in full support of "Plan B" for encoding multiple > media sources in > > SDP, and would like to see the Plan A vs. Plan B decision > resolved soon. > > Recently, though, a third option, called "NoPlan" has been > proposed, but it > > lacked the details of what a JS API would look like for NoPlan. > Cullen > > asked to see such an API proposal, and so I have worked with > Emil to make > > one. He will be adding it to the NoPlan draft, but I will also > include it > > in this email. > > > > Again, Google is in full support of "Plan B". But if Plan A vs. > Plan B > > cannot be decided, then we support NoPlan with the following > additions to > > the WebRTC JS API as an option that allows implementing either > Plan A or > > Plan B in Javascript. And even if Plan A vs. Plan B is > resolved, these API > > additions would still be a big improvement for those WebRTC > applications > > that don't use SDP for signalling. > > > > It is a bit long because I have added many comments and > examples, but the > > actually additions only include two new methods on > PeerConnection and a few > > new dictionaries. So don't be overwhelmed :). > > > > > > > > Intro: This follows the model of createDataChannel, which has a > JS method on > > PeerConnection that makes it possible to add data channels > without going > > through SDP. Furthermore, just like createDataChannel allows 2 > ways to > > handle neogitation (the "I know what I'm doing; Here's what I > want to send; > > Let me signal everything" mode and the "please take care of it > for me; send > > an OPEN message" mode), this also has 2 ways to handle > negotiation (the "I > > know what I'm doing; Here's what I want to send; Let me signal > everything" > > mode and the "please take care of it for me; send SDP back and > forth" > > mode). > > > > Following the success of createDataChannel, this allows simple > applications > > to Just Work and more advanced applications to easily control > what they need > > to. In particular, it's possible to use this API to implement > either Plan A > > or Plan B. > > > > // The following two method are added to RTCPeerConnection > > partial interface RTCPeerConnection { > > // Create a stream that is used to send a source stream. > > // The MediaSendStream.description can be used for signalling. > > // No media is sent until addStream(MediaSendStream) is called. > > LocalMediaStream createLocalStream(MediaStream sourceStream); > > > > // Create a stream that is used to receive media from the > remote side, > > // given the parameters signalled from MedaiSendStream.description. > > MediaStream createRemoteStream(MediaStreamDescription description); > > } > > > > > > interface LocalMediaStream implements MediaStream { > > // This can be changed at any time, but especially before calling > > // PeerConnection.addStream > > attribute MediaStreamDescription description; > > } > > > > > > // Represents the parameters used to either send or receive a stream > > // over a PeerConnection. > > dictionary MediaStreamDescription { > > MediaStreamTrackDescription[] tracks; > > } > > > > > > // Represents the parameters used to either send or receive a > track over // > > a PeerConnection. A track has many "flows", which can be grouped > > // together. > > dictionary MediaStreamTrackDescription { > > // Same as the MediaStreamTrack.id > > DOMString id; > > > > // Same as the MediaStreamTrack.kind > > DOMString kind; > > > > // A track can have many "flows", such as for Simulcast, FEC, etc. > > // And they can be grouped in arbitrary ways. > > MediaFlowDescription[] flows; > > MediaFlowGroup[] flowGroups; > > } > > > > // Represents the parameters used to either send or receive a "flow" > > // over a PeerConnection. A "flow" is a media that arrives with a > > // single, unique SSRC. One to many flows together make up the > media > > // for a track. For example, there may be Simulcast, FEC, and RTX > > // flows. > > dictionay MediaFlowDescription { > > // The "flow id" must be unique to the track, but need not be > unique > > // outside of the track (two tracks could both have a flow > with the > > // same flow ID). > > DOMString id; > > > > // Each flow can go over its own transport. If the JS sets > this to a > > // transportId that doesn't have a transport setup already, the > > // browser will use SDP negotiation to setup a transport to > back that > > // transportId. If This is set to an MID in the SDP, then > that MID's > > // transport is used. > > DOMString transportId; > > > > // The SSRC used to send the flow. > > unsigned int ssrc; > > > > // When used as receive parameters, this indicates the > possible list > > // of codecs that might come in for this flow. For exmample, > a given > > // receive flow could be setup to receive any of OPUS, ISAC, > or PCMU. > > // When used as send parameters, this indicates that the first > codec > > // should be used, but the browser can use send other codecs if it > > // needs to because of either bandwidth or CPU constraints. > > MediaCodecDescription[] codecs; > > } > > > > > > dictionary MediaFlowGroup { > > DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc > > DOMString[] flowids; > > } > > > > dictionary MediaCodecDescription { > > unsigned byte payloadType; > > DOMString name; > > unsigned int? clockRate; > > unsigned int? bitRate; > > // A grab bag of other fmtp that will need to be further defined. > > MediaCodecParam[] params; > > } > > > > dictionary MediaCodecParam { > > DOMString key; > > DOMString value; > > } > > > > > > Notes: > > > > - When LocalMediaStreams are added using addStream, > onnegotiatedneeded is > > not called, and those streams are never reflected in future SDP > exchanges. > > Indeed, it would be impossible to put them in the SDP without first > > resolving if that would be Plan A SDP or Plan B SDP. > > > > - Just like piles of attributes would need to be defined for > Plan A and for > > Plan B, similar attributes would need to be defined here > (Luckily, much > > work has already been done figuring out what those parameters > are :). > > > > > > Pros: > > > > - Either Plan A or Plan B or could be implemented in Javascript > using this > > API > > - It exposes all the same functionality to the Javascript as > SDP, but in a > > much nicer format that is much easier to work with. > > - Any other signalling mechanism, such as Jingle or CLUE could be > > implemented using this API. > > - There is almost no risk of signalling glare. > > - Debugging errors with misconfigured descriptions should be > much easier > > with this than with large SDP blobs. > > > > > > Cons: > > > > - Now there are two slightly different ways to add streams: by > creating a > > LocalMediaStream first, and not. This is, however, analogous to > setting > > "negotiated: true" in createDataChannel. On way is "Just Work", > and the > > other is more advanced control. > > > > - All the options in MediaCodecDescription are a bit > complicated. Really, > > this is only necessary because Plan A requires being able to > specify codec > > parameters per SSRC, and set each flow on different transports. > If we did > > not have this requirement, we could simplify. > > > > > > Example Usage: > > > > // Imagine I have MyApp, handles creating a PeerConnection, > > // signalling, and rendering streams. This is how the new API > could be > > // used. > > var peerConnection = MyApp.createPeerConnection(); > > > > // On sender side: > > var stream = MyApp.getMediaStream(); > > var localStream = peerConnection.createSendStream(stream); > > sendStream.description = MyApp.modifyStream(localStream.description) > > MyApp.signalAddStream(localStream.description, function(response)) { > > if (!response.rejected) { > > // Media will not be sent. > > peerConnection.addStream(localStream); > > } > > } > > > > // On receiver side: > > MyApp.onAddStreamSignalled = function(streamDescription) { > > var stream = > peerConnection.createReceiveStream(streamDescription); > > MyApp.renderStream(stream); > > } > > > > > > // In this exchange, the MediaStreamDescription signalled from the > > // sender to the receiver may have looked something like this: > > > > { > > tracks: [ > > { > > id: "audio1", > > kind: "audio", > > flows: [ > > { > > id: "main", > > transportId: "transport1", > > ssrc: 1111, > > codecs: [ > > { > > payloadType: 111, > > name: "opus", > > // ... more codec details > > }, > > { > > payloadType: 112, > > name: "pcmu", > > // ... more codec details > > }] > > }] > > }, > > { > > id: "video1", > > kind: "video", > > flows: [ > > { > > id: "sim0", > > transportId: "transport2", > > ssrc: 2222, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8" > > // ... more codec details > > }] > > }, > > { > > id: "sim1", > > transportId: "transport2", > > ssrc: 2223, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... more codec details > > }] > > }, > > { > > id: "sim2", > > transportId: "transport2", > > ssrc: 2224, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... more codec details > > }] > > }, > > > > { > > id: "sim0fec", > > transportId: "transport2", > > ssrc: 2225, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... > > }] > > }], > > flowGroups: [ > > { > > semantics: "SIM", > > ssrcs: [2222, 2223, 2224] > > }, > > { > > semantics: "FEC", > > ssrcs: [2222, 2225] > > }] > > }] > > } > > > > > > Constructive feedback is welcome :). > > > > > _______________________________________________ > > 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 --------------030308010002020009000305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    On 06/18/2013 07:44 AM, Peter Thatcher wrote:
    I need to write a more complete example, but it basically would be:

    var signalling = new AppSpecificSignalling();
    var stream = getUserMedia(...);  // For the example, imagine it's synchronous.
    var pc = new PeerConnection(...);
    var dc = pc.createDataChannel(...);
    pc.createOffer(function(offer) {
      pc.setLocalDescription(offer);
      signalling.swapTransportParams(offer.sdp, function(answerSdp) {
        pc.setRemoteDescription(new SessionDescription(answerSdp);
      });
    });
    var localStream = pc.createLocalStream(stream);
    signalling.addStream(localStream.description);
    signalling.onStreamAdded = function(remoteStreamDescription) {
      var remoteStream = pc.createRemoteStream(stream);
      // Render the remoteStream.
    });

    And in all of this, the only SDP involved would be to setup the transport the data channel, which would then be used to BUNDLE audio and video over the same (with rtcp-mux, naturally).  Something like this:

    v=0 o=- 697639972863421376 2 IN IP4 127.0.0.1
    s=-
    t=0 0
    m=application 1 DTLS/SCTP 5000
    c=IN IP4 0.0.0.0
    a=mid:transport

    a=ice-ufrag:tEP42he9r6LycvmM
    a=ice-pwd:cKJLuvHy9pas9rdezUZB9xet
    a=fingerprint:sha-256 EC:E0:95:43:B7:01:49:8B:BC:21:CC:41:7F:10:FD:92:28:B8:F8:41:07:70:77:7D:7C:47:92:30:79:C4:95:9C



    10 lines of SDP (per side) is, relatively speaking, very small, and it really only contains three values: ice-ufrag/ice-pwd, and dtsl fingerprint.  

    I may be missing something, but I think this would work.  If anyone knows a reason why it wouldn't, I'm sure you'll let me know :).

    At the risk of adding some more complexity:

    if both sides add the offerToReceiveVideo=true constraint, the SDP will also include M-lines for audio and video, indicating supported codecs, which allows the initial offer/answer to supply information that allows the UA to check that the parameters to the addLocalStream / addRemoteStream calls actually make sense in context, that payload type numbers actually mean what they're supposed to mean, and so on.

    You know, what SDP was originally designed for....




    On Mon, Jun 17, 2013 at 1:07 PM, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:

    Peter,

    You say that only initial PeerConnection set up requires offer answer.   Where is that in your example?  In the example, all we see on the receiving side is that it calls createReceiveStream.

     

    -          Jim

     

    From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Peter Thatcher
    Sent: Monday, June 17, 2013 3:26 PM
    To: Martin Thomson


    Cc: <rtcweb@ietf.org>
    Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

     

    Yes, I was expecting you to be more supportive.  I'm surprised out how your want "all or nothing".  I'm afraid if our options for a clean API are all or nothing, we'll just end up with nothing.  I'd prefer to try incremental improvements to word toward (eventually) a clean API. 

     

    Do you think it is impossible to work toward a clean API in an incremental approach?  If you think it's possible, I'd like to hear your thoughts on how. 

     

     

    By the way, these API additions would greatly minimize the amount of SDP editing necessary for JS clients that don't use SDP for signalling.  And later incremental improvements could reduce it further.  Also, it's no longer necessary to do offer/answer for adding tracks.  It's only the intial PeerConnection setup that needs to do Offer/Answer.  So, it doesn't inherit all the problems quite as much as you described.  It may be slightly abominable, but I certainly consider it less abominable than the SDP editing necessary without it.

     

    On Mon, Jun 17, 2013 at 11:57 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

    Maybe you'd expect me to be more supportive of something that looked
    so much like CU-RTC-Web.  It inherits all the worst properties of JSEP
    (Offer/Answer, SDP editing) with a partial implementation of a clean
    API.

    It's comment 22-lite.  It's an abomination.  If you are going to do
    this, do it properly.


    On 17 June 2013 05:57, Peter Thatcher <pthatcher@google.com> wrote:
    > Google is in full support of "Plan B" for encoding multiple media sources in
    > SDP, and would like to see the Plan A vs. Plan B decision resolved soon.
    > Recently, though, a third option, called "NoPlan" has been proposed, but it
    > lacked the details of what a JS API would look like for NoPlan.  Cullen
    > asked to see such an API proposal, and so I have worked with Emil to make
    > one.  He will be adding it to the NoPlan draft, but I will also include it
    > in this email.
    >
    > Again, Google is in full support of "Plan B".  But if Plan A vs. Plan B
    > cannot be decided, then we support NoPlan with the following additions to
    > the WebRTC JS API as an option that allows implementing either Plan A or
    > Plan B  in Javascript.  And even if Plan A vs. Plan B is resolved, these API
    > additions would still be a big improvement for those WebRTC applications
    > that don't use SDP for signalling.
    >
    > It is a bit long because I have added many comments and examples, but the
    > actually additions only include two new methods on PeerConnection and a few
    > new dictionaries.  So don't be overwhelmed :).
    >
    >
    >
    > Intro: This follows the model of createDataChannel, which has a JS method on
    > PeerConnection that makes it possible to add data channels without going
    > through SDP.  Furthermore, just like createDataChannel allows 2 ways to
    > handle neogitation (the "I know what I'm doing;  Here's what I want to send;
    > Let me signal everything" mode and the "please take care of it for me;  send
    > an OPEN message" mode), this also has 2 ways to handle negotiation (the "I
    > know what I'm doing; Here's what I want to send; Let me signal everything"
    > mode and the "please take care of it for me;  send SDP back and forth"
    > mode).
    >
    > Following the success of createDataChannel, this allows simple applications
    > to Just Work and more advanced applications to easily control what they need
    > to.  In particular, it's possible to use this API to implement either Plan A
    > or Plan B.
    >
    > // The following two method are added to RTCPeerConnection
    > partial interface RTCPeerConnection {
    >  // Create a stream that is used to send a source stream.
    >  // The MediaSendStream.description can be used for signalling.
    >  // No media is sent until addStream(MediaSendStream) is called.
    >  LocalMediaStream createLocalStream(MediaStream sourceStream);
    >
    >  // Create a stream that is used to receive media from the remote side,
    >  // given the parameters signalled from MedaiSendStream.description.
    >  MediaStream createRemoteStream(MediaStreamDescription description);
    > }
    >
    >
    > interface LocalMediaStream implements MediaStream {
    >   // This can be changed at any time, but especially before calling
    >   // PeerConnection.addStream
    >   attribute MediaStreamDescription description;
    > }
    >
    >
    > // Represents the parameters used to either send or receive a stream
    > // over a PeerConnection.
    > dictionary MediaStreamDescription {
    >   MediaStreamTrackDescription[] tracks;
    > }
    >
    >
    > // Represents the parameters used to either send or receive a track over //
    > a PeerConnection.  A track has many "flows", which can be grouped
    > // together.
    > dictionary MediaStreamTrackDescription {
    >   // Same as the MediaStreamTrack.id
    >   DOMString id;
    >
    >   // Same as the MediaStreamTrack.kind
    >   DOMString kind;
    >
    >   // A track can have many "flows", such as for Simulcast, FEC, etc.
    >   // And they can be grouped in arbitrary ways.
    >   MediaFlowDescription[] flows;
    >   MediaFlowGroup[] flowGroups;
    > }
    >
    > // Represents the parameters used to either send or receive a "flow"
    > // over a PeerConnection.  A "flow" is a media that arrives with a
    > // single, unique SSRC.  One to many flows together make up the media
    > // for a track.  For example, there may be Simulcast, FEC, and RTX
    > // flows.
    > dictionay MediaFlowDescription {
    >   // The "flow id" must be unique to the track, but need not be unique
    >   // outside of the track (two tracks could both have a flow with the
    >   // same flow ID).
    >   DOMString id;
    >
    >   // Each flow can go over its own transport.  If the JS sets this to a
    >   // transportId that doesn't have a transport setup already, the
    >   // browser will use SDP negotiation to setup a transport to back that
    >   // transportId.  If This is set to an MID in the SDP, then that MID's
    >   // transport is used.
    >   DOMString transportId;
    >
    >   // The SSRC used to send the flow.
    >   unsigned int ssrc;
    >
    >   // When used as receive parameters, this indicates the possible list
    >   // of codecs that might come in for this flow.  For exmample, a given
    >   // receive flow could be setup to receive any of OPUS, ISAC, or PCMU.
    >   // When used as send parameters, this indicates that the first codec
    >   // should be used, but the browser can use send other codecs if it
    >   // needs to because of either bandwidth or CPU constraints.
    >   MediaCodecDescription[] codecs;
    > }
    >
    >
    > dictionary MediaFlowGroup {
    >   DOMString type;  // "SIM" for Simulcast, "FEC" for FEC, etc
    >   DOMString[] flowids;
    > }
    >
    > dictionary MediaCodecDescription {
    >   unsigned byte payloadType;
    >   DOMString name;
    >   unsigned int? clockRate;
    >   unsigned int? bitRate;
    >   // A grab bag of other fmtp that will need to be further defined.
    >   MediaCodecParam[] params;
    > }
    >
    > dictionary MediaCodecParam {
    >   DOMString key;
    >   DOMString value;
    > }
    >
    >
    > Notes:
    >
    > - When LocalMediaStreams are added using addStream, onnegotiatedneeded is
    > not called, and those streams are never reflected in future SDP exchanges.
    > Indeed, it would be impossible to put them in the SDP without first
    > resolving if that would be Plan A SDP or Plan B SDP.
    >
    > - Just like piles of attributes would need to be defined for Plan A and for
    > Plan B, similar attributes would need to be defined here (Luckily,  much
    > work has already been done figuring out what those parameters are :).
    >
    >
    > Pros:
    >
    > - Either Plan A or Plan B or could be implemented in Javascript using this
    > API
    > - It exposes all the same functionality to the Javascript as SDP, but in a
    > much nicer format that is much easier to work with.
    > - Any other signalling mechanism, such as Jingle or CLUE could be
    > implemented using this API.
    > - There is almost no risk of signalling glare.
    > - Debugging errors with misconfigured descriptions should be much easier
    > with this than with large SDP blobs.
    >
    >
    > Cons:
    >
    > - Now there are two slightly different ways to add streams: by creating a
    > LocalMediaStream first, and not.  This is, however, analogous to setting
    > "negotiated: true" in createDataChannel.  On way is "Just Work", and the
    > other is more advanced control.
    >
    > - All the options in MediaCodecDescription are a bit complicated.  Really,
    > this is only necessary because Plan A requires being able to specify codec
    > parameters per SSRC, and set each flow on different transports.  If we did
    > not have this requirement, we could simplify.
    >
    >
    > Example Usage:
    >
    > // Imagine I have MyApp, handles creating a PeerConnection,
    > // signalling, and rendering streams.  This is how the new API could be
    > // used.
    > var peerConnection = MyApp.createPeerConnection();
    >
    > // On sender side:
    > var stream = MyApp.getMediaStream();
    > var localStream = peerConnection.createSendStream(stream);
    > sendStream.description = MyApp.modifyStream(localStream.description)
    > MyApp.signalAddStream(localStream.description, function(response)) {
    >   if (!response.rejected) {
    >     // Media will not be sent.
    >     peerConnection.addStream(localStream);
    >   }
    > }
    >
    > // On receiver side:
    > MyApp.onAddStreamSignalled = function(streamDescription) {
    >   var stream = peerConnection.createReceiveStream(streamDescription);
    >   MyApp.renderStream(stream);
    > }
    >
    >
    > // In this exchange, the MediaStreamDescription signalled from the
    > // sender to the receiver may have looked something like this:
    >
    > {
    >   tracks: [
    >   {
    >     id: "audio1",
    >     kind: "audio",
    >     flows: [
    >     {
    >       id: "main",
    >       transportId: "transport1",
    >       ssrc: 1111,
    >       codecs: [
    >       {
    >         payloadType: 111,
    >         name: "opus",
    >         // ... more codec details
    >       },
    >       {
    >         payloadType: 112,
    >         name: "pcmu",
    >         // ... more codec details
    >       }]
    >    }]
    >  },
    >  {
    >     id: "video1",
    >     kind: "video",
    >     flows: [
    >     {
    >       id: "sim0",
    >       transportId: "transport2",
    >       ssrc: 2222,
    >       codecs: [
    >       {
    >         payloadType: 122,
    >         name: "vp8"
    >         // ... more codec details
    >       }]
    >    },
    >    {
    >      id: "sim1",
    >      transportId: "transport2",
    >      ssrc: 2223,
    >      codecs: [
    >      {
    >        payloadType: 122,
    >        name: "vp8",
    >        // ... more codec details
    >      }]
    >    },
    >    {
    >      id: "sim2",
    >      transportId: "transport2",
    >      ssrc: 2224,
    >      codecs: [
    >      {
    >        payloadType: 122,
    >        name: "vp8",
    >        // ... more codec details
    >      }]
    >    },
    >
    >    {
    >      id: "sim0fec",
    >      transportId: "transport2",
    >      ssrc: 2225,
    >      codecs: [
    >      {
    >        payloadType: 122,
    >        name: "vp8",
    >        // ...
    >      }]
    >    }],
    >    flowGroups: [
    >    {
    >      semantics: "SIM",
    >      ssrcs: [2222, 2223, 2224]
    >    },
    >    {
    >      semantics: "FEC",
    >      ssrcs: [2222, 2225]
    >    }]
    >  }]
    > }
    >
    >
    > Constructive feedback is welcome :).
    >

    > _______________________________________________
    > 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

    --------------030308010002020009000305-- From enrico.marocco@telecomitalia.it Tue Jun 18 02:21:41 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771E021F9C8C for ; Tue, 18 Jun 2013 02:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.719 X-Spam-Level: X-Spam-Status: No, score=-101.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCK-rYXVZyDg for ; Tue, 18 Jun 2013 02:21:36 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id CEA8B21F944C for ; Tue, 18 Jun 2013 02:21:35 -0700 (PDT) Received: from grfhub703rm001.griffon.local (10.19.3.10) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 18 Jun 2013 11:21:33 +0200 Received: from MacLab.local (10.229.8.22) by smtp.telecomitalia.it (10.19.9.236) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 18 Jun 2013 11:21:33 +0200 Message-ID: <51C0269B.5070200@telecomitalia.it> Date: Tue, 18 Jun 2013 11:21:31 +0200 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010309000107080601050603" X-TI-Disclaimer: Disclaimer1 Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 09:21:41 -0000 --------------ms010309000107080601050603 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/18/13 10:31 AM, I=C3=B1aki Baz Castillo wrote: >> That means the >> SDP is really just used as a way to tell the browser what ice ufrag, i= ce >> pwd, and DTLS fingerprint to use. >=20 > And do we really need SDP for that? mandatory? I won't comment on whether SDP was the best option to begin with, but the fact that every other person on this list has a demo WebRTC app that, with little to no manipulation, achieves some kind of *basic* interoperability with legacy SIP proves that it was in fact a somewhat practical one. A whole different story is whether we want to tie ourselves to the complicacies of multiple SDP renegotiations for any non-obvious use case that may or may not exist today in other that slideware form, but that certainly still have to show any decent level of interoperability. Enrico --------------ms010309000107080601050603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MTgw OTIxMzJaMCMGCSqGSIb3DQEJBDEWBBQ2MW45Z2VnRWEjldX3OeA63ZGd7DBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAIptWAgWYBw0j7uCz3rEmDC5W/i5x4lSijHIEZxXq MBHhw4z6qld7dXraTr6u9s3yCj9Zk5Y8QjZivZubXezcvNJ7r2l5c0vzZEf35Y6qyw6gOKzw s6z7mS2nFFPgvlT1ml6qyjM+eiASsp0dWPIcCffDRnRiFoRYBESZHsBwN68h6qWaEDgM3x/q AgXFk4teXSK2AMZyfVSaGTClJkAs7omfY9Z+EDEt7qGBMMWetODKw+8mJaCpYSlbeDUzfsGP shGQTCHZuzbp0ctuKXyhFZ7JWSwsjdYAzr373VwZDsHRBV05U9EJhFTwDl7byfAPhmMAPwjC XQJLVtUxpOe1rAAAAAAAAA== --------------ms010309000107080601050603-- From ibc@aliax.net Tue Jun 18 02:31:20 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B44B21F9BA8 for ; Tue, 18 Jun 2013 02:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0C2ga2JVKKU for ; Tue, 18 Jun 2013 02:31:20 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7819F21F9B79 for ; Tue, 18 Jun 2013 02:31:19 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c10so2174524qcz.0 for ; Tue, 18 Jun 2013 02:31:18 -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=lQZrO3GDv1oxARq9LY8WZRmFOE1Dp3F/+3gfsleK8XE=; b=K+UZ0IniTDkO3WkYn9LU5x49mke3T3ta1wpwx5cX0+GDTBrtxrZp2i5mkfi9ZSPoAs t7kMNPwhRWZKCU92aI8zFYRogX+ZjRkSW9Nrwcif8dLveI0ygfd6SnL0dndESV63bL1Y KhJYOd3BzOqs/4CMK8ou9TQyQJrJ9g6tVuLfXVq9J8w7j74J8LQest2Z0DCu+4lVVKHj QCsSQiE4tG03on+xW2OI5PYckribZwFvuI2oyTgD6T9KI2I+9ag/Qo1fLqkCo5W02dkI Y0qsVHBypa0w9ilxH3JYOR9ziOgzoPXSoVaerRMuVRjN/oEB1LAb6Mkm621Okm5tmKH9 ylsw== X-Received: by 10.224.60.195 with SMTP id q3mr21999951qah.82.1371547878722; Tue, 18 Jun 2013 02:31:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Tue, 18 Jun 2013 02:30:58 -0700 (PDT) In-Reply-To: <51C0269B.5070200@telecomitalia.it> References: <51C0269B.5070200@telecomitalia.it> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 18 Jun 2013 11:30:58 +0200 Message-ID: To: Enrico Marocco Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk98b9LpZ4zbKKnylILfo6WZKyfiT4XzcafikqoxzZrL0yksbj9wiA37a6TQpWiivRp9n8b Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 09:31:20 -0000 2013/6/18 Enrico Marocco : > On 6/18/13 10:31 AM, I=C3=B1aki Baz Castillo wrote: >>> That means the >>> SDP is really just used as a way to tell the browser what ice ufrag, ic= e >>> pwd, and DTLS fingerprint to use. >> >> And do we really need SDP for that? mandatory? > > I won't comment on whether SDP was the best option to begin with, but > the fact that every other person on this list has a demo WebRTC app > that, with little to no manipulation, achieves some kind of *basic* > interoperability with legacy SIP proves that it was in fact a somewhat > practical one. Yes, that is basically a "PSTN call", no more. For sure, many people have seen their mission accomplished with those demos ("we can enter the PSTN from the web, we are done, WebRTC satisfy our needs !!!!"). > A whole different story is whether we want to tie ourselves to the > complicacies of multiple SDP renegotiations for any non-obvious use case > that may or may not exist today in other that slideware form, I could not give my opinion better than what is told in these posts: http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/ http://blog.webrtc.is/2013/06/17/sdp-inside-webrtc-is-bad-for-sip/ -- I=C3=B1aki Baz Castillo From enrico.marocco@telecomitalia.it Tue Jun 18 02:41:46 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47F421F9A99 for ; Tue, 18 Jun 2013 02:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.569 X-Spam-Level: X-Spam-Status: No, score=-101.569 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKoeycCv8SpT for ; Tue, 18 Jun 2013 02:41:39 -0700 (PDT) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id A896521F9930 for ; Tue, 18 Jun 2013 02:41:38 -0700 (PDT) Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 18 Jun 2013 11:41:32 +0200 Received: from MacLab.local (10.229.8.22) by smtp.telecomitalia.it (10.19.9.235) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 18 Jun 2013 11:41:32 +0200 Message-ID: <51C02B4C.2090108@telecomitalia.it> Date: Tue, 18 Jun 2013 11:41:32 +0200 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <51C0269B.5070200@telecomitalia.it> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010300030705010902060206" X-TI-Disclaimer: Disclaimer1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 09:41:47 -0000 --------------ms010300030705010902060206 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/18/13 11:30 AM, I=C3=B1aki Baz Castillo wrote: >>> And do we really need SDP for that? mandatory? >> >> I won't comment on whether SDP was the best option to begin with, but >> the fact that every other person on this list has a demo WebRTC app >> that, with little to no manipulation, achieves some kind of *basic* >> interoperability with legacy SIP proves that it was in fact a somewhat= >> practical one. >=20 > Yes, that is basically a "PSTN call", no more. For sure, many people > have seen their mission accomplished with those demos ("we can enter > the PSTN from the web, we are done, WebRTC satisfy our needs !!!!"). And even from the no-plan side of the fence that looks like a feature rather than a bug. Enrico --------------ms010300030705010902060206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MTgw OTQxMzJaMCMGCSqGSIb3DQEJBDEWBBQvhA4fOX5MZ6AMEk/czqUWXd3lVzBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAYv7OQfxAMMYql8UM3g+qLDYr4IUYFvG0I4e5V02K Pi91QyEFKaTeG4eI2bwAWfyvxdt5fg1s7Y3Pu7IAR4PlsFXJwNojs+JyB6VxWFDSbwU8IuTl zzop6aHf+mevFYoj32gLvlL7uL4TLKCl/DUur3BMYUpBbNxu6j0pbMZ7EvbYTzGm217Ns3A8 37Pr2chjMGsseZrfgCo1SsEdbD/FjM6j7MMDSGdyUwzL2UTUVNVlNanVGtZmvRCyVnt3gq/R S4WKba/E3I3yN7sNnhFr3FvFcKHbTwXuC7eB/sOnElgeJwuntbSrgJ8j26wnLdrAcNu6Gkwa gciTMyXfX8jSrwAAAAAAAA== --------------ms010300030705010902060206-- From prvs=3881e1e3e5=magnus.westerlund@ericsson.com Tue Jun 18 02:56:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C66E21F9B95 for ; Tue, 18 Jun 2013 02:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.066 X-Spam-Level: X-Spam-Status: No, score=-106.066 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zI0qCK1ypGH2 for ; Tue, 18 Jun 2013 02:56:03 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DB5D921F96F5 for ; Tue, 18 Jun 2013 02:55:58 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-d9-51c02eab022b Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AA.A7.09795.BAE20C15; Tue, 18 Jun 2013 11:55:55 +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; Tue, 18 Jun 2013 11:55:53 +0200 Message-ID: <51C02EE8.5070809@ericsson.com> Date: Tue, 18 Jun 2013 11:56:56 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> In-Reply-To: <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+Jvre5qvQOBBlO26Vh82vSJ2WLtv3Z2 ByaPJUt+Mnl8fHqLJYApitsmKbGkLDgzPU/fLoE74+mHmYwFG9QrDv36z97AeE2+i5GTQ0LA ROLAmQlsELaYxIV764FsLg4hgVOMEktubmOHcJYzSqx/3c0OUsUroC0xc/o3JhCbRUBV4vKr FywgNpuAhcTNH41gk0QFgiWObN/MAlEvKHFy5hMgm4NDREBP4ug9TpAws4CwxIaLbWAlwgKW Ej3db5ghdp1mktgx6ycjSIJTwE7i4PITrBDXSUpsedHODtGsJzHlagsjhC0v0bx1NjOILQR0 W0NTB+sERqFZSFbPQtIyC0nLAkbmVYzsuYmZOenl5psYgeF6cMtvgx2Mm+6LHWKU5mBREuf9 dGpXoJBAemJJanZqakFqUXxRaU5q8SFGJg5OEMEl1cBYbv7PJtsljq3hE/exQg+Ln+l+0iK3 dm16Oz1s5W7zlVknfa7/iC8T13iepW9Zc2S/3iGxfP6Up5a/3snm3hHtXvrj90Pf9aHHIkvy Lk1oy1qq+DM6+csRSeacsvUPDz+yOyi+I/PNBAN57Qv3rxtXbV3n/NMjsFlr4/bVzO+zDDUL BDSkjiorsRRnJBpqMRcVJwIAdNGbmyoCAAA= Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 09:56:09 -0000 Hadirel and WG, Please see my response inline. On 2013-06-14 18:58, Hadriel Kaplan wrote: > You can't be serious. There was exactly ONE email asking for agenda > items, here: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html It > was sent on May 30th. It gave a generous 6 days to respond. Luckily > no one ever goes on vacation for longer than 5 days. Instead, two > people sent a response on June 10th, a tremendous 11 days after the > request. Outrageous! That's a almost twice as long as they were > given! > > Thank goodness the chairs detected this monstrous breach of > procedure, and thwarted the attempts of anarchy! I mean if people > are allowed to respond to emails so tardily, how can we be expected > to get things accomplished as quickly as they've so far been in this > WG?!? Yes, we have only sent a single email this time, being the second round in a short time we tried to schedule this meeting. > > Sure, an interim for this topic has been waiting for many months if > not a whole year, and now that people didn't respond in 6 days but > took instead 11 days the topic will be delayed indefinitely yet > again... but that's no excuse for blatantly flaunting the rules! Yes, there has been difficult finding a time could work for this meeting. That was why the agenda request time was short. > > Personally I saw the email on May 30th, and assumed Oscar and Dan > would respond to you for agenda time. I assumed that if no one had > submitted agenda items to you, that the WG Chairs would send out an > email warning about that, or perhaps even directly email the people > who they expected to submit agenda items. > Yes, you assumed that someone would respond. Rather than you reaching out to verify that others would drive the question for you. Hadriel you are apparently very interested in this topic. Why don't you ensure that an agenda topic is on the agenda for Berlin? The WG chairs are happy to receive agenda requests already now. > >> If you want to discuss this, write a draft describing how how your >> additional keying is to be integrated, what the pro and cons of it. >> That will enable direct discussion of a proposal. The WG clearly >> are opinionated on this matter, but apparently don't have energy to >> produce proposals. > > There *are* drafts. > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00 > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 There > are even powerpoint slides, sent to the chairs the last time this > meeting almost happened but didn't. One of those drafts has been expired since February I would like to point out. The looking at these drafts, they are neither a proposal for what to actually do. Dan Wing's draft is argument in general why SDES would be bad for security. Oscar Ohlsson's is an argument for why a number of potential risks are not a serious issue and what the other gains of using security descriptions are. >From my perspective I really would like to see some progress in at least the proposal for actually adding additional keying to ensure that the raised issues in drafts or earlier WG meetings and email discussions are meet. Additionally I would really like to see some more details for how the actual integration of an additional keying mechanism is supposed to work. > > I think the problem must be that those things weren't signed in > triplicate, sent in, sent back, queried, lost, found, subjected to > public enquiry, lost again, and finally buried in soft peat for three > months and recycled as firelighters. No, that is not it. This topic has dragged on for various reasons. Yes we chairs are clearly to blame for some of them, like being slow to attempt to schedule a meeting. However, after that there has been issues finding a suitable time where sufficient mass of people could participate. There has been time conflicts with other meetings resulting in a cancellation, which in hind sight was unnecessary. Then a rescheduling, lurk warm response from the WG, limited agenda items and another almost collision resulting another cancellation. I am sorry that this makes you frustrated. Well, it makes also me frustrated. I wished this topic was dealt with and out of the way, but it is not. So, if you want it dealt with. Please request agenda time for Berlin and ensure to update any drafts or other material to actually take into account what actually has happened in the last 15 months. Regards 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 ---------------------------------------------------------------------- From ibc@aliax.net Tue Jun 18 03:00:03 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F9221F9E03 for ; Tue, 18 Jun 2013 03:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BszB6vNsuBK0 for ; Tue, 18 Jun 2013 03:00:03 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA3321F9E5B for ; Tue, 18 Jun 2013 02:59:59 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so1981225qab.8 for ; Tue, 18 Jun 2013 02:59:59 -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=/91eB0hZTuQqN0bDPzIwK2Beh4CQqmlmdvqf8lFS7ig=; b=Mn1ZYKcshjpWHmIJNrogIOUj6bJd0Ynak+8c0uSe0NVNbmFG77YHHNMvS7rh7hZ6Ue 3RZ5rEvJImOCIfYhO+jPHT5bc+aCbtnsLT4cIG7T3h11LGmPN6zjaoOvtm+aKeBg7XFy zjUspl4S03jT/OyIDZrt7IewzVmOhqVYjwDekMe+BdqQTXthgFczJy/nOJhM4g+rp7YB WcNuyZ+x37aPC67B4wE4/5VTQocp0rBMlVL9xivmWy5wg9DD4n5Lcs6KOelpA1ZbBHRS Q8q+iZQKVXlPRFFZNjRkqswWhvKCh4hMxnYls1AuNfpbsRFSr/TMg6dvvpKZ689b5EAp 3EYA== X-Received: by 10.49.14.161 with SMTP id q1mr9975655qec.50.1371549599599; Tue, 18 Jun 2013 02:59:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Tue, 18 Jun 2013 02:59:38 -0700 (PDT) In-Reply-To: <51C02B4C.2090108@telecomitalia.it> References: <51C0269B.5070200@telecomitalia.it> <51C02B4C.2090108@telecomitalia.it> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 18 Jun 2013 11:59:38 +0200 Message-ID: To: Enrico Marocco Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlUy6kv+ogkiHrtHbAgUiO3ZRer7+pNGRGvlznrAsT9KWUtk9GJte8nG2Ts8LgmfM/wynwO Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 10:00:03 -0000 2013/6/18 Enrico Marocco : >> Yes, that is basically a "PSTN call", no more. For sure, many people >> have seen their mission accomplished with those demos ("we can enter >> the PSTN from the web, we are done, WebRTC satisfy our needs !!!!"). > > And even from the no-plan side of the fence that looks like a feature > rather than a bug. It's easy to build a spec based on "SIP interoperability" and then make a "SIP intercommunication demo". Now the problem is that any *future* custom signaling protocol on top of WebRTC must deal with O/A and SDP limitations. WebRTC innovation subject to SIP model, forever. -- I=C3=B1aki Baz Castillo From emcho@sip-communicator.org Tue Jun 18 03:09:12 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4752921F9BBB for ; Tue, 18 Jun 2013 03:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf8JccszwgvZ for ; Tue, 18 Jun 2013 03:09:01 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0243F21F9BAA for ; Tue, 18 Jun 2013 03:09:00 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id 14so3731518pdj.26 for ; Tue, 18 Jun 2013 03:09:00 -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=Ekc4fZ1mAGqUcoVbGnKV3euDy7sNoVlJTEmmo4bvlWY=; b=VxTHBw+ec0ygBt1pmZIBglghNbbzIGqXbi/p9QJhhNaPl8UX5s8SuH2lOlytc/sh7l uzW8M/4GtsRrd0lo3q6FlgU5qAvF27lrGMxPg/zroRGjLbpnWp3m0qsf2mgjCOoTFXfC S+AAlISnhMIZS69nv5YT65x69SGdZ8E9aULzLLOysv9u/6pCVC+SP5q/wHM3qiy/Debh J+e0LHoC2fEn9pm8nH7wlHUhzAtkXPaFkB9Jrn5ywv+vA4DYIITchNwdOziNu0m+CTVI tkrfHfu2CuCJx5Rle5aezNVCq6c+Z4RCnAVVz7QIqMmhpb40ezuKz8pRebbSbI6y9V2c GeSQ== X-Received: by 10.66.145.2 with SMTP id sq2mr1532019pab.2.1371550140561; Tue, 18 Jun 2013 03:09:00 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [2607:f8b0:400e:c01::232]) by mx.google.com with ESMTPSA id vv6sm18958285pab.6.2013.06.18.03.08.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 03:09:00 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id wz7so3767256pbc.37 for ; Tue, 18 Jun 2013 03:08:59 -0700 (PDT) X-Received: by 10.66.216.136 with SMTP id oq8mr1433376pac.161.1371550139561; Tue, 18 Jun 2013 03:08:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.192.65 with HTTP; Tue, 18 Jun 2013 03:08:39 -0700 (PDT) In-Reply-To: References: <51C0269B.5070200@telecomitalia.it> <51C02B4C.2090108@telecomitalia.it> From: Emil Ivov Date: Tue, 18 Jun 2013 12:08:39 +0200 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkuMCMW8B8I2g7BWeSAI3XQSECgTWJdYwgD7SbjuB2y0PcHv++6BBctAeDqCuTNnXtAWvLa Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 10:09:12 -0000 On Tue, Jun 18, 2013 at 11:59 AM, I=F1aki Baz Castillo wrot= e: > 2013/6/18 Enrico Marocco : >>> Yes, that is basically a "PSTN call", no more. For sure, many people >>> have seen their mission accomplished with those demos ("we can enter >>> the PSTN from the web, we are done, WebRTC satisfy our needs !!!!"). >> >> And even from the no-plan side of the fence that looks like a feature >> rather than a bug. > > It's easy to build a spec based on "SIP interoperability" and then > make a "SIP intercommunication demo". Now the problem is that any > *future* custom signaling protocol on top of WebRTC must deal with O/A > and SDP limitations. WebRTC innovation subject to SIP model, forever. This is exactly what No Plan tries to avoid. It gets you interoperability for widely deployed legacy (as in SIP phones, popular free SBCs and PSTN) and then it lets you do what you want for all the fancy use cases that you are going to come up with. You are in no way hampered by SDP this way. Emil -- https://jitsi.org From ibc@aliax.net Tue Jun 18 04:30:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C6521F9EBC for ; Tue, 18 Jun 2013 04:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.37 X-Spam-Level: X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vet8pF9tzOi for ; Tue, 18 Jun 2013 04:30:29 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0A70721F9EAF for ; Tue, 18 Jun 2013 04:30:28 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id a1so2191113qcx.39 for ; Tue, 18 Jun 2013 04:30: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=dUcz5QMDiWQhgBfuPoJs6oXXZDu++kr1baP3v9Mwkqg=; b=edPiufukEbICJ9zXN5jfESfW3z8I+n6ndUN/gGg1zVX8jmp9LLY5lU8IWfMLXNvOQd 1VONU4vBgXzr4mqjuNb+ch0giXK1VIX0bsu84ki7rFOZ8SkIKuN/iIc+ICr2TbRTqP4t 6+/K21ir/ma60V3PBh7uPQmNhGMYUEQvMdy80mCcMTCSRyl5EsPw7gT/njA3cwHmAiBu 6Yei0KpSyiqyR3kL+p+9K10jqAldU4gb69Ws/kcOp519LnUQGUn9NwSyYlQsyATjVrAO SUT6TXcPMIf+3h+qhjMhKIFojj+Q3MeTNz2VEemgzYh+F5q9CNkzuwly3U27Jx9bzTlY pxBA== X-Received: by 10.229.147.71 with SMTP id k7mr8376217qcv.129.1371555028172; Tue, 18 Jun 2013 04:30:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Tue, 18 Jun 2013 04:30:07 -0700 (PDT) In-Reply-To: References: <51C0269B.5070200@telecomitalia.it> <51C02B4C.2090108@telecomitalia.it> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 18 Jun 2013 13:30:07 +0200 Message-ID: To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlUgSiQi0t1AFCYmos87D6+/d9aQ6y5rSbySjXTt995WCzP/2wKWMWwURxz7xOL0O6yx1te Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 11:30:30 -0000 2013/6/18 Emil Ivov : > This is exactly what No Plan tries to avoid. It gets you > interoperability for widely deployed legacy (as in SIP phones, popular > free SBCs and PSTN) and then it lets you do what you want for all the > fancy use cases that you are going to come up with. You are in no way > hampered by SDP this way. Hi Emil, I understand your aim and really appreciate your effort (as I said before, it is much better than fully depending on SDP for any media operation). However let me expose the following questions, and I would be very grateful if you answer inline: * SIP over WebSocket JS app running in the browser (so SIP signaling is used in the wire). * I send the initial INVITE with the SDP I retrieve from the local PC (I am the JS app). * Later I want to put the remote peer on hold, so I need to send a re-INVITE with same SDP but some differences: - Increased SDP version number. - a=3Dinactive in every m=3D sections. * How to do that? As far as I can imagine: - I need to keep the initial SDP or retrieve it again from the PC, so I get a string blob. I can "expect" how such a string blob looks, but I cannot be sure since the same SDP can be represented in multiple ways. - So I need to *parse* the SDP at JS level, right? and then I need to mangle it (for increasing version number and adding a=3Dinactive), right?. - And then I must pause/stop my local streams (via PC API call), generate the re-INVITE with the mangled SDP, and send it to the remote, right? - Then the remote peer receives it. Since it is also a SIP JS app, it must *parse* the SDP at JS level and realize that there are a=3Dinactive lines in every m=3D sections, right? Then it could notify the human user that "the remote has put the call on hold". - Then, should the remote JS app pass the SDP to its PC? I expect not (just wondering). - And finally, the remote peer (its JS SIP app) should also mangle its initial SDP for increasing the version number and adding a=3Dinactive or a=3Drecvonly in every m=3D sections, right? and then send it into a SIP 200 OK. So, unless I'm fully wrong, a simple use case (hold/unhold application so widely extended in SIP) requires: * SDP parsing at JS. * SDP mangling at JS. And such a parsing and mangling must be done over a string blob that can have multiple representations (which depends on each WebRTC implementation). Even worse, some non-browser-WebRTC-devices may add a=3Dinactive/sendonly before the m=3D sections (global SDP attribute), so my JS app must be ready to detect it, right? Does it really look nice? IMHO the mechanism you propose makes WebRTC easy for very-very-very-ultra-basic use cases (basically an audio/video call with no media changes) and makes it really complex for implementing any kind of media modification or media application (i.e. "hold" / "unhold"). Another example: * I am a powerful SIP conference server which properly implements WebRTC. I initiate a call to 5 users (running JS SIP app in their browsers). The initial INVITE has SSRC/MSID fields in the SDP identifying all the participants, am I right? * Later, during the conference, I call to another 6th participant and enter him into the conference, so I need to send a re-INVITE to every participant with a modified version of the SDP (note that this is SIP protocol, so I need to use SIP messages to carry the new info about SSRC/MSID and so on). * Magically I (the server) create the new SDP with the SSRC/MSID of the new stream associated to the new participant, and send it into a re-INVITE to every participant. * Now a participant receives it and must be able to know what has been modified (in order to render it in the HTML, i.e. by drawing a new

    --047d7b86f75ebc4fc304df704de1-- From ibc@aliax.net Tue Jun 18 09:36:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B905521F9994 for ; Tue, 18 Jun 2013 09:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zR3YZn8Vj60m for ; Tue, 18 Jun 2013 09:36:42 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3A97D21F9980 for ; Tue, 18 Jun 2013 09:36:42 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id f11so2248128qae.17 for ; Tue, 18 Jun 2013 09:36:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=w7+Ud8nmkePUYA6EACG+vNye3wdqauGX9f+yJD/nOfY=; b=SpvpK//DpUI3+8QCU8ajO10JVH8FMd9SipPXAh14+6jV4GwqNLJYmHfVvrR6Qam2s5 Pjzvyabjxbw5lYlaUQAKHGzCXJacdhggy5ek4X0SoKvzWmnEeQbZ9BfjhslfE7/1Su/s rxp9wLEfK75AzSlSIFQyhk1uiYK60U5n8GPgWfCvawDxj+d7ndywOAoekbwV/h20N5g5 VQyq6aViLdJc4cIvf0Log+6UOYdcrslSNfY/XhA/Hp4VWrJcelluOeP22RAQM/Yfe8M6 n20iC2Ee7drzyghz3Dyz0ris7YbykkFpPPTFPXNO+hcUzOo51pjoiXdoTIw+U6mwzFrS p5gg== X-Received: by 10.224.164.205 with SMTP id f13mr23471823qay.16.1371573401657; Tue, 18 Jun 2013 09:36:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Tue, 18 Jun 2013 09:36:21 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 18 Jun 2013 18:36:21 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkWJOp9qu1oo2WY5YK1t20KU4jAuAZzheBx3+PKyarBm5NiruVb8goULFDTaHKRA/TsoAYO Subject: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 16:36:42 -0000 Hi all, I re-send this mail in a new thread. Dear WG Chairs, With all due respect, IMHO there is too much controversy about SDP usage in WebRTC so I would like to request the WG to reopen the "SDP or not SDP" debate. I would also appreciate that those in favour of mandating SDP as the core communication for WebRTC explain their rationale again (given the number of arguments against SDP and the frustration SDP is causing), and also that they give arguments and responses to all the SDP related issues nicely summarized in this mail: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html Thanks a lot. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Jun 18 09:37:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6189911E80E2 for ; Tue, 18 Jun 2013 09:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUp9Mjv6jht3 for ; Tue, 18 Jun 2013 09:37:33 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id D6BBE11E80A2 for ; Tue, 18 Jun 2013 09:37:32 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id n1so2395427qcx.8 for ; Tue, 18 Jun 2013 09:37:32 -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=pgBhkzt5x8ZWZBpWKNYyxv8PhKw/pV5WR4agdpqfYR0=; b=KUaWHLFaHOp/d42NdotpcVAArXvwhyZSJIxjbDESYOGgVbNaCuhgEGmzM2R7tUC8p7 Gq4kp4XMqz2dRXekv9V7r96SMI0jnUJPrRQeInm3wqrvwRZx0n+LiOT/BTnsjm/wKq53 T0L2c/RiOFun1A41kqaIAtMBrxMr0NHM3bTtDINGq7Jw7MmyPm+BbDzlWTol2Bi5CP1r ZSgmZ1TpFqYsqwyuTzkUHVTbXvQLnEk/DNdfI5/sDXG+s/mqGcNqt6ltY0NW3hXCvD2/ B2XYmtB3zHTknpTcuHiepU87aaUPO7jUCC3BeGZvmCyNdhZ1spDGs6uuRk9GWl+HnhbE awmw== X-Received: by 10.49.109.72 with SMTP id hq8mr28525566qeb.38.1371573452288; Tue, 18 Jun 2013 09:37:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Tue, 18 Jun 2013 09:37:12 -0700 (PDT) In-Reply-To: References: <51C0269B.5070200@telecomitalia.it> <51C069CD.6000804@hookflash.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 18 Jun 2013 18:37:12 +0200 Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn62FO4I/AAga7oLIjjmcf8hCK3ltJAULwLxGfd7kuQ9PUq6aCdKB05CjP+WNiVKRYIHVsC Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 16:37:33 -0000 2013/6/18 Peter Thatcher : > While I appreciate your desires to see a cleaner API (such that a JS app = can > choose not to use SDP), but I'd really like to keep this thread focused o= n > the proposal made: the addition of two methods to PeerConnection that > greatly improve the situation for adding streams. > > We are not proposing eliminating SDP altogether. While such a proposal a= nd > discussion may have merit, that's not what we are proposing, so please st= art > a separate thread to discuss it. Yes Peter, you are right, sorry for that. I've opened a new thread. -- I=C3=B1aki Baz Castillo From elagerway@gmail.com Tue Jun 18 10:19:17 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F8911E80EE for ; Tue, 18 Jun 2013 10:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JdKkLYqmZr9 for ; Tue, 18 Jun 2013 10:19:16 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 386EE11E80E6 for ; Tue, 18 Jun 2013 10:19:15 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so3493607wev.8 for ; Tue, 18 Jun 2013 10:19:15 -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=5/qAl4BOpowLsm2rQGNoFgfUkMAEcEcB8Z9rd/DAw50=; b=iC653oj8cfzo90fGHNclb0CFz5yfCSLWHUSYaHS0BsZOVtwbr5BSWGtZ12B/xU+BGK XhQAuzzhZjroQufwIA9kwACylsbCMG6xikOA95qNAG6q3u/elvp9RTIvU65Ilrng5Zin kkK3EfDVxjkecY7MSjkYksuvjSzuTk7XKKwUiHRzUbXhyhr2boaZt5r04L9AjfERHwCi fn6vWBauwZpe/OtyVIBGI7Iz8ix+1s5ewM/tQDpX2e7L6BMWKO/sLOGpgF32lsU9GvLC PBggrhsLVAqLNtMtVa1E+/bBpzhl6/XZ0zuQ+iJBAczo/bSGtUe+Xg2lRLOBDDAIhKrn Xo7A== MIME-Version: 1.0 X-Received: by 10.180.198.175 with SMTP id jd15mr8192395wic.28.1371575955027; Tue, 18 Jun 2013 10:19:15 -0700 (PDT) Sender: elagerway@gmail.com Received: by 10.216.22.132 with HTTP; Tue, 18 Jun 2013 10:19:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Jun 2013 10:19:14 -0700 X-Google-Sender-Auth: 9LbDICuV8xE5BkLxn13wHPB-37E Message-ID: From: Erik Lagerway To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7b62495694fc3604df70e99a Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 17:19:17 -0000 --047d7b62495694fc3604df70e99a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 to re-open the debate re: SDP Although, as MK and RR have commented, it's not just SDP that is the issue. We need to take a hard look at O/A as well. /Erik *Erik Lagerway | *Hookflash * | Twitter | WebRTC.is Blog * **** On Tue, Jun 18, 2013 at 9:36 AM, I=F1aki Baz Castillo wrote= : > Hi all, I re-send this mail in a new thread. > > > Dear WG Chairs, > > With all due respect, IMHO there is too much controversy about SDP > usage in WebRTC so I would like to request the WG to reopen the "SDP > or not SDP" debate. > > I would also appreciate that those in favour of mandating SDP as the > core communication for WebRTC explain their rationale again (given the > number of arguments against SDP and the frustration SDP is causing), > and also that they give arguments and responses to all the SDP related > issues nicely summarized in this mail: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html > > > Thanks a lot. > > > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b62495694fc3604df70e99a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    +1 to re-open the debate re: SDP

    Althou= gh, as MK and RR have commented, it's not just SDP that is the issue. W= e need to take a hard look at O/A as well.

    /Erik

    <= span style=3D"border-collapse:collapse;line-height:14px">Erik Lagerway | Hookflash<= font color=3D"#943634"> | Twitter | WebRTC.i= s Blog =
    <= /span>


    On Tue, Jun 18, 2013 at 9:36 AM, I=F1aki= Baz Castillo <ibc@aliax.net> wrote:
    Hi all, I re-send this mail in a new thread.


    Dear WG Chairs,

    With all due respect, IMHO there is too much controversy about SDP
    usage in WebRTC so I would like to request the WG to reopen the "SDP or not SDP" debate.

    I would also appreciate that those in favour of mandating SDP as the
    core communication for WebRTC explain their rationale again (given the
    number of arguments against SDP and the frustration SDP is causing),
    and also that they give arguments and responses to all the SDP related
    issues nicely summarized in this mail:

    =A0 http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg07873.html


    Thanks a lot.


    --
    I=F1aki Baz Castillo
    <ibc@aliax.net>
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    = https://www.ietf.org/mailman/listinfo/rtcweb

    --047d7b62495694fc3604df70e99a-- From robin@hookflash.com Tue Jun 18 10:20:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1C721F8F24 for ; Tue, 18 Jun 2013 10:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pb7LR2oZkSQa for ; Tue, 18 Jun 2013 10:20:45 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFBB21F8930 for ; Tue, 18 Jun 2013 10:20:45 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id wo10so4952612obc.31 for ; Tue, 18 Jun 2013 10:20:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=ag6tHtGaN5VTW3SNK82inoy0d1h0Wl01hKfTdStwnTA=; b=kmb0a0pK925XKm94QCWH+PvntUD8maTQj3IFPENz3YEeq9QtbKWtlysZYE5Ad8H8W/ E/OTXVj7JoNT94CT57CdSsD0WsKalJjhAJHe6h4yMeZ+wEwGHBy3+77rLYEmH6u32RBk 8i1w+ZfXShxkmdXXP3SZS2f8HSROQtLaBFaPvwReq+ir8ZyWW1uTJyvfX08QGNsCtMdk 0vIlp4+l0tOfZX5ye3vZLiT2ALhNJFFv12ku5GqGNAhiuGJmfidVquPhSIgelgcWhsxG hdK8iU0z2rH1qh7siWx0fl6lX2jicN3kq3EfR+ZggdWW9vikkI7w9uDSj9o+sVDc0ly4 CQiw== X-Received: by 10.60.92.163 with SMTP id cn3mr12696291oeb.107.1371576044740; Tue, 18 Jun 2013 10:20:44 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id z5sm22661938obw.4.2013.06.18.10.20.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 10:20:43 -0700 (PDT) Message-ID: <51C096E8.2000300@hookflash.com> Date: Tue, 18 Jun 2013 13:20:40 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080607090602050601070408" X-Gm-Message-State: ALoCoQk2nWgBti7+u3e0gifw0977fgspyDWuoSPSRtvLxomxgus19nbMhxxpG+Ecd2hypMtM0apG Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 17:20:45 -0000 This is a multi-part message in MIME format. --------------080607090602050601070408 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit +1 ... and to be clear it's SDP with offer/answer that really makes it horrible. Replacing with nicer JSON or a wrapper API solves nothing IMHO. -Robin > Iñaki Baz Castillo > 18 June, 2013 12:36 PM > > I would also appreciate that those in favour of mandating SDP as the > core communication for WebRTC explain their rationale again (given the > number of arguments against SDP and the frustration SDP is causing), > and also that they give arguments and responses to all the SDP related > issues nicely summarized in this mail: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html > --------------080607090602050601070408 Content-Type: multipart/related; boundary="------------060401090906040107040100" --------------060401090906040107040100 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
    +1

    ... and to be clear it's SDP with offer/answer that really makes it horrible. Replacing with nicer JSON or a wrapper API solves nothing IMHO.

    -Robin


    18 June, 2013 12:36 PM

    I would also appreciate that those in favour of mandating SDP as the
    core communication for WebRTC explain their rationale again (given the
    number of arguments against SDP and the frustration SDP is causing),
    and also that they give arguments and responses to all the SDP related
    issues nicely summarized in this mail:

    http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html

    --------------060401090906040107040100 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxD9py+sZfjkviDxZNpF7b6h4d024uZb2x t7iQ3Ei/NuZkLAnggZwAwwAMVni+ZaU9ztwUafM5VtjEbQ/g0PD3/CSiz8MiBG2hlsrfBf02 iPn6Vwc+I2uel7DCfHbQn/Zrv9HvP2kfDcmk2+k2umTWl2q+TpkFs5kUAABljV1bLAjBByM1 24NzWlR6nnYyEG1KitD6v/4X78Wf+h4vv++Y/wD4mu3lRwninx/8CWFzqnhTxPelfsmuaPb2 cvOGE0UMZBz/ALgH5GuTGxcf3qPUwEoT/dSPKU8P+G1hGgb4vsP25l4cbgNgXP6detec5T+I 9lUaXLynqf7OHgDT7n4knX7IRiw8NKiLk5dppCSuPbCsT9BXZgqbqv2j6Hl46pClenHqrGl/ aC+o/OvSPGND9om/0xvhX4W0t763TXbSW1aOxeQC4ASBo5gU6jDYByBgjHWscY4+z1OnCX9r ofOZvNPWMvJc3PD7jAN2Q3pj0z2ryby5T3/rEeXlsfQv7K/iDw1pOhapZ6nrNjaa3e3xuGtJ 51SUwJGu1gCRkDLZxnFelgZQ9m0meHjU/aXZQ/4RHxx/0Jmvf+C6b/4mujmOM8Y/bJ/5PT+K P/X3a/8AoiKuLEbI6cN8R5mf9RP/ANdK5mdg7wx/yVDwJ/2Nmm/+jkrajuc2K2R+9VdJxn// 2Q== --------------060401090906040107040100-- --------------080607090602050601070408-- From roman@telurix.com Tue Jun 18 10:25:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F8721F9B95 for ; Tue, 18 Jun 2013 10:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.972 X-Spam-Level: X-Spam-Status: No, score=-0.972 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs2IKplF-EWz for ; Tue, 18 Jun 2013 10:25:24 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id A4AA821F9B94 for ; Tue, 18 Jun 2013 10:25:23 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so3600147wes.21 for ; Tue, 18 Jun 2013 10:25:22 -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=UG2T/oQqqpAnKV2VUmaoNzM4eqxfUOfluGyGSWG6kCI=; b=AQ4G8Rgw+efNgQxFVU9Hr3I1iD1ZGZ4l70cpHtF+b2olyd4WavyBYbOrgllwj9inr+ xDbOK6YWzmVmgHMbdi+1Yq8CZ1jdEIVmI71HbiDlgB6Q5/kzL9oRQYS314D3PIAvb3SZ 3U4RmK7amV+c9FBZE+pxyFBFpawmIcgasgLzaTcwMbeV5PFCLDM56iqKSHa/wcCBZDP3 JfPcrRv9sPkKzpkQW042ty5jBumlAUCrGNYbtGdzNJE2lFnzckPjkX6DU0WZ+KmpxgLL CzTWyYVOOFklFJ5cFwHbW4B0crvZTwNljeyH7TL2g70UIoGPQBJ3cjaHJUeHGiyDrr/M AU+A== X-Received: by 10.194.48.49 with SMTP id i17mr3314342wjn.55.1371576322762; Tue, 18 Jun 2013 10:25:22 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [2a00:1450:400c:c03::22b]) by mx.google.com with ESMTPSA id f8sm3503258wiv.0.2013.06.18.10.25.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 10:25:21 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so3674093wev.30 for ; Tue, 18 Jun 2013 10:25:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.85.6 with SMTP id d6mr8179499wiz.47.1371576320564; Tue, 18 Jun 2013 10:25:20 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Tue, 18 Jun 2013 10:25:20 -0700 (PDT) In-Reply-To: <51C096E8.2000300@hookflash.com> References: <51C096E8.2000300@hookflash.com> Date: Tue, 18 Jun 2013 13:25:20 -0400 Message-ID: From: Roman Shpount To: Robin Raymond Content-Type: multipart/related; boundary=f46d0442808e5ea7fa04df70ff59 X-Gm-Message-State: ALoCoQkmkZa13HxGfDNT87SAJ6XLEwZlqsEJKdfG7Jy1vPUtTZqjwhiCI8LzNLgCfNBxuwhc2paD Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 17:25:25 -0000 --f46d0442808e5ea7fa04df70ff59 Content-Type: multipart/alternative; boundary=f46d0442808e5ea7f804df70ff58 --f46d0442808e5ea7f804df70ff58 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am also strongly for removing O/A and SDP from the API. This is a wrong API surface that does not provide the necessary degree of control for building WebRTC apps. _____________ Roman Shpount On Tue, Jun 18, 2013 at 1:20 PM, Robin Raymond wrote: > > +1 > > ... and to be clear it's SDP with offer/answer that really makes it > horrible. Replacing with nicer JSON or a wrapper API solves nothing IMHO. > > -Robin > > > I=F1aki Baz Castillo > 18 June, 2013 12:36 PM > > I would also appreciate that those in favour of mandating SDP as the > core communication for WebRTC explain their rationale again (given the > number of arguments against SDP and the frustration SDP is causing), > and also that they give arguments and responses to all the SDP related > issues nicely summarized in this mail: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d0442808e5ea7f804df70ff58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am also strongly for removing O/A and SDP from the API. This is a wrong A= PI surface that does not provide the necessary degree of control for buildi= ng WebRTC apps.
    _____________
    Roman Shpount


    On Tue, Jun 18, 2013 at 1:20 PM, Robin R= aymond <robin@hookflash.com> wrote:

    +1

    ... and to be clear it's SDP with offer/answer that really makes it=20 horrible. Replacing with nicer JSON or a wrapper API solves nothing=20 IMHO.

    -Robin


    =20 18 June, 2013=20 12:36 PM

    = I would also=20 appreciate that those in favour of mandating SDP as the
    core=20 communication for WebRTC explain their rationale again (given the
    number of arguments against SDP and the frustration SDP is causing),
    and=20 also that they give arguments and responses to all the SDP related
    issue= s nicely summarized in this mail:

    =20 http://www.ietf.org/mail-archive/web/rtcweb/current/ms= g07873.html


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


    --f46d0442808e5ea7f804df70ff58-- --f46d0442808e5ea7fa04df70ff59 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ddd9d19dcf12aa45_0.0.1.1 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkI CQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkLEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAARCAAZABkDAREA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxD9py +sZfjkviDxZNpF7b6h4d024uZb2xt7iQ3Ei/NuZkLAnggZwAwwAMVni+ZaU9ztwUafM5VtjEbQ/g 0PD3/CSiz8MiBG2hlsrfBf02iPn6Vwc+I2uel7DCfHbQn/Zrv9HvP2kfDcmk2+k2umTWl2q+TpkF s5kUAABljV1bLAjBByM124NzWlR6nnYyEG1KitD6v/4X78Wf+h4vv++Y/wD4mu3lRwninx/8CWFz qnhTxPelfsmuaPb2cvOGE0UMZBz/ALgH5GuTGxcf3qPUwEoT/dSPKU8P+G1hGgb4vsP25l4cbgNg XP6detec5T+I9lUaXLynqf7OHgDT7n4knX7IRiw8NKiLk5dppCSuPbCsT9BXZgqbqv2j6Hl46pCl enHqrGl/aC+o/OvSPGND9om/0xvhX4W0t763TXbSW1aOxeQC4ASBo5gU6jDYByBgjHWscY4+z1On CX9rofOZvNPWMvJc3PD7jAN2Q3pj0z2ryby5T3/rEeXlsfQv7K/iDw1pOhapZ6nrNjaa3e3xuGtJ 51SUwJGu1gCRkDLZxnFelgZQ9m0meHjU/aXZQ/4RHxx/0Jmvf+C6b/4mujmOM8Y/bJ/5PT+KP/X3 a/8AoiKuLEbI6cN8R5mf9RP/ANdK5mdg7wx/yVDwJ/2Nmm/+jkrajuc2K2R+9VdJxn//2Q== --f46d0442808e5ea7fa04df70ff59-- From agouaillard@gmail.com Tue Jun 18 10:40:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301E521F9967 for ; Tue, 18 Jun 2013 10:40:52 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9QuW8qEf1P4 for ; Tue, 18 Jun 2013 10:40:51 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id C945721F965B for ; Tue, 18 Jun 2013 10:40:41 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id o6so5431056oag.13 for ; Tue, 18 Jun 2013 10:40: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=pkqvicEi0u27hidfbgOcOE1dFgOxQvv/pgrAgcmvh6I=; b=LnMk6jD+8d/vsn1+X72qxgfZ4ebPGKwLIe3NyquEwwKKdgG3WJapBBDzvttGAKvW06 7y9C28mzyoyh0qzbscdaFeAMlPMqN9KIN/PhnWkDiXZxRjVAFThoxPLjAqYntjr9v9Xq FawZVgxmU1EcwQLGtj6K+uoTdjmL5C8lshEPU3ixIbIxWsXo6/veaNw10sJYMsneqwlf SK0szSjXG4PgWBWU2BnX3MvR6RTIOf/muPsovPBpeqEIS7+P1xYKRrvABhBuIsVPeEzE wiGh30pv5w7ByZyw4z6qHhUNjwW8l5ZdZN9LC3eiHpliWuVILVXhunf21FEdPLxZhL6G 8tow== MIME-Version: 1.0 X-Received: by 10.60.44.168 with SMTP id f8mr13029906oem.133.1371577241120; Tue, 18 Jun 2013 10:40:41 -0700 (PDT) Received: by 10.182.49.8 with HTTP; Tue, 18 Jun 2013 10:40:40 -0700 (PDT) In-Reply-To: References: <51C096E8.2000300@hookflash.com> Date: Tue, 18 Jun 2013 13:40:40 -0400 Message-ID: From: Alexandre GOUAILLARD To: Roman Shpount Content-Type: multipart/related; boundary=001a113343d23d39a604df713664 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 17:40:52 -0000 --001a113343d23d39a604df713664 Content-Type: multipart/alternative; boundary=001a113343d23d39a504df713663 --001a113343d23d39a504df713663 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 to reopening the discussion. On Tue, Jun 18, 2013 at 1:25 PM, Roman Shpount wrote: > I am also strongly for removing O/A and SDP from the API. This is a wrong > API surface that does not provide the necessary degree of control for > building WebRTC apps. > _____________ > Roman Shpount > > > On Tue, Jun 18, 2013 at 1:20 PM, Robin Raymond wrote= : > >> >> +1 >> >> ... and to be clear it's SDP with offer/answer that really makes it >> horrible. Replacing with nicer JSON or a wrapper API solves nothing IMHO= . >> >> -Robin >> >> >> I=F1aki Baz Castillo >> 18 June, 2013 12:36 PM >> >> I would also appreciate that those in favour of mandating SDP as the >> core communication for WebRTC explain their rationale again (given the >> number of arguments against SDP and the frustration SDP is causing), >> and also that they give arguments and responses to all the SDP related >> issues nicely summarized in this mail: >> >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html >> >> >> _______________________________________________ >> 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 > > --001a113343d23d39a504df713663 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    +1 to reopening the discussion.


    On Tue, Jun 18, 2013 at 1:25 PM, R= oman Shpount <roman@telurix.com> wrote:
    I am also strongly for removing O/A and SDP = from the API. This is a wrong API surface that does not provide the necessa= ry degree of control for building WebRTC apps.
    _____________
    Roman = Shpount


    On Tue, Jun 18, 2= 013 at 1:20 PM, Robin Raymond <robin@hookflash.com> wrote:=

    +1

    ... and to be clear it's SDP with offer/answer that really makes it=20 horrible. Replacing with nicer JSON or a wrapper API solves nothing=20 IMHO.

    -Robin


    =20 18 June, 2013=20 12:36 PM

    = I would also=20 appreciate that those in favour of mandating SDP as the
    core=20 communication for WebRTC explain their rationale again (given the
    number of arguments against SDP and the frustration SDP is causing),
    and=20 also that they give arguments and responses to all the SDP related
    issue= s nicely summarized in this mail:

    =20 http://www.ietf.org/mail-archive/web/rtcweb/current/ms= g07873.html


    _________________________________________= ______
    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


    --001a113343d23d39a504df713663-- --001a113343d23d39a604df713664 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ddd9d19dcf12aa45_0.0.1.1 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkI CQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkLEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAARCAAZABkDAREA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxD9py +sZfjkviDxZNpF7b6h4d024uZb2xt7iQ3Ei/NuZkLAnggZwAwwAMVni+ZaU9ztwUafM5VtjEbQ/g 0PD3/CSiz8MiBG2hlsrfBf02iPn6Vwc+I2uel7DCfHbQn/Zrv9HvP2kfDcmk2+k2umTWl2q+TpkF s5kUAABljV1bLAjBByM124NzWlR6nnYyEG1KitD6v/4X78Wf+h4vv++Y/wD4mu3lRwninx/8CWFz qnhTxPelfsmuaPb2cvOGE0UMZBz/ALgH5GuTGxcf3qPUwEoT/dSPKU8P+G1hGgb4vsP25l4cbgNg XP6detec5T+I9lUaXLynqf7OHgDT7n4knX7IRiw8NKiLk5dppCSuPbCsT9BXZgqbqv2j6Hl46pCl enHqrGl/aC+o/OvSPGND9om/0xvhX4W0t763TXbSW1aOxeQC4ASBo5gU6jDYByBgjHWscY4+z1On CX9rofOZvNPWMvJc3PD7jAN2Q3pj0z2ryby5T3/rEeXlsfQv7K/iDw1pOhapZ6nrNjaa3e3xuGtJ 51SUwJGu1gCRkDLZxnFelgZQ9m0meHjU/aXZQ/4RHxx/0Jmvf+C6b/4mujmOM8Y/bJ/5PT+KP/X3 a/8AoiKuLEbI6cN8R5mf9RP/ANdK5mdg7wx/yVDwJ/2Nmm/+jkrajuc2K2R+9VdJxn//2Q== --001a113343d23d39a604df713664-- From ag@ag-projects.com Tue Jun 18 11:22:41 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A1C21F9BD5 for ; Tue, 18 Jun 2013 11:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os039iJSuGxr for ; Tue, 18 Jun 2013 11:22:35 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id E3A2F21F9BAF for ; Tue, 18 Jun 2013 11:22:33 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 4C655B35DD; Tue, 18 Jun 2013 20:22:30 +0200 (CEST) Received: from ag-retina.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id C5515B017A for ; Tue, 18 Jun 2013 20:22:29 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Adrian Georgescu In-Reply-To: <5165CF9D.6030302@jesup.org> Date: Tue, 18 Jun 2013 20:22:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5158F0FC.3070104@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02B56F@FR711WXCHMBA02.zeu.alcatel-lucent.com> <5165CF9D.6030302@jesup.org> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 18:22:41 -0000 +1 While working with the specs, some may have realised that SDP is not = such a great idea to put in practice and may also want to come forward = to admit their mistake. Regards, Adrian From matthew.kaufman@skype.net Tue Jun 18 12:02:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE2311E80FC for ; Tue, 18 Jun 2013 12:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Y2YZehfKj6u for ; Tue, 18 Jun 2013 12:02:50 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9205111E80F7 for ; Tue, 18 Jun 2013 12:02:44 -0700 (PDT) Received: from BL2FFO11FD009.protection.gbl (10.173.161.201) by BL2FFO11HUB009.protection.gbl (10.173.161.111) with Microsoft SMTP Server (TLS) id 15.0.707.0; Tue, 18 Jun 2013 19:02:41 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD009.mail.protection.outlook.com (10.173.161.15) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 18 Jun 2013 19:02:41 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.171]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0136.001; Tue, 18 Jun 2013 19:02:23 +0000 From: "Matthew Kaufman (SKYPE)" To: Magnus Westerlund , Hadriel Kaplan Thread-Topic: [rtcweb] No Interim on SDES at this juncture Thread-Index: AQHOZrw6CQcaVcHO7ESUEcTH2Hsm5ZkxWrGAgADdvYCAAA4GAIACkewAgACbDYCABdNvAIAAlhWI Date: Tue, 18 Jun 2013 19:02:22 +0000 Message-ID: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com>, <51C02EE8.5070809@ericsson.com> In-Reply-To: <51C02EE8.5070809@ericsson.com> 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="iso-8859-1" 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:(377454002)(189002)(51704005)(199002)(24454002)(52314003)(377424003)(77982001)(79102001)(31966008)(66066001)(74876001)(81542001)(80022001)(561944002)(23756003)(69226001)(46102001)(33656001)(74366001)(44976003)(76786001)(81342001)(54316002)(6806003)(76482001)(56816003)(47776003)(54356001)(76796001)(50466002)(20776003)(55846006)(77096001)(53806001)(59766001)(74706001)(63696002)(56776001)(65816001)(47736001)(49866001)(4396001)(51856001)(47446002)(15202345002)(74502001)(47976001)(74662001)(50986001)(16406001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB009; H:TK5EX14MLTC104.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0881A7A935 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 19:02:55 -0000 Back on April 25th, I made some claims. I still believe these are true:=0A= =0A= 1. DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it is ju= st a different encrypted channel over which the key is set.=0A= =0A= 2. DTLS-SRTP w/EKT requires a more complex media gateway relationship for i= nterworking (as it needs to be in-path for the keying on that side, despite= the use of SDES on the other side).=0A= =0A= 3. DTLS-SRTP w/EKT for interworking exposes the key via SDES on the other s= ide of the interworking relationship anyway, so even though there isn't SDE= S to the browser there's SDES on the other (likely SIP) side.=0A= =0A= 4. And DTLS-SRTP without EKT fails completely for the cases where the key n= eeds to be set for interworking.=0A= =0A= 5. And finally, to get the browser-to-browser security guarantees you would= need to be A) sure that you're really talking browser to browser and not v= ia something else in path (like a mixer) and B) would really prefer that th= ere be no way that the in-path device be able to force a key (thus you'd wa= nt to NOT allow EKT in the browser-to-browser case, even though there's no = way for a browser to know for sure what it is talking to... I suppose that = *if* you trusted your browser and the browser at the other end (which you n= eed to do anyway, because they could just leak keys or media), you could ma= ndate that browsers set some bit that disallows EKT and hope that the other= end respects it)=0A= =0A= =0A= Since we can't get interworking at all without either DTLS-SRTP + EKT or SD= ES, and since the security guarantees of DTLS-SRTP + EKT are the same as th= ose of SDES, and since the interworking gateway is made more complex (becau= se the keying must be in-path), I believe the only possible conclusions are= A) We accept that interworking with other SRTP systems is desirable and th= erefore SDES is the best way to achieve that or B) We prevent any interwork= ing with other RTP or SRTP systems.=0A= =0A= As someone who could make some money sending traffic to/from non-RTCWEB net= works, I'm a fan of "A".=0A= =0A= And no, I'm not planning on writing a draft that says to just do what we sh= ould be doing anyway.=0A= =0A= Matthew Kaufman=0A= =0A= =0A= ________________________________________=0A= From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Magnus= Westerlund [magnus.westerlund@ericsson.com]=0A= Sent: Tuesday, June 18, 2013 2:56 AM=0A= To: Hadriel Kaplan=0A= Cc: rtcweb@ietf.org=0A= Subject: Re: [rtcweb] No Interim on SDES at this juncture=0A= =0A= Hadirel and WG,=0A= =0A= Please see my response inline.=0A= =0A= On 2013-06-14 18:58, Hadriel Kaplan wrote:=0A= > You can't be serious. There was exactly ONE email asking for agenda=0A= > items, here:=0A= > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html It=0A= > was sent on May 30th. It gave a generous 6 days to respond. Luckily=0A= > no one ever goes on vacation for longer than 5 days. Instead, two=0A= > people sent a response on June 10th, a tremendous 11 days after the=0A= > request. Outrageous! That's a almost twice as long as they were=0A= > given!=0A= >=0A= > Thank goodness the chairs detected this monstrous breach of=0A= > procedure, and thwarted the attempts of anarchy! I mean if people=0A= > are allowed to respond to emails so tardily, how can we be expected=0A= > to get things accomplished as quickly as they've so far been in this=0A= > WG?!?=0A= =0A= Yes, we have only sent a single email this time, being the second round=0A= in a short time we tried to schedule this meeting.=0A= =0A= >=0A= > Sure, an interim for this topic has been waiting for many months if=0A= > not a whole year, and now that people didn't respond in 6 days but=0A= > took instead 11 days the topic will be delayed indefinitely yet=0A= > again... but that's no excuse for blatantly flaunting the rules!=0A= =0A= Yes, there has been difficult finding a time could work for this=0A= meeting. That was why the agenda request time was short.=0A= =0A= >=0A= > Personally I saw the email on May 30th, and assumed Oscar and Dan=0A= > would respond to you for agenda time. I assumed that if no one had=0A= > submitted agenda items to you, that the WG Chairs would send out an=0A= > email warning about that, or perhaps even directly email the people=0A= > who they expected to submit agenda items.=0A= >=0A= =0A= Yes, you assumed that someone would respond. Rather than you reaching=0A= out to verify that others would drive the question for you. Hadriel you=0A= are apparently very interested in this topic. Why don't you ensure that=0A= an agenda topic is on the agenda for Berlin? The WG chairs are happy to=0A= receive agenda requests already now.=0A= =0A= >=0A= >> If you want to discuss this, write a draft describing how how your=0A= >> additional keying is to be integrated, what the pro and cons of it.=0A= >> That will enable direct discussion of a proposal. The WG clearly=0A= >> are opinionated on this matter, but apparently don't have energy to=0A= >> produce proposals.=0A= >=0A= > There *are* drafts.=0A= > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00=0A= > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 There=0A= > are even powerpoint slides, sent to the chairs the last time this=0A= > meeting almost happened but didn't.=0A= =0A= One of those drafts has been expired since February I would like to=0A= point out.=0A= =0A= The looking at these drafts, they are neither a proposal for what to=0A= actually do. Dan Wing's draft is argument in general why SDES would be=0A= bad for security. Oscar Ohlsson's is an argument for why a number of=0A= potential risks are not a serious issue and what the other gains of=0A= using security descriptions are.=0A= =0A= >From my perspective I really would like to see some progress in at least=0A= the proposal for actually adding additional keying to ensure that the=0A= raised issues in drafts or earlier WG meetings and email discussions are=0A= meet. Additionally I would really like to see some more details for how=0A= the actual integration of an additional keying mechanism is supposed to=0A= work.=0A= =0A= =0A= >=0A= > I think the problem must be that those things weren't signed in=0A= > triplicate, sent in, sent back, queried, lost, found, subjected to=0A= > public enquiry, lost again, and finally buried in soft peat for three=0A= > months and recycled as firelighters.=0A= =0A= No, that is not it. This topic has dragged on for various reasons. Yes=0A= we chairs are clearly to blame for some of them, like being slow to=0A= attempt to schedule a meeting. However, after that there has been issues=0A= finding a suitable time where sufficient mass of people could=0A= participate. There has been time conflicts with other meetings resulting=0A= in a cancellation, which in hind sight was unnecessary. Then a=0A= rescheduling, lurk warm response from the WG, limited agenda items and=0A= another almost collision resulting another cancellation.=0A= =0A= I am sorry that this makes you frustrated. Well, it makes also me=0A= frustrated. I wished this topic was dealt with and out of the way, but=0A= it is not. So, if you want it dealt with. Please request agenda time for=0A= Berlin and ensure to update any drafts or other material to actually=0A= take into account what actually has happened in the last 15 months.=0A= =0A= Regards=0A= =0A= Magnus Westerlund=0A= =0A= ----------------------------------------------------------------------=0A= Multimedia Technologies, Ericsson Research EAB/TVM=0A= ----------------------------------------------------------------------=0A= Ericsson AB | Phone +46 10 7148287=0A= F=E4r=F6gatan 6 | Mobile +46 73 0949079=0A= SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com=0A= ----------------------------------------------------------------------=0A= =0A= _______________________________________________=0A= rtcweb mailing list=0A= rtcweb@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rtcweb=0A= =0A= From mjordan@digium.com Tue Jun 18 12:19:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C5321E80A8 for ; Tue, 18 Jun 2013 12:19:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKHoYfogDBcJ for ; Tue, 18 Jun 2013 12:19:16 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABE521E8092 for ; Tue, 18 Jun 2013 12:19:15 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id t13so4027595lbd.15 for ; Tue, 18 Jun 2013 12:19:14 -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 :content-type:x-gm-message-state; bh=rbYH77nXpwm7SNyYzIa0T8BqkmHquDD4iFbe0fWH8OI=; b=W6rRPYpzZA8ijXsdgk5h8kvMKPDXP9hjZHhH7KNUQlNsVqRpNHGyoAtfY8lI8sG8tg FNCjt2sPlPxg1qqvOlH6ZRyhSv1M/uPZmwys5h32/9p94dQbRTUzdXIuJf0XXF+tRLAV 6kRBol9aeBtb9TZPuBfkNHWgCo7SZY6AuYnW1wl1/qyrk2GJhlH3oHYCFoeStBPuCsNm +Vb8FL5sgzCW7VUnDIEiq+ytRTvIAvW+ckCCuw0XKGFbUfpV/sO32fo6JcIXJLn8QNuH xnhVr5QhbcCiwn0cC6e8ipw7n7cXlCFTMc0x0GS3PHOd6cc8swPZJSpAq7DZ1mi9Duf6 gXWA== MIME-Version: 1.0 X-Received: by 10.112.154.170 with SMTP id vp10mr1743907lbb.11.1371583154211; Tue, 18 Jun 2013 12:19:14 -0700 (PDT) Received: by 10.112.180.234 with HTTP; Tue, 18 Jun 2013 12:19:14 -0700 (PDT) In-Reply-To: References: <5158F0FC.3070104@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02B56F@FR711WXCHMBA02.zeu.alcatel-lucent.com> <5165CF9D.6030302@jesup.org> Date: Tue, 18 Jun 2013 14:19:14 -0500 Message-ID: From: Matthew Jordan To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e01161a44afd40f04df729673 X-Gm-Message-State: ALoCoQmrjCKJp8uIhKhejQLnlDQwpCFlQXpAmgSfIcv7myeaabwOloTy1Rar3qZz7IBt3bd4fICu Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 19:19:23 -0000 --089e01161a44afd40f04df729673 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 18, 2013 at 1:22 PM, Adrian Georgescu wrote: > +1 > > While working with the specs, some may have realised that SDP is not such > a great idea to put in practice and may also want to come forward to admit > their mistake. > > Regards, > Adrian > > In the Asterisk project, we were able to use our legacy SIP stack to enable very basic WebRTC communication with Chrome and FireFox. That sounds nice, until you realize we have to continually preface that with "sometimes". Because the answer is, more often than not, something breaks. Invariably, the breakages have been in the SDPs sent to Asterisk by the browser. What SDP breaks us changes depending on the browser being used, the version of said browser, and whether or not some new WebRTC SDP feature has been put in the browser's latest release. And just when we think we have to modify Asterisk to handle the new SDP sent by some browser, the browser changes again. As a result, Asterisk 11 hasn't changed a lot since we released; we've been trying to avoid coding to a moving target. We always envisioned that things would quiet down and the browsers would settle on an implementation of SDP that we could adapt to - but it doesn't seem like things are quieting down as much as we'd like. And sure, the SIP stack in Asterisk is crufty, and sure, sometimes the fault is in our implementation, not the browser's - but I think we on the Asterisk project can certainly say that relying on SDP hasn't been a panacea for interoperability. It feels like maintaining compatibility with "traditional" SDP implementations is getting harder for the browsers to manage and holding the entire process back. As one of those older "traditional" implementations, I'd rather write an entirely new channel driver for Asterisk than have to re-write our SDP handling. So... +1 to Inaki's request. Matt -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org --089e01161a44afd40f04df729673 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    = On Tue, Jun 18, 2013 at 1:22 PM, Adrian Georgescu <ag@ag-projects.com= > wrote:
    +1

    While working with the specs, some may have realised that SDP is not such a= great idea to put in practice and may also want to come forward to admit t= heir mistake.

    Regards,
    Adrian


    In the Asterisk project, we were able to use our legacy SIP stack t= o enable very basic WebRTC communication with Chrome and FireFox. That soun= ds nice, until you realize we have to continually preface that with "s= ometimes".

    Because the answer is, more often tha= n not, something breaks. Invariably, the breakages have been in the SDPs se= nt to Asterisk by the browser. What SDP breaks us changes depending on the = browser being used, the version of said browser, and whether or not some ne= w WebRTC SDP feature has been put in the browser's latest release. And = just when we think we have to modify Asterisk to handle the new SDP sent by= some browser, the browser changes again. As a result, Asterisk 11 hasn'= ;t changed a lot since we released; we've been trying to avoid coding t= o a moving target. We always envisioned that things would quiet down and th= e browsers would settle on an implementation of SDP that we could adapt to = - but it doesn't seem like things are quieting down as much as we'd= like. And sure, the SIP stack in Asterisk is crufty, and sure, sometimes t= he fault is in our implementation, not the browser's - but I think we o= n the Asterisk project can certainly say that relying on SDP hasn't bee= n a panacea for interoperability.

    It feels like maintaining compatibility wit= h "traditional" SDP implementations is getting harder for the bro= wsers to manage and holding the entire process back. As one of those older = "traditional" implementations, I'd rather write an entirely n= ew channel driver for Asterisk than have to re-write our SDP handling.

    So... +1 to Inaki's request.

    Matt

    --
    Matthew Jordan
    Digium, Inc. | Engineering Manag= er
    445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
    --089e01161a44afd40f04df729673-- From rlb@ipv.sx Tue Jun 18 12:32:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E7221E805D for ; Tue, 18 Jun 2013 12:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyzCEROIYuZL for ; Tue, 18 Jun 2013 12:32:02 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4F411E8106 for ; Tue, 18 Jun 2013 12:32:02 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id g12so5424982oah.39 for ; Tue, 18 Jun 2013 12:32:01 -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:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=nOC30r3vI4NeWrPa+UsZPVf6GnhcJtwtCpwCPQW6Le0=; b=ZxlMkuiUq70PW0/wpFjBBrDTP/BathSix3DnB6kvR6HBAYysA9V0cmwOPYZRgKN4as RMLef6gZXZ5csp9G4jQ2i7+jbrdNnWLYiEohOx+i/O1CfRMrhPKI5xgNkElw4zSHkRCU gW2eAchhB/MtOIz6PyUrGRgJoshjxdVnp+YmviTcKgV41/UvWcsaYZ7vj4dsLeU+w8qx STOvi1BXgCLVwMQe69PtOCpboJod+wHPc6rys3mKyJTjSSETpgoezNvi4haWc1es1UkL xUxETRi4U1X1NF1K/t2Ho0vFVVyXwA9KhNQhzrd2aZGwLKg5ZEx3OfFpOgQ/hCZgk+Rb ZWRQ== MIME-Version: 1.0 X-Received: by 10.60.52.15 with SMTP id p15mr12878063oeo.87.1371583921719; Tue, 18 Jun 2013 12:32:01 -0700 (PDT) Received: by 10.60.26.135 with HTTP; Tue, 18 Jun 2013 12:32:01 -0700 (PDT) X-Originating-IP: [128.33.85.80] In-Reply-To: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> Date: Tue, 18 Jun 2013 15:32:01 -0400 Message-ID: From: Richard Barnes To: "Matthew Kaufman (SKYPE)" Content-Type: multipart/alternative; boundary=001a113309ce6f19f104df72c48e X-Gm-Message-State: ALoCoQnQDn80uyre8THIq2ziX8Y4lozwmpeW4c+dg7KwWjR5RYbfEKFJi5aYdDfsfD+ifLyBIf1u Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 19:32:06 -0000 --001a113309ce6f19f104df72c48e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman (SKYPE) < matthew.kaufman@skype.net> wrote: > Back on April 25th, I made some claims. I still believe these are true: > > 1. DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it is > just a different encrypted channel over which the key is set. > Could you explain this in a little more detail? I agree that the COMSEC properties are the same, but it seems like the communicating parties are different. DTLS-SRTP+EKT: Browser ---(EKT)---> Gateway ---(SDES)---> Endpoint SDES+HTTPS: Browser ---(HTTPS)---> Server ---(???)---> Gateway ---(SDES)---> Endpoint That is, in the DTLS-SRTP+EKT case, the key never traverses the server. Does your argument require that the server and the gateway be equally trusted? (For example, because the server can choose the gateway.) It doesn't seem like this is necessarily true in the general case. --Richard > 2. DTLS-SRTP w/EKT requires a more complex media gateway relationship for > interworking (as it needs to be in-path for the keying on that side, > despite the use of SDES on the other side). > > 3. DTLS-SRTP w/EKT for interworking exposes the key via SDES on the other > side of the interworking relationship anyway, so even though there isn't > SDES to the browser there's SDES on the other (likely SIP) side. > > 4. And DTLS-SRTP without EKT fails completely for the cases where the key > needs to be set for interworking. > > 5. And finally, to get the browser-to-browser security guarantees you > would need to be A) sure that you're really talking browser to browser an= d > not via something else in path (like a mixer) and B) would really prefer > that there be no way that the in-path device be able to force a key (thus > you'd want to NOT allow EKT in the browser-to-browser case, even though > there's no way for a browser to know for sure what it is talking to... I > suppose that *if* you trusted your browser and the browser at the other e= nd > (which you need to do anyway, because they could just leak keys or media)= , > you could mandate that browsers set some bit that disallows EKT and hope > that the other end respects it) > > > Since we can't get interworking at all without either DTLS-SRTP + EKT or > SDES, and since the security guarantees of DTLS-SRTP + EKT are the same a= s > those of SDES, and since the interworking gateway is made more complex > (because the keying must be in-path), I believe the only possible > conclusions are A) We accept that interworking with other SRTP systems is > desirable and therefore SDES is the best way to achieve that or B) We > prevent any interworking with other RTP or SRTP systems. > > As someone who could make some money sending traffic to/from non-RTCWEB > networks, I'm a fan of "A". > > And no, I'm not planning on writing a draft that says to just do what we > should be doing anyway. > > Matthew Kaufman > > > ________________________________________ > From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of > Magnus Westerlund [magnus.westerlund@ericsson.com] > Sent: Tuesday, June 18, 2013 2:56 AM > To: Hadriel Kaplan > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] No Interim on SDES at this juncture > > Hadirel and WG, > > Please see my response inline. > > On 2013-06-14 18:58, Hadriel Kaplan wrote: > > You can't be serious. There was exactly ONE email asking for agenda > > items, here: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html It > > was sent on May 30th. It gave a generous 6 days to respond. Luckily > > no one ever goes on vacation for longer than 5 days. Instead, two > > people sent a response on June 10th, a tremendous 11 days after the > > request. Outrageous! That's a almost twice as long as they were > > given! > > > > Thank goodness the chairs detected this monstrous breach of > > procedure, and thwarted the attempts of anarchy! I mean if people > > are allowed to respond to emails so tardily, how can we be expected > > to get things accomplished as quickly as they've so far been in this > > WG?!? > > Yes, we have only sent a single email this time, being the second round > in a short time we tried to schedule this meeting. > > > > > Sure, an interim for this topic has been waiting for many months if > > not a whole year, and now that people didn't respond in 6 days but > > took instead 11 days the topic will be delayed indefinitely yet > > again... but that's no excuse for blatantly flaunting the rules! > > Yes, there has been difficult finding a time could work for this > meeting. That was why the agenda request time was short. > > > > > Personally I saw the email on May 30th, and assumed Oscar and Dan > > would respond to you for agenda time. I assumed that if no one had > > submitted agenda items to you, that the WG Chairs would send out an > > email warning about that, or perhaps even directly email the people > > who they expected to submit agenda items. > > > > Yes, you assumed that someone would respond. Rather than you reaching > out to verify that others would drive the question for you. Hadriel you > are apparently very interested in this topic. Why don't you ensure that > an agenda topic is on the agenda for Berlin? The WG chairs are happy to > receive agenda requests already now. > > > > >> If you want to discuss this, write a draft describing how how your > >> additional keying is to be integrated, what the pro and cons of it. > >> That will enable direct discussion of a proposal. The WG clearly > >> are opinionated on this matter, but apparently don't have energy to > >> produce proposals. > > > > There *are* drafts. > > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00 > > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 There > > are even powerpoint slides, sent to the chairs the last time this > > meeting almost happened but didn't. > > One of those drafts has been expired since February I would like to > point out. > > The looking at these drafts, they are neither a proposal for what to > actually do. Dan Wing's draft is argument in general why SDES would be > bad for security. Oscar Ohlsson's is an argument for why a number of > potential risks are not a serious issue and what the other gains of > using security descriptions are. > > From my perspective I really would like to see some progress in at least > the proposal for actually adding additional keying to ensure that the > raised issues in drafts or earlier WG meetings and email discussions are > meet. Additionally I would really like to see some more details for how > the actual integration of an additional keying mechanism is supposed to > work. > > > > > > I think the problem must be that those things weren't signed in > > triplicate, sent in, sent back, queried, lost, found, subjected to > > public enquiry, lost again, and finally buried in soft peat for three > > months and recycled as firelighters. > > No, that is not it. This topic has dragged on for various reasons. Yes > we chairs are clearly to blame for some of them, like being slow to > attempt to schedule a meeting. However, after that there has been issues > finding a suitable time where sufficient mass of people could > participate. There has been time conflicts with other meetings resulting > in a cancellation, which in hind sight was unnecessary. Then a > rescheduling, lurk warm response from the WG, limited agenda items and > another almost collision resulting another cancellation. > > I am sorry that this makes you frustrated. Well, it makes also me > frustrated. I wished this topic was dealt with and out of the way, but > it is not. So, if you want it dealt with. Please request agenda time for > Berlin and ensure to update any drafts or other material to actually > take into account what actually has happened in the last 15 months. > > Regards > > 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 > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113309ce6f19f104df72c48e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman (SKYPE) <= span dir=3D"ltr"><matthew.kaufman@skype.net> wrote:
    Back on April 25t= h, I made some claims. I still believe these are true:

    1. DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it is ju= st a different encrypted channel over which the key is set.

    Could you explain this in a little more detail? =A0I a= gree that the COMSEC properties are the same, but it seems like the communi= cating parties are different.

    DTLS-SRTP+EKT: =A0Browser ---(EKT)---> Gateway ---(S= DES)---> Endpoint
    SDES+HTTPS: Browser ---(HTTPS)---> Server= ---(???)---> Gateway ---(SDES)---> Endpoint

    That is, in the DTLS-SRTP+EKT case, the key never traverses the server. =A0= Does your argument require that the server and the gateway be equally trust= ed? =A0(For example, because the server can choose the gateway.) =A0It does= n't seem like this is necessarily true in the general case. =A0

    --Richard

    =A0
    2. DTLS-SRTP w/EKT requires a more complex media gateway relationship for i= nterworking (as it needs to be in-path for the keying on that side, despite= the use of SDES on the other side).

    3. DTLS-SRTP w/EKT for interworking exposes the key via SDES on the other s= ide of the interworking relationship anyway, so even though there isn't= SDES to the browser there's SDES on the other (likely SIP) side.

    4. And DTLS-SRTP without EKT fails completely for the cases where the key n= eeds to be set for interworking.

    5. And finally, to get the browser-to-browser security guarantees you would= need to be A) sure that you're really talking browser to browser and n= ot via something else in path (like a mixer) and B) would really prefer tha= t there be no way that the in-path device be able to force a key (thus you&= #39;d want to NOT allow EKT in the browser-to-browser case, even though the= re's no way for a browser to know for sure what it is talking to... I s= uppose that *if* you trusted your browser and the browser at the other end = (which you need to do anyway, because they could just leak keys or media), = you could mandate that browsers set some bit that disallows EKT and hope th= at the other end respects it)


    Since we can't get interworking at all without either DTLS-SRTP + EKT o= r SDES, and since the security guarantees of DTLS-SRTP + EKT are the same a= s those of SDES, and since the interworking gateway is made more complex (b= ecause the keying must be in-path), I believe the only possible conclusions= are A) We accept that interworking with other SRTP systems is desirable an= d therefore SDES is the best way to achieve that or B) We prevent any inter= working with other RTP or SRTP systems.

    As someone who could make some money sending traffic to/from non-RTCWEB net= works, I'm a fan of "A".

    And no, I'm not planning on writing a draft that says to just do what w= e should be doing anyway.

    Matthew Kaufman


    ________________________________________
    From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] = on behalf of Magnus Westerlund [magnus.westerlund@ericsson.com]
    Sent: Tuesday, June 18, 2013 2:56 AM
    To: Hadriel Kaplan
    Cc: rtcweb@ietf= .org
    Subject: Re: [rtcweb] No Interim on SDES at this juncture

    Hadirel and WG,

    Please see my response inline.

    On 2013-06-14 18:58, Hadriel Kaplan wrote:
    > You can't be serious. There was exactly ONE email asking for agend= a
    > items, here:
    > http://www.ietf.org/mail-archive/web/rtcweb/curre= nt/msg07668.html It
    > was sent on May 30th. =A0It gave a generous 6 days to respond. =A0Luck= ily
    > no one ever goes on vacation for longer than 5 days. Instead, two
    > people sent a response on June 10th, a tremendous 11 days after the > request. =A0Outrageous! =A0That's a almost twice as long as they w= ere
    > given!
    >
    > Thank goodness the chairs detected this monstrous breach of
    > procedure, and thwarted the attempts of anarchy! =A0I mean if people > are allowed to respond to emails so tardily, how can we be expected > to get things accomplished as quickly as they've so far been in th= is
    > WG?!?

    Yes, we have only sent a single email this time, being the second round
    in a short time we tried to schedule this meeting.

    >
    > Sure, an interim for this topic has been waiting for many months if > not a whole year, and now that people didn't respond in 6 days but=
    > took instead 11 days the topic will be delayed indefinitely yet
    > again... but that's no excuse for blatantly flaunting the rules!
    Yes, there has been difficult finding a time could work for this
    meeting. That was why the agenda request time was short.

    >
    > Personally I saw the email on May 30th, and assumed Oscar and Dan
    > would respond to you for agenda time. =A0I assumed that if no one had<= br> > submitted agenda items to you, that the WG Chairs would send out an > email warning about that, or perhaps even directly email the people > who they expected to submit agenda items.
    >

    Yes, you assumed that someone would respond. Rather than you reaching
    out to verify that others would drive the question for you. Hadriel you
    are apparently very interested in this topic. Why don't you ensure that=
    an agenda topic is on the agenda for Berlin? The WG chairs are happy to
    receive agenda requests already now.

    >
    >> If you want to discuss this, write a draft describing how how your=
    >> additional keying is to be integrated, what the pro and cons of it= .
    >> That will enable direct discussion of a proposal. The WG clearly >> are opinionated on this matter, but apparently don't have ener= gy to
    >> produce proposals.
    >
    > There *are* drafts.
    > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-pro= blems-00
    > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sde= s-support-01 There
    > are even powerpoint slides, sent to the chairs the last time this
    > meeting almost happened but didn't.

    One of those drafts has been expired since February I would like to
    point out.

    The looking at these drafts, they are neither a proposal for what to
    actually do. Dan Wing's draft is argument in general why SDES would be<= br> bad for security. Oscar Ohlsson's is an argument for why a number of potential risks are not a serious issue and what the other gains of
    using security descriptions are.

    >From my perspective I really would like to see some progress in at least the proposal for actually adding additional keying to ensure that the
    raised issues in drafts or earlier WG meetings and email discussions are meet. Additionally I would really like to see some more details for how
    the actual integration of an additional keying mechanism is supposed to
    work.


    >
    > I think the problem must be that those things weren't signed in > triplicate, sent in, sent back, queried, lost, found, subjected to
    > public enquiry, lost again, and finally buried in soft peat for three<= br> > months and recycled as firelighters.

    No, that is not it. This topic has dragged on for various reasons. Yes
    we chairs are clearly to blame for some of them, like being slow to
    attempt to schedule a meeting. However, after that there has been issues finding a suitable time where sufficient mass of people could
    participate. There has been time conflicts with other meetings resulting in a cancellation, which in hind sight was unnecessary. Then a
    rescheduling, lurk warm response from the WG, limited agenda items and
    another almost collision resulting another cancellation.

    I am sorry that this makes you frustrated. Well, it makes also me
    frustrated. I wished this topic was dealt with and out of the way, but
    it is not. So, if you want it dealt with. Please request agenda time for Berlin and ensure to update any drafts or other material to actually
    take into account what actually has happened in the last 15 months.

    Regards

    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

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

    --001a113309ce6f19f104df72c48e-- From ted.ietf@gmail.com Tue Jun 18 13:15:16 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A1021F9C90 for ; Tue, 18 Jun 2013 13:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLlMjx6DBlFq for ; Tue, 18 Jun 2013 13:15:16 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DE1F921F9C14 for ; Tue, 18 Jun 2013 13:15:15 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e11so11511762iej.29 for ; Tue, 18 Jun 2013 13:15:12 -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=REKJAPvSUTgCLIBB4RhIVzLu9ssPT9yhOXFA7RulSxQ=; b=zLw4TBBsYYEIBCnmGxHkEz3zrzIqDkGIxPstjxkF/Oby50GBNF384V5NU9GdF8ijE0 +M42FioqhhGAIFuRfZeYV7AARFAeWxEeetPJIVhkBik7Bpfz74SV8F+ZwhdZrn/iEFmk B5hxKZXk2EUYcXdWWrfzhnro7Chdp5+anmqIul9xV4eg1S6FB+mCQN03VOXL7epjDJFr Lrg4kJ8z+JIMzYsyeoDyw9L1a5JnalyvJ1x2jpGkdIJ34AvXL2qWe8d3BzIRxnm4793u Eyg59dYriPG5hynBZByk1pOWq5w3tVbcBXlduj0wxBHYfPjmli4ge9pqKif35C5F6NpE 0zLw== MIME-Version: 1.0 X-Received: by 10.50.17.166 with SMTP id p6mr8526750igd.12.1371586512778; Tue, 18 Jun 2013 13:15:12 -0700 (PDT) Received: by 10.42.49.7 with HTTP; Tue, 18 Jun 2013 13:15:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Jun 2013 13:15:12 -0700 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=14dae9340cc9df85c004df735e30 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:15:16 -0000 --14dae9340cc9df85c004df735e30 Content-Type: text/plain; charset=ISO-8859-1 I've read the messages on this thread up to lunchtime in California on June 18th. I have not consulted with the other chairs, because we are still somewhat out of synch, so this is my personal response, rather than a chair response. SDP occurs as an API control surface in this protocol, and it may also be used in O/A semantics between endpoints. The request does not clearly state which aspect is asking for reconsideration. Since one is handled in a different group, that is critical. Secondly, the requirement the group has is that the solution *provides support sufficient to allow O/A semantics*, not that these must be used between two parties using the same signalling. Being clear on what you would like to see by writing a draft proposal, rather than simply asking to re-open concluded discussions would be helpful. Speaking very personally, I would like to see the group close having completed its milestones. While I am very aware that re-using a syntax like SDP makes for some unpleasant moments, I'm not sure that any system that actual has any level of interoperability with existing SIP deployments as a goal will avoid that unpleasantness--at best, you have a mechanism on one end that looks different *but must be mapped to SDP* in the interoperability case. Creating something new that accomplishes that and is substantially better than SDP seems like a long task to me. Again, not as a chair decision or statement, but to give some response to the points made. regards, Ted Hardie --14dae9340cc9df85c004df735e30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've read the messages on this thread up to lunchtime in California on = June 18th.=A0 I have not consulted with the other chairs, because we are st= ill somewhat out of synch, so this is my personal response, rather than a c= hair response.

    SDP occurs as an API control surface in this protocol, and it may also = be used in O/A semantics between endpoints.=A0 The request does not clearly= state which aspect is asking for reconsideration.=A0 Since one is handled = in a different group, that is critical.=A0 Secondly, the requirement the gr= oup has is that the solution *provides support sufficient to allow O/A sema= ntics*, not that these must be used between two parties using the same sign= alling.=A0=A0 Being clear on what you would like to see by writing a draft = proposal, rather than simply asking to re-open concluded discussions would = be helpful.

    Speaking very personally, I would like to see the group close having co= mpleted its milestones.=A0 While I am very aware that re-using a syntax lik= e SDP makes for some unpleasant moments, I'm not sure that any system t= hat actual has any level of interoperability with existing SIP deployments = as a goal will avoid that unpleasantness--at best, you have a mechanism on = one end that looks different *but must be mapped to SDP* in the interoperab= ility case.=A0=A0 Creating something new that accomplishes that and is subs= tantially better than SDP seems like a long task to me.=A0

    Again, not as a chair decision or statement, but to give some response = to the points made.

    regards,

    Ted Hardie
    --14dae9340cc9df85c004df735e30-- From adam@nostrum.com Tue Jun 18 13:23:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639A821E8092 for ; Tue, 18 Jun 2013 13:23:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZ9WGH+8J5Ny for ; Tue, 18 Jun 2013 13:23:27 -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 D375E11E80E3 for ; Tue, 18 Jun 2013 13:23:01 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r5IKMuJZ064639 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 18 Jun 2013 15:22:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51C0C1A0.9010107@nostrum.com> Date: Tue, 18 Jun 2013 15:22:56 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ted Hardie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:23:28 -0000 On 6/18/13 15:15, Ted Hardie wrote: > Creating something new that accomplishes that and is substantially > better than SDP seems like a long task to me. Many men have died on that hill. I'm still sad about the colossal time and talent sink represented by these 61 pages: http://tools.ietf.org/id/draft-ietf-mmusic-sdpng-08.txt I have no reason to think that burning WebRTC down the the ground and starting over would produce a different result. If anything, the issues are more contentious now than they were in 2005. /a From matthew.kaufman@skype.net Tue Jun 18 13:56:36 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EDA11E8100 for ; Tue, 18 Jun 2013 13:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y42lqbmEA9oO for ; Tue, 18 Jun 2013 13:56:29 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF6B21E8054 for ; Tue, 18 Jun 2013 13:56:29 -0700 (PDT) Received: from BN1BFFO11FD002.protection.gbl (10.58.52.201) by BN1BFFO11HUB005.protection.gbl (10.58.53.115) with Microsoft SMTP Server (TLS) id 15.0.707.0; Tue, 18 Jun 2013 20:56:26 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD002.mail.protection.outlook.com (10.58.53.62) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 18 Jun 2013 20:56:26 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.171]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Tue, 18 Jun 2013 20:56:09 +0000 From: "Matthew Kaufman (SKYPE)" To: Ted Hardie , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Thread-Index: AQHObEI8XC7enqULikaWynaBYkCsupk76I4AgAAJ1AA= Date: Tue, 18 Jun 2013 20:56:08 +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.33] Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7D79TK5EX14MBXC273r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(377454002)(31966008)(54356001)(74366001)(76786001)(77096001)(561944002)(69226001)(81342001)(66066001)(81542001)(74706001)(63696002)(49866001)(74502001)(65816001)(46102001)(47446002)(512934002)(56776001)(51856001)(74662001)(74876001)(55846006)(79102001)(50986001)(77982001)(76796001)(76482001)(33656001)(47976001)(56816003)(16406001)(6806003)(54316002)(20776003)(80022001)(59766001)(71186001)(53806001)(47736001)(4396001)(16236675002); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB005; H:TK5EX14HUBC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0881A7A935 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:56:36 -0000 --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7D79TK5EX14MBXC273r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The good news is that I co-authored and Microsoft published a nice starting= point for discussing a specification that doesn't have SDP O/A. The bad news is that it was voted down for future consideration at W3C. The good news is that W3C has apparently abdicated the entire responsibilit= y for producing a browser API to IETF, where it has not yet been voted down= . More good news is that if and when the W3C considers the current specificat= ion that the IETF produces, if it is not complete enough to independently r= eplicate without looking at other browser's source code (in other words, if= the SDP that is produced is not fully specified in an interoperable way in= either the W3C specification itself or, worst case, in the entire stack of= normative references), I will also have the pleasure of co-authoring a for= mal objection to publishing that specification. One might consider that since the current SDP-based path we are on does not= have anywhere near a complete set of implementable normative references, a= nd that producing such might actually be harder than using something that d= oesn't rely on SDP as the API surface, you might be a lot farther from some= thing that finishes the entire W3C process than you think. Matthew Kaufman ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Ted Ha= rdie [ted.ietf@gmail.com] Sent: Tuesday, June 18, 2013 1:15 PM To: I=F1aki Baz Castillo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened I've read the messages on this thread up to lunchtime in California on June= 18th. I have not consulted with the other chairs, because we are still so= mewhat out of synch, so this is my personal response, rather than a chair r= esponse. SDP occurs as an API control surface in this protocol, and it may also be u= sed in O/A semantics between endpoints. The request does not clearly state= which aspect is asking for reconsideration. Since one is handled in a dif= ferent group, that is critical. Secondly, the requirement the group has is= that the solution *provides support sufficient to allow O/A semantics*, no= t that these must be used between two parties using the same signalling. = Being clear on what you would like to see by writing a draft proposal, rath= er than simply asking to re-open concluded discussions would be helpful. Speaking very personally, I would like to see the group close having comple= ted its milestones. While I am very aware that re-using a syntax like SDP = makes for some unpleasant moments, I'm not sure that any system that actual= has any level of interoperability with existing SIP deployments as a goal = will avoid that unpleasantness--at best, you have a mechanism on one end th= at looks different *but must be mapped to SDP* in the interoperability case= . Creating something new that accomplishes that and is substantially bett= er than SDP seems like a long task to me. Again, not as a chair decision or statement, but to give some response to t= he points made. regards, Ted Hardie --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7D79TK5EX14MBXC273r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    The good news is that I co-authored and Microsoft published a nice sta= rting point for discussing a specification that doesn't have SDP O/A.

    The bad news is that it was voted down for future consideration at W3C= .

    The good news is that W3C has apparently abdicated the entire responsi= bility for producing a browser API to IETF, where it has not yet been voted= down.

    More good news is that if and when the W3C considers the current speci= fication that the IETF produces, if it is not complete enough to independen= tly replicate without looking at other browser's source code (in other word= s, if the SDP that is produced is not fully specified in an interoperable way in either the W3C specificatio= n itself or, worst case, in the entire stack of normative references), I wi= ll also have the pleasure of co-authoring a formal objection to publishing = that specification.

    One might consider that since the current SDP-based path we are on doe= s not have anywhere near a complete set of implementable normative referenc= es, and that producing such might actually be harder than using something t= hat doesn't rely on SDP as the API surface, you might be a lot farther from something that finishes the entir= e W3C process than you think.

    Matthew Kaufman

    From: rtcweb-bounces@ietf.org [rtcweb-bou= nces@ietf.org] on behalf of Ted Hardie [ted.ietf@gmail.com]
    Sent: Tuesday, June 18, 2013 1:15 PM
    To: I=F1aki Baz Castillo
    Cc: rtcweb@ietf.org
    Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate t= o be re-opened

    I've read the messages on this thread up to lunchtime in California on= June 18th.  I have not consulted with the other chairs, because we ar= e still somewhat out of synch, so this is my personal response, rather than= a chair response.

    SDP occurs as an API control surface in this protocol, and it may also be u= sed in O/A semantics between endpoints.  The request does not clearly = state which aspect is asking for reconsideration.  Since one is handle= d in a different group, that is critical.  Secondly, the requirement the group has is that the solution *provides sup= port sufficient to allow O/A semantics*, not that these must be used betwee= n two parties using the same signalling.   Being clear on what yo= u would like to see by writing a draft proposal, rather than simply asking to re-open concluded discussions would be helpfu= l.

    Speaking very personally, I would like to see the group close having comple= ted its milestones.  While I am very aware that re-using a syntax like= SDP makes for some unpleasant moments, I'm not sure that any system that a= ctual has any level of interoperability with existing SIP deployments as a goal will avoid that unpleasantness--at= best, you have a mechanism on one end that looks different *but must be ma= pped to SDP* in the interoperability case.   Creating something n= ew that accomplishes that and is substantially better than SDP seems like a long task to me. 

    Again, not as a chair decision or statement, but to give some response to t= he points made.

    regards,

    Ted Hardie
    --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7D79TK5EX14MBXC273r_-- From matthew.kaufman@skype.net Tue Jun 18 14:16:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D604B21E808E for ; Tue, 18 Jun 2013 14:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Udl4W1+v3R6X for ; Tue, 18 Jun 2013 14:16:52 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2B35811E80F9 for ; Tue, 18 Jun 2013 14:16:51 -0700 (PDT) Received: from BY2FFO11FD022.protection.gbl (10.1.15.203) by BY2FFO11HUB014.protection.gbl (10.1.14.86) with Microsoft SMTP Server (TLS) id 15.0.707.0; Tue, 18 Jun 2013 21:16:50 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD022.mail.protection.outlook.com (10.1.15.211) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 18 Jun 2013 21:16:50 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.171]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0136.001; Tue, 18 Jun 2013 21:16:39 +0000 From: "Matthew Kaufman (SKYPE)" To: Richard Barnes Thread-Topic: [rtcweb] No Interim on SDES at this juncture Thread-Index: AQHOZrw6CQcaVcHO7ESUEcTH2Hsm5ZkxWrGAgADdvYCAAA4GAIACkewAgACbDYCABdNvAIAAlhWIgAAKmICAABtrwA== Date: Tue, 18 Jun 2013 21:16:38 +0000 Message-ID: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> , 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.33] Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7EF8TK5EX14MBXC273r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(377424003)(51704005)(52314003)(189002)(24454002)(377454002)(16236675002)(46102001)(63696002)(80022001)(65816001)(50986001)(74502001)(74366001)(74876001)(76786001)(51856001)(16406001)(76796001)(15202345002)(71186001)(55846006)(59766001)(66066001)(81542001)(47446002)(4396001)(56776001)(54316002)(53806001)(69226001)(81342001)(77096001)(561944002)(74662001)(31966008)(6806003)(47736001)(47976001)(54356001)(56816003)(49866001)(76482001)(74706001)(512934002)(79102001)(44976003)(20776003)(33656001)(16297215003)(77982001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB014; H:TK5EX14HUBC107.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0881A7A935 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 21:16:59 -0000 --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7EF8TK5EX14MBXC273r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So lets assume the case where I have a web server that is talking to my bro= wser *and* generating SIP traffic to talk to your SDES-capable (and ICE-cap= able) PBX. And assume that your PBX initiated the call and picked the keying. So in the EKT case we have (for key flow): your PBX -(SDES in SIP)-> my server -(SDES in JSON in HTTPS)-> browser -(E= KT)-> a media relay i now need to run (for media): browser <--(key that was received over HTTPS and then sent using EKT)--> m= edia relay <--(key that was received via SDES)--> your pbx but in the SDES case we have (for key flow): your PBX -(SDES in SIP)-> my server -(SDES in SDP in HTTPS)-> browser (and= that's it, because I don't need a media relay in path any more) (for media): browser <--(key that was received over HTTPS at the browser, SDES in SDP o= n SIP side)--> your pbx Your diagram is missing the part where the browser either learns the key th= at it is supposed to ask EKT to set or tells your SIP/SDES side what key it= set using EKT. Either way, those keys go over HTTPS to/from the browser, y= es? Matthew Kaufman ________________________________ From: Richard Barnes [rlb@ipv.sx] Sent: Tuesday, June 18, 2013 12:32 PM To: Matthew Kaufman (SKYPE) Cc: Magnus Westerlund; Hadriel Kaplan; rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman (SKYPE) > wrote: Back on April 25th, I made some claims. I still believe these are true: 1. DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it is ju= st a different encrypted channel over which the key is set. Could you explain this in a little more detail? I agree that the COMSEC pr= operties are the same, but it seems like the communicating parties are diff= erent. DTLS-SRTP+EKT: Browser ---(EKT)---> Gateway ---(SDES)---> Endpoint SDES+HTTPS: Browser ---(HTTPS)---> Server ---(???)---> Gateway ---(SDES)---= > Endpoint That is, in the DTLS-SRTP+EKT case, the key never traverses the server. Do= es your argument require that the server and the gateway be equally trusted= ? (For example, because the server can choose the gateway.) It doesn't se= em like this is necessarily true in the general case. --Richard 2. DTLS-SRTP w/EKT requires a more complex media gateway relationship for i= nterworking (as it needs to be in-path for the keying on that side, despite= the use of SDES on the other side). 3. DTLS-SRTP w/EKT for interworking exposes the key via SDES on the other s= ide of the interworking relationship anyway, so even though there isn't SDE= S to the browser there's SDES on the other (likely SIP) side. 4. And DTLS-SRTP without EKT fails completely for the cases where the key n= eeds to be set for interworking. 5. And finally, to get the browser-to-browser security guarantees you would= need to be A) sure that you're really talking browser to browser and not v= ia something else in path (like a mixer) and B) would really prefer that th= ere be no way that the in-path device be able to force a key (thus you'd wa= nt to NOT allow EKT in the browser-to-browser case, even though there's no = way for a browser to know for sure what it is talking to... I suppose that = *if* you trusted your browser and the browser at the other end (which you n= eed to do anyway, because they could just leak keys or media), you could ma= ndate that browsers set some bit that disallows EKT and hope that the other= end respects it) Since we can't get interworking at all without either DTLS-SRTP + EKT or SD= ES, and since the security guarantees of DTLS-SRTP + EKT are the same as th= ose of SDES, and since the interworking gateway is made more complex (becau= se the keying must be in-path), I believe the only possible conclusions are= A) We accept that interworking with other SRTP systems is desirable and th= erefore SDES is the best way to achieve that or B) We prevent any interwork= ing with other RTP or SRTP systems. As someone who could make some money sending traffic to/from non-RTCWEB net= works, I'm a fan of "A". And no, I'm not planning on writing a draft that says to just do what we sh= ould be doing anyway. Matthew Kaufman ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounc= es@ietf.org] on behalf of Magnus Westerlund= [magnus.westerlund@ericsson.com] Sent: Tuesday, June 18, 2013 2:56 AM To: Hadriel Kaplan Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture Hadirel and WG, Please see my response inline. On 2013-06-14 18:58, Hadriel Kaplan wrote: > You can't be serious. There was exactly ONE email asking for agenda > items, here: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html It > was sent on May 30th. It gave a generous 6 days to respond. Luckily > no one ever goes on vacation for longer than 5 days. Instead, two > people sent a response on June 10th, a tremendous 11 days after the > request. Outrageous! That's a almost twice as long as they were > given! > > Thank goodness the chairs detected this monstrous breach of > procedure, and thwarted the attempts of anarchy! I mean if people > are allowed to respond to emails so tardily, how can we be expected > to get things accomplished as quickly as they've so far been in this > WG?!? Yes, we have only sent a single email this time, being the second round in a short time we tried to schedule this meeting. > > Sure, an interim for this topic has been waiting for many months if > not a whole year, and now that people didn't respond in 6 days but > took instead 11 days the topic will be delayed indefinitely yet > again... but that's no excuse for blatantly flaunting the rules! Yes, there has been difficult finding a time could work for this meeting. That was why the agenda request time was short. > > Personally I saw the email on May 30th, and assumed Oscar and Dan > would respond to you for agenda time. I assumed that if no one had > submitted agenda items to you, that the WG Chairs would send out an > email warning about that, or perhaps even directly email the people > who they expected to submit agenda items. > Yes, you assumed that someone would respond. Rather than you reaching out to verify that others would drive the question for you. Hadriel you are apparently very interested in this topic. Why don't you ensure that an agenda topic is on the agenda for Berlin? The WG chairs are happy to receive agenda requests already now. > >> If you want to discuss this, write a draft describing how how your >> additional keying is to be integrated, what the pro and cons of it. >> That will enable direct discussion of a proposal. The WG clearly >> are opinionated on this matter, but apparently don't have energy to >> produce proposals. > > There *are* drafts. > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00 > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 There > are even powerpoint slides, sent to the chairs the last time this > meeting almost happened but didn't. One of those drafts has been expired since February I would like to point out. The looking at these drafts, they are neither a proposal for what to actually do. Dan Wing's draft is argument in general why SDES would be bad for security. Oscar Ohlsson's is an argument for why a number of potential risks are not a serious issue and what the other gains of using security descriptions are. >From my perspective I really would like to see some progress in at least the proposal for actually adding additional keying to ensure that the raised issues in drafts or earlier WG meetings and email discussions are meet. Additionally I would really like to see some more details for how the actual integration of an additional keying mechanism is supposed to work. > > I think the problem must be that those things weren't signed in > triplicate, sent in, sent back, queried, lost, found, subjected to > public enquiry, lost again, and finally buried in soft peat for three > months and recycled as firelighters. No, that is not it. This topic has dragged on for various reasons. Yes we chairs are clearly to blame for some of them, like being slow to attempt to schedule a meeting. However, after that there has been issues finding a suitable time where sufficient mass of people could participate. There has been time conflicts with other meetings resulting in a cancellation, which in hind sight was unnecessary. Then a rescheduling, lurk warm response from the WG, limited agenda items and another almost collision resulting another cancellation. I am sorry that this makes you frustrated. Well, it makes also me frustrated. I wished this topic was dealt with and out of the way, but it is not. So, if you want it dealt with. Please request agenda time for Berlin and ensure to update any drafts or other material to actually take into account what actually has happened in the last 15 months. Regards 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 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7EF8TK5EX14MBXC273r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    So lets assume the case where I have a web server that is talking to= my browser *and* generating SIP traffic to talk to your SDES-capable (and = ICE-capable) PBX.

    And assume that your PBX initiated the call and picked the keying.

    So in the EKT case we have (for key flow):
     your PBX -(SDES in SIP)-> my server -(SDES in JSON in HTTPS)-= > browser -(EKT)-> a media relay i now need to run
    (for media):
     browser <--(key that was received over HTTPS and then sent us= ing EKT)--> media relay <--(key that was received via SDES)--> you= r pbx

    but in the SDES case we have (for key flow):
     your PBX -(SDES in SIP)-> my server -(SDES in SDP in HTTPS)-&= gt; browser (and that's it, because I don't need a media relay in path any = more)
    (for media):
     browser <--(key that was received over HTTPS at the browser, = SDES in SDP on SIP side)--> your pbx


    Your diagram is missing the part where the browser either learns the k= ey that it is supposed to ask EKT to set or tells your SIP/SDES side what k= ey it set using EKT. Either way, those keys go over HTTPS to/from the brows= er, yes?

    Matthew Kaufman
      
    From: Richard Barnes [rlb@ipv.sx]
    Sent: Tuesday, June 18, 2013 12:32 PM
    To: Matthew Kaufman (SKYPE)
    Cc: Magnus Westerlund; Hadriel Kaplan; rtcweb@ietf.org
    Subject: Re: [rtcweb] No Interim on SDES at this juncture

    On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman (SKYPE) <= span dir=3D"ltr"> <matthew.= kaufman@skype.net> wrote:
    Back on April 25th, I made some claims. I still believe these are true:

    1. DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it is ju= st a different encrypted channel over which the key is set.

    Could you explain this in a little more detail?  I agree that the= COMSEC properties are the same, but it seems like the communicating partie= s are different.

    DTLS-SRTP+EKT:  Browser ---(EKT)---> Gateway ---(SDES)---&= gt; Endpoint
    SDES+HTTPS: Browser ---(HTTPS)---> Server ---(???)---> Gatew= ay ---(SDES)---> Endpoint

    That is, in the DTLS-SRTP+EKT case, the key never traverses the se= rver.  Does your argument require that the server and the gateway be e= qually trusted?  (For example, because the server can choose the gatew= ay.)  It doesn't seem like this is necessarily true in the general case.  

    --Richard

     
    2. DTLS-SRTP w/EKT requires a more complex media gateway relationship for i= nterworking (as it needs to be in-path for the keying on that side, despite= the use of SDES on the other side).

    3. DTLS-SRTP w/EKT for interworking exposes the key via SDES on the other s= ide of the interworking relationship anyway, so even though there isn't SDE= S to the browser there's SDES on the other (likely SIP) side.

    4. And DTLS-SRTP without EKT fails completely for the cases where the key n= eeds to be set for interworking.

    5. And finally, to get the browser-to-browser security guarantees you would= need to be A) sure that you're really talking browser to browser and not v= ia something else in path (like a mixer) and B) would really prefer that th= ere be no way that the in-path device be able to force a key (thus you'd want to NOT allow EKT in the browser-to= -browser case, even though there's no way for a browser to know for sure wh= at it is talking to... I suppose that *if* you trusted your browser and the= browser at the other end (which you need to do anyway, because they could just leak keys or media), you co= uld mandate that browsers set some bit that disallows EKT and hope that the= other end respects it)


    Since we can't get interworking at all without either DTLS-SRTP + EKT o= r SDES, and since the security guarantees of DTLS-SRTP + EKT are the sa= me as those of SDES, and since the interworking gateway is made more comple= x (because the keying must be in-path), I believe the only possible conclusions are A) We accept that interworking= with other SRTP systems is desirable and therefore SDES is the best way to= achieve that or B) We prevent any interworking with other RTP or SRTP syst= ems.

    As someone who could make some money sending traffic to/from non-RTCWEB net= works, I'm a fan of "A".

    And no, I'm not planning on writing a draft that says to just do what we sh= ould be doing anyway.

    Matthew Kaufman


    ________________________________________
    From: rtcweb-b= ounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Magnus Westerlund [magnus.westerl= und@ericsson.com]
    Sent: Tuesday, June 18, 2013 2:56 AM
    To: Hadriel Kaplan
    Cc: rtcweb@ietf.org
    Subject: Re: [rtcweb] No Interim on SDES at this juncture

    Hadirel and WG,

    Please see my response inline.

    On 2013-06-14 18:58, Hadriel Kaplan wrote:
    > You can't be serious. There was exactly ONE email asking for agenda > items, here:
    > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html It > was sent on May 30th.  It gave a generous 6 days to respond. &nbs= p;Luckily
    > no one ever goes on vacation for longer than 5 days. Instead, two
    > people sent a response on June 10th, a tremendous 11 days after the > request.  Outrageous!  That's a almost twice as long as they= were
    > given!
    >
    > Thank goodness the chairs detected this monstrous breach of
    > procedure, and thwarted the attempts of anarchy!  I mean if peopl= e
    > are allowed to respond to emails so tardily, how can we be expected > to get things accomplished as quickly as they've so far been in this > WG?!?

    Yes, we have only sent a single email this time, being the second round
    in a short time we tried to schedule this meeting.

    >
    > Sure, an interim for this topic has been waiting for many months if > not a whole year, and now that people didn't respond in 6 days but
    > took instead 11 days the topic will be delayed indefinitely yet
    > again... but that's no excuse for blatantly flaunting the rules!

    Yes, there has been difficult finding a time could work for this
    meeting. That was why the agenda request time was short.

    >
    > Personally I saw the email on May 30th, and assumed Oscar and Dan
    > would respond to you for agenda time.  I assumed that if no one h= ad
    > submitted agenda items to you, that the WG Chairs would send out an > email warning about that, or perhaps even directly email the people > who they expected to submit agenda items.
    >

    Yes, you assumed that someone would respond. Rather than you reaching
    out to verify that others would drive the question for you. Hadriel you
    are apparently very interested in this topic. Why don't you ensure that
    an agenda topic is on the agenda for Berlin? The WG chairs are happy to
    receive agenda requests already now.

    >
    >> If you want to discuss this, write a draft describing how how your=
    >> additional keying is to be integrated, what the pro and cons of it= .
    >> That will enable direct discussion of a proposal. The WG clearly >> are opinionated on this matter, but apparently don't have energy t= o
    >> produce proposals.
    >
    > There *are* drafts.
    > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00
    > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 There > are even powerpoint slides, sent to the chairs the last time this
    > meeting almost happened but didn't.

    One of those drafts has been expired since February I would like to
    point out.

    The looking at these drafts, they are neither a proposal for what to
    actually do. Dan Wing's draft is argument in general why SDES would be
    bad for security. Oscar Ohlsson's is an argument for why a number of
    potential risks are not a serious issue and what the other gains of
    using security descriptions are.

    >From my perspective I really would like to see some progress in at least the proposal for actually adding additional keying to ensure that the
    raised issues in drafts or earlier WG meetings and email discussions are meet. Additionally I would really like to see some more details for how
    the actual integration of an additional keying mechanism is supposed to
    work.


    >
    > I think the problem must be that those things weren't signed in
    > triplicate, sent in, sent back, queried, lost, found, subjected to
    > public enquiry, lost again, and finally buried in soft peat for three<= br> > months and recycled as firelighters.

    No, that is not it. This topic has dragged on for various reasons. Yes
    we chairs are clearly to blame for some of them, like being slow to
    attempt to schedule a meeting. However, after that there has been issues finding a suitable time where sufficient mass of people could
    participate. There has been time conflicts with other meetings resulting in a cancellation, which in hind sight was unnecessary. Then a
    rescheduling, lurk warm response from the WG, limited agenda items and
    another almost collision resulting another cancellation.

    I am sorry that this makes you frustrated. Well, it makes also me
    frustrated. I wished this topic was dealt with and out of the way, but
    it is not. So, if you want it dealt with. Please request agenda time for Berlin and ensure to update any drafts or other material to actually
    take into account what actually has happened in the last 15 months.

    Regards

    Magnus Westerlund

    ----------------------------------------------------------------------
    Multimedia Technologies, Ericsson Research EAB/TVM
    ----------------------------------------------------------------------
    Ericsson AB                | Phone =  +46 10 7148287
    F=E4r=F6gatan 6                | Mo= bile +46 73 0949079
    SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
    ----------------------------------------------------------------------

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

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

    --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7EF8TK5EX14MBXC273r_-- From matthew.kaufman@skype.net Tue Jun 18 14:21:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF8D21E808E for ; Tue, 18 Jun 2013 14:21:29 -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.107, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tT0USTXO2d11 for ; Tue, 18 Jun 2013 14:21:22 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id CDFB711E80F9 for ; Tue, 18 Jun 2013 14:21:21 -0700 (PDT) Received: from BY2FFO11FD017.protection.gbl (10.1.15.200) by BY2FFO11HUB008.protection.gbl (10.1.14.166) with Microsoft SMTP Server (TLS) id 15.0.707.0; Tue, 18 Jun 2013 21:21:20 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD017.mail.protection.outlook.com (10.1.14.105) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 18 Jun 2013 21:21:20 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.171]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Tue, 18 Jun 2013 21:20:05 +0000 From: "Matthew Kaufman (SKYPE)" To: Richard Barnes Thread-Topic: [rtcweb] No Interim on SDES at this juncture Thread-Index: AQHOZrw6CQcaVcHO7ESUEcTH2Hsm5ZkxWrGAgADdvYCAAA4GAIACkewAgACbDYCABdNvAIAAlhWIgAAKmICAABtrwIAAAl2g Date: Tue, 18 Jun 2013 21:20:04 +0000 Message-ID: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> , , 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.33] Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7F9ETK5EX14MBXC273r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(24454002)(377424003)(52314003)(51704005)(189002)(377454002)(76482001)(20776003)(44976003)(81542001)(16297215003)(54316002)(512934002)(79102001)(80022001)(16406001)(50986001)(74706001)(53806001)(74366001)(74502001)(33656001)(56776001)(54356001)(69226001)(77982001)(51856001)(59766001)(47446002)(4396001)(76796001)(46102001)(561944002)(31966008)(55846006)(74876001)(81342001)(74662001)(65816001)(63696002)(66066001)(71186001)(56816003)(76786001)(16236675002)(77096001)(6806003)(15202345002)(47976001)(49866001)(47736001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB008; H:TK5EX14HUBC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0881A7A935 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 21:21:29 -0000 --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7F9ETK5EX14MBXC273r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "Either way, those keys go over HTTPS to/from the browser, yes?"... or wors= e, the keys are sent from my server to my media relay server over its own s= ignaling channel and then *it* runs the EKT from its end. Either way, I've = got the keys and I'm probably sending them over HTTPS... only in this case,= to my gateway and not the browser. But then the browser *still* gets the keys over a channel no more/less secu= re than HTTPS. Matthew Kaufman ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Matthe= w Kaufman (SKYPE) [matthew.kaufman@skype.net] Sent: Tuesday, June 18, 2013 2:16 PM To: Richard Barnes Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture So lets assume the case where I have a web server that is talking to my bro= wser *and* generating SIP traffic to talk to your SDES-capable (and ICE-cap= able) PBX. And assume that your PBX initiated the call and picked the keying. So in the EKT case we have (for key flow): your PBX -(SDES in SIP)-> my server -(SDES in JSON in HTTPS)-> browser -(E= KT)-> a media relay i now need to run (for media): browser <--(key that was received over HTTPS and then sent using EKT)--> m= edia relay <--(key that was received via SDES)--> your pbx but in the SDES case we have (for key flow): your PBX -(SDES in SIP)-> my server -(SDES in SDP in HTTPS)-> browser (and= that's it, because I don't need a media relay in path any more) (for media): browser <--(key that was received over HTTPS at the browser, SDES in SDP o= n SIP side)--> your pbx Your diagram is missing the part where the browser either learns the key th= at it is supposed to ask EKT to set or tells your SIP/SDES side what key it= set using EKT. Either way, those keys go over HTTPS to/from the browser, y= es? Matthew Kaufman ________________________________ From: Richard Barnes [rlb@ipv.sx] Sent: Tuesday, June 18, 2013 12:32 PM To: Matthew Kaufman (SKYPE) Cc: Magnus Westerlund; Hadriel Kaplan; rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman (SKYPE) > wrote: Back on April 25th, I made some claims. I still believe these are true: 1. DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it is ju= st a different encrypted channel over which the key is set. Could you explain this in a little more detail? I agree that the COMSEC pr= operties are the same, but it seems like the communicating parties are diff= erent. DTLS-SRTP+EKT: Browser ---(EKT)---> Gateway ---(SDES)---> Endpoint SDES+HTTPS: Browser ---(HTTPS)---> Server ---(???)---> Gateway ---(SDES)---= > Endpoint That is, in the DTLS-SRTP+EKT case, the key never traverses the server. Do= es your argument require that the server and the gateway be equally trusted= ? (For example, because the server can choose the gateway.) It doesn't se= em like this is necessarily true in the general case. --Richard 2. DTLS-SRTP w/EKT requires a more complex media gateway relationship for i= nterworking (as it needs to be in-path for the keying on that side, despite= the use of SDES on the other side). 3. DTLS-SRTP w/EKT for interworking exposes the key via SDES on the other s= ide of the interworking relationship anyway, so even though there isn't SDE= S to the browser there's SDES on the other (likely SIP) side. 4. And DTLS-SRTP without EKT fails completely for the cases where the key n= eeds to be set for interworking. 5. And finally, to get the browser-to-browser security guarantees you would= need to be A) sure that you're really talking browser to browser and not v= ia something else in path (like a mixer) and B) would really prefer that th= ere be no way that the in-path device be able to force a key (thus you'd wa= nt to NOT allow EKT in the browser-to-browser case, even though there's no = way for a browser to know for sure what it is talking to... I suppose that = *if* you trusted your browser and the browser at the other end (which you n= eed to do anyway, because they could just leak keys or media), you could ma= ndate that browsers set some bit that disallows EKT and hope that the other= end respects it) Since we can't get interworking at all without either DTLS-SRTP + EKT or SD= ES, and since the security guarantees of DTLS-SRTP + EKT are the same as th= ose of SDES, and since the interworking gateway is made more complex (becau= se the keying must be in-path), I believe the only possible conclusions are= A) We accept that interworking with other SRTP systems is desirable and th= erefore SDES is the best way to achieve that or B) We prevent any interwork= ing with other RTP or SRTP systems. As someone who could make some money sending traffic to/from non-RTCWEB net= works, I'm a fan of "A". And no, I'm not planning on writing a draft that says to just do what we sh= ould be doing anyway. Matthew Kaufman ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounc= es@ietf.org] on behalf of Magnus Westerlund= [magnus.westerlund@ericsson.com] Sent: Tuesday, June 18, 2013 2:56 AM To: Hadriel Kaplan Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Interim on SDES at this juncture Hadirel and WG, Please see my response inline. On 2013-06-14 18:58, Hadriel Kaplan wrote: > You can't be serious. There was exactly ONE email asking for agenda > items, here: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html It > was sent on May 30th. It gave a generous 6 days to respond. Luckily > no one ever goes on vacation for longer than 5 days. Instead, two > people sent a response on June 10th, a tremendous 11 days after the > request. Outrageous! That's a almost twice as long as they were > given! > > Thank goodness the chairs detected this monstrous breach of > procedure, and thwarted the attempts of anarchy! I mean if people > are allowed to respond to emails so tardily, how can we be expected > to get things accomplished as quickly as they've so far been in this > WG?!? Yes, we have only sent a single email this time, being the second round in a short time we tried to schedule this meeting. > > Sure, an interim for this topic has been waiting for many months if > not a whole year, and now that people didn't respond in 6 days but > took instead 11 days the topic will be delayed indefinitely yet > again... but that's no excuse for blatantly flaunting the rules! Yes, there has been difficult finding a time could work for this meeting. That was why the agenda request time was short. > > Personally I saw the email on May 30th, and assumed Oscar and Dan > would respond to you for agenda time. I assumed that if no one had > submitted agenda items to you, that the WG Chairs would send out an > email warning about that, or perhaps even directly email the people > who they expected to submit agenda items. > Yes, you assumed that someone would respond. Rather than you reaching out to verify that others would drive the question for you. Hadriel you are apparently very interested in this topic. Why don't you ensure that an agenda topic is on the agenda for Berlin? The WG chairs are happy to receive agenda requests already now. > >> If you want to discuss this, write a draft describing how how your >> additional keying is to be integrated, what the pro and cons of it. >> That will enable direct discussion of a proposal. The WG clearly >> are opinionated on this matter, but apparently don't have energy to >> produce proposals. > > There *are* drafts. > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00 > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 There > are even powerpoint slides, sent to the chairs the last time this > meeting almost happened but didn't. One of those drafts has been expired since February I would like to point out. The looking at these drafts, they are neither a proposal for what to actually do. Dan Wing's draft is argument in general why SDES would be bad for security. Oscar Ohlsson's is an argument for why a number of potential risks are not a serious issue and what the other gains of using security descriptions are. >From my perspective I really would like to see some progress in at least the proposal for actually adding additional keying to ensure that the raised issues in drafts or earlier WG meetings and email discussions are meet. Additionally I would really like to see some more details for how the actual integration of an additional keying mechanism is supposed to work. > > I think the problem must be that those things weren't signed in > triplicate, sent in, sent back, queried, lost, found, subjected to > public enquiry, lost again, and finally buried in soft peat for three > months and recycled as firelighters. No, that is not it. This topic has dragged on for various reasons. Yes we chairs are clearly to blame for some of them, like being slow to attempt to schedule a meeting. However, after that there has been issues finding a suitable time where sufficient mass of people could participate. There has been time conflicts with other meetings resulting in a cancellation, which in hind sight was unnecessary. Then a rescheduling, lurk warm response from the WG, limited agenda items and another almost collision resulting another cancellation. I am sorry that this makes you frustrated. Well, it makes also me frustrated. I wished this topic was dealt with and out of the way, but it is not. So, if you want it dealt with. Please request agenda time for Berlin and ensure to update any drafts or other material to actually take into account what actually has happened in the last 15 months. Regards 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 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7F9ETK5EX14MBXC273r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    "Either way, those keys go over HTTPS to/from the browser, yes?= "... or worse, the keys are sent from my server to my media relay serv= er over its own signaling channel and then *it* runs the EKT from its end. Either way, I've got the keys and I'm probably = sending them over HTTPS... only in this case, to my gateway and not the bro= wser.

    But then the browser *still* gets the keys over a channel no more/less= secure than HTTPS.

    Matthew Kaufman

    From: rtcweb-bounces@ietf.org [rtcweb-bou= nces@ietf.org] on behalf of Matthew Kaufman (SKYPE) [matthew.kaufman@skype.= net]
    Sent: Tuesday, June 18, 2013 2:16 PM
    To: Richard Barnes
    Cc: rtcweb@ietf.org
    Subject: Re: [rtcweb] No Interim on SDES at this juncture

    So lets assume the case where I have a web server that is talking to m= y browser *and* generating SIP traffic to talk to your SDES-capable (and IC= E-capable) PBX.

    And assume that your PBX initiated the call and picked the keying.

    So in the EKT case we have (for key flow):
     your PBX -(SDES in SIP)-> my server -(SDES in JSON in HTTPS)-= > browser -(EKT)-> a media relay i now need to run
    (for media):
     browser <--(key that was received over HTTPS and then sent us= ing EKT)--> media relay <--(key that was received via SDES)--> you= r pbx

    but in the SDES case we have (for key flow):
     your PBX -(SDES in SIP)-> my server -(SDES in SDP in HTTPS)-&= gt; browser (and that's it, because I don't need a media relay in path any = more)
    (for media):
     browser <--(key that was received over HTTPS at the browser, = SDES in SDP on SIP side)--> your pbx


    Your diagram is missing the part where the browser either learns the k= ey that it is supposed to ask EKT to set or tells your SIP/SDES side what k= ey it set using EKT. Either way, those keys go over HTTPS to/from the brows= er, yes?

    Matthew Kaufman
      
    From: Richard Barnes [rlb@ipv.sx]
    Sent: Tuesday, June 18, 2013 12:32 PM
    To: Matthew Kaufman (SKYPE)
    Cc: Magnus Westerlund; Hadriel Kaplan; rtcweb@ietf.org
    Subject: Re: [rtcweb] No Interim on SDES at this juncture

    On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman (SKYPE) <= span dir=3D"ltr"> <matthew.= kaufman@skype.net> wrote:
    Back on April 25th, I made some claims. I still believe these are true:

    1. DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it is ju= st a different encrypted channel over which the key is set.

    Could you explain this in a little more detail?  I agree that the= COMSEC properties are the same, but it seems like the communicating partie= s are different.

    DTLS-SRTP+EKT:  Browser ---(EKT)---> Gateway ---(SDES)---&= gt; Endpoint
    SDES+HTTPS: Browser ---(HTTPS)---> Server ---(???)---> Gatew= ay ---(SDES)---> Endpoint

    That is, in the DTLS-SRTP+EKT case, the key never traverses the se= rver.  Does your argument require that the server and the gateway be e= qually trusted?  (For example, because the server can choose the gatew= ay.)  It doesn't seem like this is necessarily true in the general case.  

    --Richard

     
    2. DTLS-SRTP w/EKT requires a more complex media gateway relationship for i= nterworking (as it needs to be in-path for the keying on that side, despite= the use of SDES on the other side).

    3. DTLS-SRTP w/EKT for interworking exposes the key via SDES on the other s= ide of the interworking relationship anyway, so even though there isn't SDE= S to the browser there's SDES on the other (likely SIP) side.

    4. And DTLS-SRTP without EKT fails completely for the cases where the key n= eeds to be set for interworking.

    5. And finally, to get the browser-to-browser security guarantees you would= need to be A) sure that you're really talking browser to browser and not v= ia something else in path (like a mixer) and B) would really prefer that th= ere be no way that the in-path device be able to force a key (thus you'd want to NOT allow EKT in the browser-to= -browser case, even though there's no way for a browser to know for sure wh= at it is talking to... I suppose that *if* you trusted your browser and the= browser at the other end (which you need to do anyway, because they could just leak keys or media), you co= uld mandate that browsers set some bit that disallows EKT and hope that the= other end respects it)


    Since we can't get interworking at all without either DTLS-SRTP + EKT o= r SDES, and since the security guarantees of DTLS-SRTP + EKT are the sa= me as those of SDES, and since the interworking gateway is made more comple= x (because the keying must be in-path), I believe the only possible conclusions are A) We accept that interworking= with other SRTP systems is desirable and therefore SDES is the best way to= achieve that or B) We prevent any interworking with other RTP or SRTP syst= ems.

    As someone who could make some money sending traffic to/from non-RTCWEB net= works, I'm a fan of "A".

    And no, I'm not planning on writing a draft that says to just do what we sh= ould be doing anyway.

    Matthew Kaufman


    ________________________________________
    From: rtcweb-b= ounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Magnus Westerlund [magnus.westerl= und@ericsson.com]
    Sent: Tuesday, June 18, 2013 2:56 AM
    To: Hadriel Kaplan
    Cc: rtcweb@ietf.org
    Subject: Re: [rtcweb] No Interim on SDES at this juncture

    Hadirel and WG,

    Please see my response inline.

    On 2013-06-14 18:58, Hadriel Kaplan wrote:
    > You can't be serious. There was exactly ONE email asking for agenda > items, here:
    > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html It > was sent on May 30th.  It gave a generous 6 days to respond. &nbs= p;Luckily
    > no one ever goes on vacation for longer than 5 days. Instead, two
    > people sent a response on June 10th, a tremendous 11 days after the > request.  Outrageous!  That's a almost twice as long as they= were
    > given!
    >
    > Thank goodness the chairs detected this monstrous breach of
    > procedure, and thwarted the attempts of anarchy!  I mean if peopl= e
    > are allowed to respond to emails so tardily, how can we be expected > to get things accomplished as quickly as they've so far been in this > WG?!?

    Yes, we have only sent a single email this time, being the second round
    in a short time we tried to schedule this meeting.

    >
    > Sure, an interim for this topic has been waiting for many months if > not a whole year, and now that people didn't respond in 6 days but
    > took instead 11 days the topic will be delayed indefinitely yet
    > again... but that's no excuse for blatantly flaunting the rules!

    Yes, there has been difficult finding a time could work for this
    meeting. That was why the agenda request time was short.

    >
    > Personally I saw the email on May 30th, and assumed Oscar and Dan
    > would respond to you for agenda time.  I assumed that if no one h= ad
    > submitted agenda items to you, that the WG Chairs would send out an > email warning about that, or perhaps even directly email the people > who they expected to submit agenda items.
    >

    Yes, you assumed that someone would respond. Rather than you reaching
    out to verify that others would drive the question for you. Hadriel you
    are apparently very interested in this topic. Why don't you ensure that
    an agenda topic is on the agenda for Berlin? The WG chairs are happy to
    receive agenda requests already now.

    >
    >> If you want to discuss this, write a draft describing how how your=
    >> additional keying is to be integrated, what the pro and cons of it= .
    >> That will enable direct discussion of a proposal. The WG clearly >> are opinionated on this matter, but apparently don't have energy t= o
    >> produce proposals.
    >
    > There *are* drafts.
    > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00
    > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 There > are even powerpoint slides, sent to the chairs the last time this
    > meeting almost happened but didn't.

    One of those drafts has been expired since February I would like to
    point out.

    The looking at these drafts, they are neither a proposal for what to
    actually do. Dan Wing's draft is argument in general why SDES would be
    bad for security. Oscar Ohlsson's is an argument for why a number of
    potential risks are not a serious issue and what the other gains of
    using security descriptions are.

    >From my perspective I really would like to see some progress in at least the proposal for actually adding additional keying to ensure that the
    raised issues in drafts or earlier WG meetings and email discussions are meet. Additionally I would really like to see some more details for how
    the actual integration of an additional keying mechanism is supposed to
    work.


    >
    > I think the problem must be that those things weren't signed in
    > triplicate, sent in, sent back, queried, lost, found, subjected to
    > public enquiry, lost again, and finally buried in soft peat for three<= br> > months and recycled as firelighters.

    No, that is not it. This topic has dragged on for various reasons. Yes
    we chairs are clearly to blame for some of them, like being slow to
    attempt to schedule a meeting. However, after that there has been issues finding a suitable time where sufficient mass of people could
    participate. There has been time conflicts with other meetings resulting in a cancellation, which in hind sight was unnecessary. Then a
    rescheduling, lurk warm response from the WG, limited agenda items and
    another almost collision resulting another cancellation.

    I am sorry that this makes you frustrated. Well, it makes also me
    frustrated. I wished this topic was dealt with and out of the way, but
    it is not. So, if you want it dealt with. Please request agenda time for Berlin and ensure to update any drafts or other material to actually
    take into account what actually has happened in the last 15 months.

    Regards

    Magnus Westerlund

    ----------------------------------------------------------------------
    Multimedia Technologies, Ericsson Research EAB/TVM
    ----------------------------------------------------------------------
    Ericsson AB                | Phone =  +46 10 7148287
    F=E4r=F6gatan 6                | Mo= bile +46 73 0949079
    SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
    ----------------------------------------------------------------------

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

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

    --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7F9ETK5EX14MBXC273r_-- From ibc@aliax.net Tue Jun 18 14:29:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAB411E810A for ; Tue, 18 Jun 2013 14:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppN5K3dEEwJz for ; Tue, 18 Jun 2013 14:29:13 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDB111E8106 for ; Tue, 18 Jun 2013 14:29:13 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l10so2587457qcy.4 for ; Tue, 18 Jun 2013 14:29:13 -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=F+qrD5ZLW+ga9YB7zvYt8N14hGaL/2upcg29wxyNFRw=; b=W1bxp6uJoqJ6GttPLIGv7UUXKRBwuadjpZ+CMVUymhgyVA5bwlbuoCsrpnRP1b2XEV PahJreHNa+gIrm9jai4MgOl5RPMvBfURSBS/bdeiM/6S2Tt8dSx9H3sgSeunkpu8tmuC FRAQJDsW8qwCDC0Ab+RlzTiqPe5LOpOxuqMFvyl2cgh4mXom7TGsIhaw4h45IwKhVIsw yCX3CBzqApRM9oXqXulmeDhGh7fE9d/Y2Cza0yFFvnwVl2ruKySD/G4jHJO0tEaLpjzI ZOMP53Ty3IscKlR2FgdCoR4/c+8oz33T4rxd64FdzbCKLU1+1/rFonolbc836AbUfhSG ENfw== X-Received: by 10.224.164.205 with SMTP id f13mr646253qay.16.1371590953078; Tue, 18 Jun 2013 14:29:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Tue, 18 Jun 2013 14:28:52 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 18 Jun 2013 23:28:52 +0200 Message-ID: To: "Matthew Kaufman (SKYPE)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkmSoI7am93wdcTFrg4CqjPX/PvncdPrLgV4r1s01DhVXWZcA+/fULypktuTXs3IfY0ATsi Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 21:29:14 -0000 Hi, in reply to concers from Adam and Ted: AFAIK nobody voting for dropping SDP is requesting a "new format to replace SDP" (if I am wrong, then please correct me). What we all ask for is: - A JS API to ask the browser's WebRTC stack for media resources (this is accomplished with getUserMedia). - A JS API to provide the local PeerConnection with media data from a remote peer we want to establish a multimedia session with, but such an API must not be based on passing a blob SDP, but based on passing some kind of JS Object with detailed media attributes, including transport params (ICE fields, remote media types, remote codecs, other media features, and so on). - A JS API to request to our local PeerConnection media data that we can send to the remote peer, in the way we want, in one step or in multiple steps, and such an API call must not return a blob SDP but a JS Object with detailed media attributes (same as above). - Period. We don't want to be forced to O/A model (although I know of no other, but I do know there are other models that don't rely on O/A semantics). We don't want to deal with blob strings that must be retrieved from our local PC and sent to the remote PC as they are, untouched. Instead we want to pass and receive the media information in any custom way (which can be serialized in JSON, represented as SDP, etc) in a single step or in multiple steps (so those cared about ICE gathering delay can optimize their cuscom logic and code). And that's all (may be I miss something or I am wrong in some aspect). And once we have that: - There will appear cool JS libraries coded by SIP experts that will take the above "JS Object with media information" retrieved from our local PerrConnection and "export" it into a SDP string that will allow interoperability with SIP devices (those supporting WebRTC media requirements). For this, probably the IETF SIP WG may start a new item for specifying how such a SDP must look. The JS library will be hosted in some public server and will provide updates frequently ("press F5"). - Some SIP vendors could also provide their own JS library that offers more media features to interop with their gateways. - Some others will code JS libraries defining a new media signaling protocol in the wire. - And some others will code their own media signaling library for their websites in which they don't need interoperability with devices other than pure WebRTC browsers. - And some of them will use O/A and some others won't. So, regardingyour concerns about how hard is replacing SDP with "a new and better format", IMHO nobody is requesting that. Best regards. 2013/6/18 Matthew Kaufman (SKYPE) : > The good news is that I co-authored and Microsoft published a nice starti= ng > point for discussing a specification that doesn't have SDP O/A. > > The bad news is that it was voted down for future consideration at W3C. > > The good news is that W3C has apparently abdicated the entire responsibil= ity > for producing a browser API to IETF, where it has not yet been voted down= . > > More good news is that if and when the W3C considers the current > specification that the IETF produces, if it is not complete enough to > independently replicate without looking at other browser's source code (i= n > other words, if the SDP that is produced is not fully specified in an > interoperable way in either the W3C specification itself or, worst case, = in > the entire stack of normative references), I will also have the pleasure = of > co-authoring a formal objection to publishing that specification. > > One might consider that since the current SDP-based path we are on does n= ot > have anywhere near a complete set of implementable normative references, = and > that producing such might actually be harder than using something that > doesn't rely on SDP as the API surface, you might be a lot farther from > something that finishes the entire W3C process than you think. > > Matthew Kaufman > > ________________________________ > From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Ted > Hardie [ted.ietf@gmail.com] > Sent: Tuesday, June 18, 2013 1:15 PM > To: I=C3=B1aki Baz Castillo > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened > > I've read the messages on this thread up to lunchtime in California on Ju= ne > 18th. I have not consulted with the other chairs, because we are still > somewhat out of synch, so this is my personal response, rather than a cha= ir > response. > > SDP occurs as an API control surface in this protocol, and it may also be > used in O/A semantics between endpoints. The request does not clearly st= ate > which aspect is asking for reconsideration. Since one is handled in a > different group, that is critical. Secondly, the requirement the group h= as > is that the solution *provides support sufficient to allow O/A semantics*= , > not that these must be used between two parties using the same signalling= . > Being clear on what you would like to see by writing a draft proposal, > rather than simply asking to re-open concluded discussions would be helpf= ul. > > Speaking very personally, I would like to see the group close having > completed its milestones. While I am very aware that re-using a syntax l= ike > SDP makes for some unpleasant moments, I'm not sure that any system that > actual has any level of interoperability with existing SIP deployments as= a > goal will avoid that unpleasantness--at best, you have a mechanism on one > end that looks different *but must be mapped to SDP* in the interoperabil= ity > case. Creating something new that accomplishes that and is substantiall= y > better than SDP seems like a long task to me. > > Again, not as a chair decision or statement, but to give some response to > the points made. > > regards, > > Ted Hardie --=20 I=C3=B1aki Baz Castillo From robin@hookflash.com Tue Jun 18 15:11:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE2A11E8106 for ; Tue, 18 Jun 2013 15:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=1.006, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hi3cywfSusUz for ; Tue, 18 Jun 2013 15:11:25 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id C8A6621E80A5 for ; Tue, 18 Jun 2013 15:11:25 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id k7so5630398oag.23 for ; Tue, 18 Jun 2013 15:11:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=VAhFqjr4NrnfnEQGFodwa9xtqcVQe1x0cuzh9gUaZt4=; b=bez3QJLBivpcHDk0SWD9hAcUQh4LKbfC9BlZsqWev7jGllUWydcvhtSKR/jARO6jN0 ++hMK5T1j0AG9tqlQmj4G7hf+8UkgRraul60t3L00LpU0ftW1aXvNgStGzFOU3o+gbKy uMKNmRp99v5QM9ziRERIxnwRNpHZZN0A6xFkhruohzFrsEfCXyPiFQNgZ/PE47B1iJIg UqnrNW0y/QaYsUMVWtNr0qPpoQUU1bUTvOeqgT+QuupK+WvCkxJC3ot5wHyIak518bZ6 TBX2R3yAifXixsSovZM21iDEBUkawTVB0xC8BHh1GYdOTEY2/WaiCRA0RfqIejGFpDZA NLbg== X-Received: by 10.60.164.6 with SMTP id ym6mr4651352oeb.122.1371593485188; Tue, 18 Jun 2013 15:11:25 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id wz1sm24064185obc.3.2013.06.18.15.11.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 15:11:24 -0700 (PDT) Message-ID: <51C0DB09.8000809@hookflash.com> Date: Tue, 18 Jun 2013 18:11:21 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Adam Roach References: <51C0C1A0.9010107@nostrum.com> In-Reply-To: <51C0C1A0.9010107@nostrum.com> Content-Type: multipart/alternative; boundary="------------050606080205070305070002" X-Gm-Message-State: ALoCoQn3bT4Ok4zKiQcWGo5I3cABRE27RvDGUwl8zm1R2MkUgaZtnmYXel2HSP/+VfKZ8wvoXcwt Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:11:27 -0000 This is a multi-part message in MIME format. --------------050606080205070305070002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit That's exactly part of the trouble. People thinking we need a signaling/negotiation framework at all for media. We don't. We don't need to replace SDP with anything. It's just not necessary at all. Yes, SIP guys will need to create and parse SDP compatible with their networks, but it's still better to do that from a dynamic updatable language like JavaScript than hard coding all that inside the browser. They don't need the browser to generate something as pre-built into the hardcoded binary that generates serialized formats for the interface to the mechanics underneath. Likewise, we don't need a JSON version nor an XML version of SDP. Start treating the media and RTC like an OS API and not like a signaling layer. Sure, restrictions for security reasons must exist (like requiring ICE agreement on the wire) but beyond that the sky should be the limit. If we have a programmatic interface to the lower layer components, we can wrap it up with our own JavaScript in any method at a higher level someone might want. JavaScript is a powerful language, so there's no reason we couldn't do some really cool stuff. JSEP? No problem. Traditional SIP/SDP? Check. XMPP? Yup. However Skype negotiates? Yup. Open Peer (and other future protocols) with stateless negotiation? Check. Custom silo protocol? Yup. You have sources, like camera's / microphones. You need to be able to to get information about the formats available to be opened. You have outputs like screens and speakers. You have a mixer where you can pin in/out the various sources. You have codecs. You have media streams going in and coming out from a mixer where you can map media to RTP streams. You have DTLS connections for arbitrary data. I'm sure I'm missing something in the 5 minutes it took to write that but the point is that this isn't rocket science and it's not difficult to wrap the basic constructs like those with a decent API (even if the details can, should and will be argued but have little impact on the global scheme of things [unlike SDP]) and much easier to come to decisions because they are well known constructs with limited scopes. With JavaScript shims as needed, we can build out anything out of those building blocks we might dream up. Stick to the core of what each part is supposed to do and leave the rest to the higher level. Let's define those APIs and let's stick to the RTC layer consisting of only: STUN/ICE/TURN, DTLS, RTP/RTCP and security/encryption requirements (and any other low-level data/media level requirements). Get rid of this inane requirement for SDP and offer/answer negotiation which is just a road block and hinderance and doesn't add much value but whose long term costs/consequences are huge! Those are all lower level APIs that can entirely be done without a signaling protocol like SDP with offer/answer at all. Not everyone does SDP. Nor does everyone want to SDP, and future signaling protocols likely won't want to do SDP. The trouble currently with WebRTC is we have virtual no low level API control and only way to interface to those components is frequently exclusively via SDP and it forces everyone to use this horrifically monolithic do-everything serialized format and offer/answer round trip to boot to affect change instead of allowing lower level control over what's going on in each component; and control over the media mapping without requiring a round trip like offer/answer requires... This decision was made primarily by the industry SIP folks (some of which have changed their minds since), many of whom still mistakenly believe that without SDP there is no compatibility with WebRTC, or believe that it produces greater compatibility, or believe we must have "something" common to signal media information; all of which is completely untrue. I really do want to hear the rational in requiring SDP and offer/answer. I don't see it as another other than a major hinderance towards compatibility and innovation rather than in favour of it (including for the SIP guys). As I understand it, the resistance to opening the discussion again comes down to fear. Because we are afraid that if we decide to reopen this can o' worms that we won't be able to have consensus again and WebRTC will never happen. The fear comes from knowing people would never agree to another media related signaling format (correctly, as it's not even needed and counter productive to have one). I mean no disrespect when I ask this but is the argument against talking about it: "Let's all stick to something really bad because it's better than nothing at all, since we won't be able to come to a new agreement on a replacement to SDP (when we don't really need a replacement)?" I'm really trying (hard) to understand the resistance to removing SDP or even discussing about something so fundamentally bad and flawed as SDP with offer/answer! What are the vested interests and rational in keeping something this bad as this intact? I want WebRTC to succeed, but, sorry, SDP (in my opinion) has got to go. -Robin > Adam Roach > 18 June, 2013 4:22 PM > > > Many men have died on that hill. I'm still sad about the colossal time > and talent sink represented by these 61 pages: > > http://tools.ietf.org/id/draft-ietf-mmusic-sdpng-08.txt > > I have no reason to think that burning WebRTC down the the ground and > starting over would produce a different result. If anything, the > issues are more contentious now than they were in 2005. > > /a --------------050606080205070305070002 Content-Type: multipart/related; boundary="------------030907010205070109010703" --------------030907010205070109010703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    That's exactly part of the trouble. People thinking we need a signaling/negotiation framework at all for media. We don't. We don't need to replace SDP with anything. It's just not necessary at all. Yes, SIP guys will need to create and parse SDP compatible with their networks, but it's still better to do that from a dynamic updatable language like JavaScript than hard coding all that inside the browser. They don't need the browser to generate something as pre-built into the hardcoded binary that generates serialized formats for the interface to the mechanics underneath. Likewise, we don't need a JSON version nor an XML version of SDP.

    Start treating the media and RTC like an OS API and not like a signaling layer. Sure, restrictions for security reasons must exist (like requiring ICE agreement on the wire) but beyond that the sky should be the limit. If we have a programmatic interface to the lower layer components, we can wrap it up with our own JavaScript in any method at a higher level someone might want. JavaScript is a powerful language, so there's no reason we couldn't do some really cool stuff. JSEP? No problem. Traditional SIP/SDP? Check. XMPP? Yup. However Skype negotiates? Yup. Open Peer (and other future protocols) with stateless negotiation? Check. Custom silo protocol? Yup.

    You have sources, like camera's / microphones. You need to be able to to get information about the formats available to be opened.

    You have outputs like screens and speakers.

    You have a mixer where you can pin in/out the various sources.

    You have codecs.

    You have media streams going in and coming out from a mixer where you can map media to RTP streams.

    You have DTLS connections for arbitrary data.

    I'm sure I'm missing something in the 5 minutes it took to write that but the point is that this isn't rocket science and it's not difficult to wrap the basic constructs like those with a decent API (even if the details can, should and will be argued but have little impact on the global scheme of things [unlike SDP]) and much easier to come to decisions because they are well known constructs with limited scopes. With JavaScript shims as needed, we can build out anything out of those building blocks we might dream up. Stick to the core of what each part is supposed to do and leave the rest to the higher level. Let's define those APIs and let's stick to the RTC layer consisting of only: STUN/ICE/TURN, DTLS, RTP/RTCP and security/encryption requirements (and any other low-level data/media level requirements). Get rid of this inane requirement for SDP and offer/answer negotiation which is just a road block and hinderance and doesn't add much value but whose long term costs/consequences are huge!

    Those are all lower level APIs that can entirely be done without a signaling protocol like SDP with offer/answer at all. Not everyone does SDP. Nor does everyone want to SDP, and future signaling protocols likely won't want to do SDP.

    The trouble currently with WebRTC is we have virtual no low level API control and only way to interface to those components is frequently exclusively via SDP and it forces everyone to use this horrifically monolithic do-everything serialized format and offer/answer round trip to boot to affect change instead of allowing lower level control over what's going on in each component; and control over the media mapping without requiring a round trip like offer/answer requires...

    This decision was made primarily by the industry SIP folks (some of which have changed their minds since), many of whom still mistakenly believe that without SDP there is no compatibility with WebRTC, or believe that it produces greater compatibility, or believe we must have "something" common to signal media information; all of which is completely untrue. I really do want to hear the rational in requiring SDP and offer/answer. I don't see it as another other than a major hinderance towards compatibility and innovation rather than in favour of it (including for the SIP guys).

    As I understand it, the resistance to opening the discussion again comes down to fear. Because we are afraid that if we decide to reopen this can o' worms that we won't be able to have consensus again and WebRTC will never happen. The fear comes from knowing people would never agree to another media related signaling format (correctly, as it's not even needed and counter productive to have one). I mean no disrespect when I ask this but is the argument against talking about it: "Let's all stick to something really bad because it's better than nothing at all, since we won't be able to come to a new agreement on a replacement to SDP (when we don't really need a replacement)?"

    I'm really trying (hard) to understand the resistance to removing SDP or even discussing about something so fundamentally bad and flawed as SDP with offer/answer! What are the vested interests and rational in keeping something this bad as this intact?

    I want WebRTC to succeed, but, sorry, SDP (in my opinion) has got to go.

    -Robin


    18 June, 2013 4:22 PM


    Many men have died on that hill. I'm still sad about the colossal time and talent sink represented by these 61 pages:

    http://tools.ietf.org/id/draft-ietf-mmusic-sdpng-08.txt

    I have no reason to think that burning WebRTC down the the ground and starting over would produce a different result. If anything, the issues are more contentious now than they were in 2005.

    /a
    --------------030907010205070109010703 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------030907010205070109010703-- --------------050606080205070305070002-- From pthatcher@google.com Tue Jun 18 15:16:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E968E21E80C8 for ; Tue, 18 Jun 2013 15:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.907 X-Spam-Level: X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1VuWeKhqIV6 for ; Tue, 18 Jun 2013 15:16:49 -0700 (PDT) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by ietfa.amsl.com (Postfix) with ESMTP id D084221F998F for ; Tue, 18 Jun 2013 15:16:49 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id 10so4363414pdc.19 for ; Tue, 18 Jun 2013 15:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kFRX8cdZVj1HUFwEJ0quvzGsGuo1YPlpZBnNRFOduxg=; b=BcO/fMJHxI/6OZ4/HDIxhsgB7KN32LVgKko5VwLTtFcRco8LMR26fovDfYLJIkcS1z kZwgX+7vFcOv54RYW8vdfZS6IdvIgHA6mTXoIahd55iaZW+hcDZOM43jvJUyoQohY9jl 2d3SGt3LF2IHPaj9rOhOmhJxq7BvWf17LmeLvLxibn015sKwW0hRhW7WpYWghGNQhBWZ ZIWbkgDCekGvvp630j9phaH71xbGVh+Qs+bI5/nPrCFYcPoESm9LEotFyWQeqTXtl/I9 FVTEZxIVxkWXildBqZRCGlFp93WKkBBUGzOQ74Jkp73+KBVDe+Y5I9uWgkQP6+AAud5r QK2Q== 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=kFRX8cdZVj1HUFwEJ0quvzGsGuo1YPlpZBnNRFOduxg=; b=FXsiTTYT0E3gPfB8NgeZQRzOIy7K1mqLJG4YYLW6j5wypgRhb7cO40ZqaZLK18dNgr v//oXSDlcI5TucwEcY3aw/o2U40MCB1WQ4KlFWWFhR6S+BA0cEF2eaA72taEDecKtIcj entlE0AZWDxkMKe7jmuLsMM7EfEaVXHs/JpziYFX/ZFp3v2kh8j1NWiHnVzJkQ7z1/li /zPPLbZvm9z00iIrhbSq1L0VDVshqFsawQ3qB7eJvALsTwsrcPcstzEBzmbiMivDpd2U cUWEfC0g6jPFzfxrisCcTtBG5PvFs+nWoKrm/qVWvy2d6hd8x56FcPoa7L1TesBBFjPy iaLw== X-Received: by 10.66.163.73 with SMTP id yg9mr2560912pab.77.1371593809508; Tue, 18 Jun 2013 15:16:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Tue, 18 Jun 2013 15:16:09 -0700 (PDT) In-Reply-To: <51C0C1A0.9010107@nostrum.com> References: <51C0C1A0.9010107@nostrum.com> From: Peter Thatcher Date: Tue, 18 Jun 2013 15:16:09 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=047d7b86f75ecae1d304df7511bf X-Gm-Message-State: ALoCoQnyqa72FzVs6RvVOJRrybTcid2Y8i6eCeZ5knf/mFHNebKyAwIAgrxbJyC5VcRkjmsEVaT02Mi7v3IutYMJ59JTk96xBOLh/qMG+tCv2AEpbCiqXiz/hQAQFmlle9nebtBMHwjgZz3k/44G9G1K5LjwWrw8o8J77Uxo7IGsuz/FeyGIaTh89LGOct5Z5RIMSHI8guI9 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:16:54 -0000 --047d7b86f75ecae1d304df7511bf Content-Type: text/plain; charset=UTF-8 Adam, I think you're confused. As Ted pointed out, there are two different uses of SDP: 1. as a control surface, 2. as a message format for signalling. SDPNG was trying to replace SDP for #2. While I believe this thread was started entirely focused on #1. So you're talking about different things. So far the only time spent on trying to replace or avoid SDP for #1 has been "comment 22", and to a lesser extent the proposal I just made for adding 2 methods to PeerConnection (createLocalStream and createRemoteStream). I think it's incorrect to conclude that we should never try to improve #1 just because other in the past failed to replace #2. They're very different. I also don't think we should burn down WebRTC and start over, but despite what some seem to think, we don't have to choose between "burn it down" and "never improve it". There are many options other than the two extremes. By the way, a gentle reminder: SDP is not the only way to do #2. I work on a rather large system almost entirely build around Jingle, without a hint of SDP, and it works just fine. Much better than SDP would have, I think. Just because SDPNG didn't work out doesn't mean there will never be any way other to do signalling than SDP. On Tue, Jun 18, 2013 at 1:22 PM, Adam Roach wrote: > On 6/18/13 15:15, Ted Hardie wrote: > >> Creating something new that accomplishes that and is substantially better >> than SDP seems like a long task to me. >> > > Many men have died on that hill. I'm still sad about the colossal time and > talent sink represented by these 61 pages: > > http://tools.ietf.org/id/**draft-ietf-mmusic-sdpng-08.txt > > I have no reason to think that burning WebRTC down the the ground and > starting over would produce a different result. If anything, the issues are > more contentious now than they were in 2005. > > /a > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --047d7b86f75ecae1d304df7511bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Adam, I think you're confused. =C2=A0As Ted pointed ou= t, there are two different uses of SDP: 1. =C2=A0as a control surface, 2. a= s a message format for signalling. =C2=A0SDPNG was trying to replace SDP fo= r #2. =C2=A0While I believe this thread was started entirely focused on #1.= =C2=A0So you're talking about different things.

    So far the only time spent on trying to replace or avoid SDP= for #1 has been "comment 22", and to a lesser extent the proposa= l I just made for adding 2 methods to PeerConnection (createLocalStream and= createRemoteStream). =C2=A0 I think it's incorrect to conclude that we= should never try to improve #1 just because other in the past failed to re= place #2. =C2=A0They're very different.

    I also don't think we should burn down WebRTC and s= tart over, but despite what some seem to think, we don't have to choose= between "burn it down" and "never improve it". =C2=A0T= here are many options other than the two extremes.



    By the way, a= gentle reminder: SDP is not the only way to do #2. =C2=A0I work on a rathe= r large system almost entirely build around Jingle, without a hint of SDP, = and it works just fine. =C2=A0Much better than SDP would have, I think. =C2= =A0Just because SDPNG didn't work out doesn't mean there will never= be any way other to do signalling than SDP.



    On Tue, Jun 18, 2013 at 1:22 PM, Adam Roach <adam@nostrum.com> wrote:
    On 6/18/13 15:15, Ted Hardie wrote:
    Creating something new that accomplishes that and is substantially better t= han SDP seems like a long task to me.

    Many men have died on that hill. I'm still sad about the colossal time = and talent sink represented by these 61 pages:

    http://tools.ietf.org/id/draft-ietf-mmusic-sdpng-08.txt<= /a>

    I have no reason to think that burning WebRTC down the the ground and start= ing over would produce a different result. If anything, the issues are more= contentious now than they were in 2005.

    /a

    --047d7b86f75ecae1d304df7511bf-- From martin.thomson@gmail.com Tue Jun 18 15:25:26 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A0521E80E1 for ; Tue, 18 Jun 2013 15:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOIUZ-ifdCGJ for ; Tue, 18 Jun 2013 15:25:25 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9251821E8096 for ; Tue, 18 Jun 2013 15:25:25 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so60915wgg.2 for ; Tue, 18 Jun 2013 15:25:24 -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=W+cylVjp/gKS5EhQQS3Y7iyPHbLdFo1Tazv+V/U9QhA=; b=GBUMBFADyUQV+pIDQpgPZBWMT67RupcZ6Xo46/cwE3ez6JmD+WnirXac4QApKLd3tu NNbuXRgPUpMP147a0nR/Y8CA6bsrwNZ1CIsV+RXP0KnQpe/vdCNKdMKkXRyfIEaFAdTd zBfFRl9SXCgN5be0aFGJXvgE0u+tECFheXpDXhaMgmD5pdQCmEVRnlaDZo72ZLUu/Cch fidL6//glLo7Ruh3D/yZYT4pgjOBmNFFpZcKZu/FG8NsZwlsgwthn82dnEeuFOv6uumV 0wTP6NskYQvjJ0+OBnRzhvfnAm+l4+S5rl3w5CZubTQzaADGaK41m3W5u4UHMSbZzQiP qN+Q== MIME-Version: 1.0 X-Received: by 10.180.20.46 with SMTP id k14mr8932842wie.14.1371594324486; Tue, 18 Jun 2013 15:25:24 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Tue, 18 Jun 2013 15:25:24 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> Date: Tue, 18 Jun 2013 15:25:24 -0700 Message-ID: From: Martin Thomson To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:25:26 -0000 I agree with Peter, except for this bit: On 18 June 2013 15:16, Peter Thatcher wrote: > Adam, I think you're confused. Adam is much harder to confuse than you think, or than he professes. Speaking of burning it all down and starting over. If you want a house-related analogy, that's not quite correct. It's refusing to build an extension because the old house, while legally fit for habitation, is falling down around your ears. Since you only need foundations, it's not that big a job (though I'll grant you that it's bigger than many people realize, even with that smaller scope). From roman@telurix.com Tue Jun 18 15:40:36 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0160821E80E0 for ; Tue, 18 Jun 2013 15:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7zi7bBS2bHX for ; Tue, 18 Jun 2013 15:40:35 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 02C4911E8114 for ; Tue, 18 Jun 2013 15:40:34 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z11so70435wgg.1 for ; Tue, 18 Jun 2013 15:40:34 -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=zNGz+jw/C6cTTsEqf7AMPbOOmiZm+10LmzHPdg3fupM=; b=Mb5i38ZntTDKxwg8gPz7QcNXGIRACm9NsJ84RWVZyk5jjApL557IEtyDZx+UwIO3jY /ZNLvQuX4M1CUulySaYtXc1kOX/N88yXGbPW/fcEJ3vJovtCIKa4UtHK16Fvraraxw4r oB9addpwb+cBZf2JdeyFhikkhycDs9q1lVLgtVZmx+sdpkW202Gp2/z2Y6dGpCEhvS8n QM6JvhkSseEml965g2jGAUEsVN4yWLb6yYoSjp1JaoUIu3AQ1TcQeO1aC42RBgxv3fpO aPC1/63ubBrz2c3S2jVFALte8WZ0y1mnPLsRcA1e3WXg9xQuT5rInGOEVdOSC+x2vkx3 U9Sg== X-Received: by 10.195.12.202 with SMTP id es10mr29797wjd.17.1371595234116; Tue, 18 Jun 2013 15:40:34 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [2a00:1450:400c:c03::231]) by mx.google.com with ESMTPSA id r9sm5316160wik.1.2013.06.18.15.40.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 15:40:33 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so3878283wev.36 for ; Tue, 18 Jun 2013 15:40:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.119.228 with SMTP id kx4mr11587wjb.33.1371595232432; Tue, 18 Jun 2013 15:40:32 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Tue, 18 Jun 2013 15:40:32 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> Date: Tue, 18 Jun 2013 18:40:32 -0400 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=089e012292e29b078a04df756602 X-Gm-Message-State: ALoCoQmvjyKi9X60qkUs/SakbhvBB71IxBr2Od7zSKJx8y2931K1lKqYFEQCa56GgzUvf4HuKGGa Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:40:36 -0000 --089e012292e29b078a04df756602 Content-Type: text/plain; charset=ISO-8859-1 One thing I got to mention is that there is already an API used internally in current WebRTC implementations: Voice and Video Engines. Both of those take external network transports (which also have their interfaces defined and abstract ICE/SRTP/DTLS-SRTP) and allow to specify what codecs to be used to receive/end media and how this media is encoded. The APIs provided by these components are fairly typical for the media library APIs that are used to build SIP and other real time communications clients. In fact these very APIs were used by (at least at some point in the past) Skype, Google Talk, Yahoo Messenger and number of other real time clients. I think the best way to build a usable API is to try to wrap this in JavaScript as closely as possible instead of building something extremely complicated on top of them. If we do this, we can create something that will make the job easier for both browser developers (no complex, hard to test, code which implements O/A) and for application developers (clear API level contract with clear mechanisms to control things happening with the media). We already know that these APIs work for what we need. Let's stop trying to hide them behind O/A complexity, and then try to invent multiple creative ways to implement exactly the same functions through all the layers we built on top. _____________ Roman Shpount --089e012292e29b078a04df756602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One thing I got to mention is that there is already an API used internally = in current WebRTC implementations: Voice and Video Engines. Both of those t= ake external network transports (which also have their interfaces defined a= nd abstract ICE/SRTP/DTLS-SRTP) and allow to specify what codecs to be used= to receive/end media and how this media is encoded. The APIs provided by t= hese components are fairly typical for the media library APIs that are used= to build SIP and other real time communications clients. In fact these ver= y APIs were used by (at least at some point in the past) Skype, Google Talk= , Yahoo=A0Messenger and number of other real time clients.=A0I think the be= st way to build a usable API is to try to wrap this in JavaScript as closel= y as possible instead of building something extremely complicated on top of= them. If we do this, we can create something that will make the job easier= for both browser developers (no complex, hard to test, code which implemen= ts O/A) and for application developers (clear API level contract with clear= mechanisms to control things happening with the media). We already know th= at these APIs work for what we need. Let's stop trying to hide them beh= ind O/A complexity, and then try to invent multiple creative ways to implem= ent exactly the same functions through all the layers we built on top.

    _____________
    Roman Shpount

    --089e012292e29b078a04df756602-- From ibc@aliax.net Tue Jun 18 15:52:23 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533B611E80E1 for ; Tue, 18 Jun 2013 15:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR-xuL6g-NwE for ; Tue, 18 Jun 2013 15:52:22 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BF47011E8112 for ; Tue, 18 Jun 2013 15:52:22 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id m15so2638631qcq.19 for ; Tue, 18 Jun 2013 15:52:15 -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=Kv8eR5g4ERMCU8GWCGTQB9SiWV2HVQZJW92a1/uKMlw=; b=EgvSjsUw9h6Ma1dxsDtTfp4h7jJoBO57Qq1+YnzADI2yDBBUTbexNUIjMkGAc+nzcG ncCralsQrctQ5alrkP55QLu45+wScY6hxXUvw5C2qlaq7cySNyOWVZ+jgMh4AsLdyZXO UZQUUQfA84EhpAemn0uVFofIbcK+6WrxvXMkBXNZQ6wlpQqNx+zEyw1KBdl2R3ZH/LvM sI/NukWq7qVm4uNM3CaqkEUiqY2+fpDsP654ODhMpiX+kSPF1PrduaWMFvpuF9KlaBTa xCPRUP7sZclJLEvLVEmamabMfNmNB0jpHYPZW3piA6SaXtYLdtXIwkQR7WdguOuKoKkh tDCA== X-Received: by 10.49.81.244 with SMTP id d20mr32709qey.33.1371595935771; Tue, 18 Jun 2013 15:52:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Tue, 18 Jun 2013 15:51:55 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 19 Jun 2013 00:51:55 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmGgfJVObyOOlmjtEFGCpX3TC+9++yXgdOXY3BAQqcgc7owFaUPbYEewFZr4FwQqYaCkLxj Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:52:23 -0000 2013/6/19 Roman Shpount : > One thing I got to mention is that there is already an API used internall= y > in current WebRTC implementations: Voice and Video Engines. Both of those > take external network transports (which also have their interfaces define= d > and abstract ICE/SRTP/DTLS-SRTP) and allow to specify what codecs to be u= sed > to receive/end media and how this media is encoded. The APIs provided by > these components are fairly typical for the media library APIs that are u= sed > to build SIP and other real time communications clients. In fact these ve= ry > APIs were used by (at least at some point in the past) Skype, Google Talk= , > Yahoo Messenger and number of other real time clients. I think the best w= ay > to build a usable API is to try to wrap this in JavaScript as closely as > possible instead of building something extremely complicated on top of th= em. > If we do this, we can create something that will make the job easier for > both browser developers (no complex, hard to test, code which implements > O/A) and for application developers (clear API level contract with clear > mechanisms to control things happening with the media). We already know t= hat > these APIs work for what we need. Let's stop trying to hide them behind O= /A > complexity, and then try to invent multiple creative ways to implement > exactly the same functions through all the layers we built on top. Very good point. That exactly what we need: something like a JS wrapper of the native internal media API. -- I=C3=B1aki Baz Castillo From robin@hookflash.com Tue Jun 18 15:58:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E8921E8094 for ; Tue, 18 Jun 2013 15:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWDtQbXjBxv5 for ; Tue, 18 Jun 2013 15:58:02 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF7E21E80ED for ; Tue, 18 Jun 2013 15:57:57 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id a13so11534485iee.20 for ; Tue, 18 Jun 2013 15:57:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=6f+9LDP57jNhjs2JbHaiJWisgnki5BtckUnGimiiyKM=; b=Uw0ZJntyYyBUmPOLCQ6rQsbHFeE1es9Ywf49qt1yJZ4mUgxWGaXYIScyrkdO/OpAqe ttOml6nwFGjWgeuXJQH6E6Av/j4apRQZitTNL4pylM6keuiRgktPQFfS1P0WEa8IwC3U WJsOG6PgG9hdb/4/0itBgfeCxXahkZ2ZeSEW5hY7a7kXxX8EbXMzJg+cyME29GrrBU7k 47t/AHo2GQcsaImsvVN4xqLDnYM2EPkweuIlhIbAcPQYJ3Ik4Nyc+mkP4ZV5ih2QOWrg 9JHf10ohVKXsCaBPYP6Kc0QU6rXcsX3auSQpk2EuDq/gz3cxGE9EM+zH3J68u4PXvQqp e3fg== X-Received: by 10.50.56.50 with SMTP id x18mr8985304igp.87.1371596275715; Tue, 18 Jun 2013 15:57:55 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id ji5sm3295666igb.0.2013.06.18.15.57.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 15:57:54 -0700 (PDT) Message-ID: <51C0E5EF.3010701@hookflash.com> Date: Tue, 18 Jun 2013 18:57:51 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <51C0C1A0.9010107@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020106050800080709080401" X-Gm-Message-State: ALoCoQk0ly68S5RfuQFWwNXM6r3EhmdInUmEG65WCXpuM+/l9DuEF1P0QHlX9lIaK1g140iK/wfu Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:58:09 -0000 This is a multi-part message in MIME format. --------------020106050800080709080401 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit +1 Exactly. Spot on. -Robin > Iñaki Baz Castillo > 18 June, 2013 6:51 PM > > > Very good point. That exactly what we need: something like a JS > wrapper of the native internal media API. > > > > -- > Iñaki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Roman Shpount > 18 June, 2013 6:40 PM > One thing I got to mention is that there is already an API used > internally in current WebRTC implementations: Voice and Video Engines. > Both of those take external network transports (which also have their > interfaces defined and abstract ICE/SRTP/DTLS-SRTP) and allow to > specify what codecs to be used to receive/end media and how this media > is encoded. The APIs provided by these components are fairly typical > for the media library APIs that are used to build SIP and other real > time communications clients. In fact these very APIs were used by (at > least at some point in the past) Skype, Google Talk, Yahoo Messenger > and number of other real time clients. I think the best way to build a > usable API is to try to wrap this in JavaScript as closely as possible > instead of building something extremely complicated on top of them. If > we do this, we can create something that will make the job easier for > both browser developers (no complex, hard to test, code which > implements O/A) and for application developers (clear API level > contract with clear mechanisms to control things happening with the > media). We already know that these APIs work for what we need. Let's > stop trying to hide them behind O/A complexity, and then try to invent > multiple creative ways to implement exactly the same functions through > all the layers we built on top. > > _____________ > Roman Shpount > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Martin Thomson > 18 June, 2013 6:25 PM > I agree with Peter, except for this bit: > > Adam is much harder to confuse than you think, or than he professes. > > Speaking of burning it all down and starting over. If you want a > house-related analogy, that's not quite correct. It's refusing to > build an extension because the old house, while legally fit for > habitation, is falling down around your ears. Since you only need > foundations, it's not that big a job (though I'll grant you that it's > bigger than many people realize, even with that smaller scope). > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Peter Thatcher > 18 June, 2013 6:16 PM > Adam, I think you're confused. As Ted pointed out, there are two > different uses of SDP: 1. as a control surface, 2. as a message > format for signalling. SDPNG was trying to replace SDP for #2. While > I believe this thread was started entirely focused on #1. So you're > talking about different things. > > So far the only time spent on trying to replace or avoid SDP for #1 > has been "comment 22", and to a lesser extent the proposal I just made > for adding 2 methods to PeerConnection (createLocalStream and > createRemoteStream). I think it's incorrect to conclude that we > should never try to improve #1 just because other in the past failed > to replace #2. They're very different. > > I also don't think we should burn down WebRTC and start over, but > despite what some seem to think, we don't have to choose between "burn > it down" and "never improve it". There are many options other than > the two extremes. > > > > By the way, a gentle reminder: SDP is not the only way to do #2. I > work on a rather large system almost entirely build around Jingle, > without a hint of SDP, and it works just fine. Much better than SDP > would have, I think. Just because SDPNG didn't work out doesn't mean > there will never be any way other to do signalling than SDP. > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Adam Roach > 18 June, 2013 4:22 PM > > > Many men have died on that hill. I'm still sad about the colossal time > and talent sink represented by these 61 pages: > > http://tools.ietf.org/id/draft-ietf-mmusic-sdpng-08.txt > > I have no reason to think that burning WebRTC down the the ground and > starting over would produce a different result. If anything, the > issues are more contentious now than they were in 2005. > > /a > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------020106050800080709080401 Content-Type: multipart/related; boundary="------------040400060609000001010009" --------------040400060609000001010009 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
    +1

    Exactly. Spot on.

    -Robin


    18 June, 2013 6:51 PM


    Very good point. That exactly what we need: something like a JS
    wrapper of the native internal media API.



    --
    Iñaki Baz Castillo
    <ibc@aliax.net>
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    18 June, 2013 6:40 PM
    One thing I got to mention is that there is already an API used internally in current WebRTC implementations: Voice and Video Engines. Both of those take external network transports (which also have their interfaces defined and abstract ICE/SRTP/DTLS-SRTP) and allow to specify what codecs to be used to receive/end media and how this media is encoded. The APIs provided by these components are fairly typical for the media library APIs that are used to build SIP and other real time communications clients. In fact these very APIs were used by (at least at some point in the past) Skype, Google Talk, Yahoo Messenger and number of other real time clients. I think the best way to build a usable API is to try to wrap this in JavaScript as closely as possible instead of building something extremely complicated on top of them. If we do this, we can create something that will make the job easier for both browser developers (no complex, hard to test, code which implements O/A) and for application developers (clear API level contract with clear mechanisms to control things happening with the media). We already know that these APIs work for what we need. Let's stop trying to hide them behind O/A complexity, and then try to invent multiple creative ways to implement exactly the same functions through all the layers we built on top.

    _____________
    Roman Shpount

    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    18 June, 2013 6:25 PM
    I agree with Peter, except for this bit:

    Adam is much harder to confuse than you think, or than he professes.

    Speaking of burning it all down and starting over. If you want a
    house-related analogy, that's not quite correct. It's refusing to
    build an extension because the old house, while legally fit for
    habitation, is falling down around your ears. Since you only need
    foundations, it's not that big a job (though I'll grant you that it's
    bigger than many people realize, even with that smaller scope).
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    18 June, 2013 6:16 PM
    Adam, I think you're confused.  As Ted pointed out, there are two different uses of SDP: 1.  as a control surface, 2. as a message format for signalling.  SDPNG was trying to replace SDP for #2.  While I believe this thread was started entirely focused on #1.  So you're talking about different things.

    So far the only time spent on trying to replace or avoid SDP for #1 has been "comment 22", and to a lesser extent the proposal I just made for adding 2 methods to PeerConnection (createLocalStream and createRemoteStream).   I think it's incorrect to conclude that we should never try to improve #1 just because other in the past failed to replace #2.  They're very different.

    I also don't think we should burn down WebRTC and start over, but despite what some seem to think, we don't have to choose between "burn it down" and "never improve it".  There are many options other than the two extremes.



    By the way, a gentle reminder: SDP is not the only way to do #2.  I work on a rather large system almost entirely build around Jingle, without a hint of SDP, and it works just fine.  Much better than SDP would have, I think.  Just because SDPNG didn't work out doesn't mean there will never be any way other to do signalling than SDP.




    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    18 June, 2013 4:22 PM


    Many men have died on that hill. I'm still sad about the colossal time and talent sink represented by these 61 pages:

    http://tools.ietf.org/id/draft-ietf-mmusic-sdpng-08.txt

    I have no reason to think that burning WebRTC down the the ground and starting over would produce a different result. If anything, the issues are more contentious now than they were in 2005.

    /a
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    --------------040400060609000001010009 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxD9py+sZfjkviDxZNpF7b6h4d024uZb2x t7iQ3Ei/NuZkLAnggZwAwwAMVni+ZaU9ztwUafM5VtjEbQ/g0PD3/CSiz8MiBG2hlsrfBf02 iPn6Vwc+I2uel7DCfHbQn/Zrv9HvP2kfDcmk2+k2umTWl2q+TpkFs5kUAABljV1bLAjBByM1 24NzWlR6nnYyEG1KitD6v/4X78Wf+h4vv++Y/wD4mu3lRwninx/8CWFzqnhTxPelfsmuaPb2 cvOGE0UMZBz/ALgH5GuTGxcf3qPUwEoT/dSPKU8P+G1hGgb4vsP25l4cbgNgXP6detec5T+I 9lUaXLynqf7OHgDT7n4knX7IRiw8NKiLk5dppCSuPbCsT9BXZgqbqv2j6Hl46pClenHqrGl/ aC+o/OvSPGND9om/0xvhX4W0t763TXbSW1aOxeQC4ASBo5gU6jDYByBgjHWscY4+z1OnCX9r ofOZvNPWMvJc3PD7jAN2Q3pj0z2ryby5T3/rEeXlsfQv7K/iDw1pOhapZ6nrNjaa3e3xuGtJ 51SUwJGu1gCRkDLZxnFelgZQ9m0meHjU/aXZQ/4RHxx/0Jmvf+C6b/4mujmOM8Y/bJ/5PT+K P/X3a/8AoiKuLEbI6cN8R5mf9RP/ANdK5mdg7wx/yVDwJ/2Nmm/+jkrajuc2K2R+9VdJxn// 2Q== --------------040400060609000001010009 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------040400060609000001010009-- --------------020106050800080709080401-- From bernard_aboba@hotmail.com Tue Jun 18 16:16:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FF621F8F6E for ; Tue, 18 Jun 2013 16:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CgW+ITtZdMW for ; Tue, 18 Jun 2013 16:16:19 -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 23A2621E808B for ; Tue, 18 Jun 2013 16:15:54 -0700 (PDT) Received: from BLU169-W104 ([65.55.116.72]) by blu0-omc3-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jun 2013 16:15:54 -0700 X-TMN: [oXdP9HXvGTO/S9nJEeaO7pQZd4SJ5axkvYuUOgUUgus=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_49d17fdd-d131-4528-9adc-e312e0e9cff4_" From: Bernard Aboba To: Magnus Westerlund Date: Tue, 18 Jun 2013 16:15:53 -0700 Importance: Normal In-Reply-To: <51C02EE8.5070809@ericsson.com> References: , , , <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com>, <51BAC9BC.6070708@ericsson.com>, <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com>, <51C02EE8.5070809@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jun 2013 23:15:54.0361 (UTC) FILETIME=[C80F4690:01CE6C79] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 23:16:25 -0000 --_49d17fdd-d131-4528-9adc-e312e0e9cff4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Additionally I would really like to see some more details for how > the actual integration of an additional keying mechanism is supposed to > work. [BA] Since both SDES and DTLS/SRTP (via the DtlsSrtpKeyAgreement constraint= ) are supported in Chrome at the moment=2C an example of how it would work = is available in running code.=20 =20 Are you looking for a presentation on the implementation details? Examples= of the SDP that are used? =20 = --_49d17fdd-d131-4528-9adc-e312e0e9cff4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    >=3B Additionally I would real= ly like to see some more details for how
    >=3B the actual integration o= f an additional keying mechanism is supposed to
    >=3B work.

    [BA]= Since both SDES and DTLS/SRTP (via the DtlsSrtpKeyAgreement constraint) ar= e supported in Chrome at the moment=2C an example of how it would work is a= vailable in running code.
     =3B
    Are you looking for a presentatio= n on the implementation details? =3B Examples of the SDP that are used?=  =3B
    = --_49d17fdd-d131-4528-9adc-e312e0e9cff4_-- From silviapfeiffer1@gmail.com Tue Jun 18 19:36:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E2D21F9954 for ; Tue, 18 Jun 2013 19:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTZDRGQnSDFq for ; Tue, 18 Jun 2013 19:36:14 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id E111C21F9921 for ; Tue, 18 Jun 2013 19:36:13 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so12279213ied.0 for ; Tue, 18 Jun 2013 19:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yGXdYSVyoEepJkzSdpgzSZIxmg7mNkmqcmD72sYVrR4=; b=uAIcVVm/Vbbp5/LnkLXK4YfO0Swry263PEpl9MgIG9ueu+Dul37IRtSllb8IMxpCaX 4p71AWaPjgndmeJyWDDIGUnWsoiVYZtlxG953X5o/krfaPGuWVF5YHzmXfdlWA0JGycl pnuhG+HMWWyJDdPE5lO2y3Yp+LdkjBSLhXr62qrT7RjLmllP59HSzFcX6sx6YB4CAqJ5 p2uP3Da5kbMLbR5Q3al05vHqmhtIbw7mIGLZqh85MuLiwuupKsxv1EBEX9YuvC1BREGZ LTUDCBG3+sX6cbbl336P0s+BoUFiCcaKBkdhxVHRz5TmLvupNPoL5dHbBUdookk3UQ4i AOmQ== X-Received: by 10.50.112.69 with SMTP id io5mr320504igb.27.1371609373419; Tue, 18 Jun 2013 19:36:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.170.104 with HTTP; Tue, 18 Jun 2013 19:35:53 -0700 (PDT) In-Reply-To: <51C051AB.6030505@makk.es> References: <51BFFB65.2020203@jitsi.org> <51C051AB.6030505@makk.es> From: Silvia Pfeiffer Date: Wed, 19 Jun 2013 12:35:53 +1000 Message-ID: To: Max Jonas Werner Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 02:36:15 -0000 On Tue, Jun 18, 2013 at 10:25 PM, Max Jonas Werner wrote: > Hej Silvia, > > On 18.06.2013 08:25, Silvia Pfeiffer wrote:> On Tue, Jun 18, 2013 at > 4:17 PM, Emil Ivov wrote: >>> On 18.06.13, 03:00, Silvia Pfeiffer wrote: >>>> >>>> What I would like to see, though, is a bit different from what you've >>>> proposed. In particular, the MediaFlowDescription object is the one >>>> object that I believe is supposed to enable JS developers to do "SDP >>>> hacking" without having to understand SDP. Unfortunately, the way in >>>> which it is currently written, this API doesn't help a JS developer >>>> much. There are properties in that object like "ssrc" that mean >>>> nothing unless you understand SDP. >>> >>> SSRC is really just a flow identifier and it actually comes from RTP, not >>> SDP. >> >> OK, could we call it rtpflowId or mediaflowId or peerflowId or >> something? And what exactly are the other identifiers? >> (You will notice that I am really naive wrt SDP, sorry!) > > Do you really want to create a second "terminology world"? For people > who don't know what SSRC means (because they don't know RTP) it may seem > reasonable but to those who already know RTP you'd have to explain > "yeah, rtpflowId is actually SSRC." So the term SSRC would have to be > included in the spec anyway. You can leave mention of SSRC to a comment in the spec next to rtpflowId. > I'm not sure if having different names for the same thing would lead to > less confusion. If SSRC is the name it's given in SDP and we want to get away from SDP, this would be a first step, wouldn't it? Silvia. From pthatcher@google.com Tue Jun 18 22:37:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8107221F9D7B for ; Tue, 18 Jun 2013 22:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frODjFNn3fPc for ; Tue, 18 Jun 2013 22:37:00 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id F095921F9D62 for ; Tue, 18 Jun 2013 22:36:59 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp12so4743713pab.7 for ; Tue, 18 Jun 2013 22:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YfEOzRP/WUCxhQgSB8mOk6LIJJaq4h217mIeZCyt1VY=; b=dO1YdB65lQEGsjKhizxyh94mViz8+5cf4J5MRNxYATmQ/Tsw3IcY8U6nszgP6x5nhp piP4aLaxjzItAMMnH1158s3UzUusuP7vqgsFZyYuj389KHOtR8xrLn1pJHi+cFrTlF+y TjRsThrQWI1e25eCPIzxgJbZE0KZGtTHdVjj+NWcnwJwo5LlHkr4WUlmGsAxyya4tsbt Jd8uVmxzIqoRx+G+FwW1Y8IwZkueAgKlAJtdnn2NNXtbozqPkriGsCI4k2zClISva64Z EzAHxZn7vD05Hrj1GfRN5CrJ86QLcxHJ/pubIaOX/1vljykvvgmDdyNMmEsJG0Pq+H7A Mr9A== 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=YfEOzRP/WUCxhQgSB8mOk6LIJJaq4h217mIeZCyt1VY=; b=PMHegpybP7RKL6yxd+YM5pI3ieLXqV2AXVi6HCAAGQdXH5jk54cbD4SMsq7cUStEQL nCIzwmhQJaXoYMojr86IR8AxLDwLrSkS59hvIRLqOWKIsmXiUmPfh3bIjQssx6M0Yi83 wMEa2TP+9NQj393HONAXkPeiMnAhnti1b7mhZ7xmTR1QGeaVXwIJ+Lly1nCV6nRF4G8P h73bo8jYwIzmEoeT+WJcbmvU4ljyry36PZ2XemZC1zDqE7//LLpD6DkvkF0+kvSgEYwQ pEeg/R3+pwMlw60JOywv3EgU7EplYm7JmeTYwS6bsfbt/dV+oWviK2YO1FHO/sxr8jVD t8aA== X-Received: by 10.66.83.7 with SMTP id m7mr5209512pay.150.1371620219593; Tue, 18 Jun 2013 22:36:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Tue, 18 Jun 2013 22:36:19 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> From: Peter Thatcher Date: Tue, 18 Jun 2013 22:36:19 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d042ef48df4cbad04df7b37f6 X-Gm-Message-State: ALoCoQlHBktt0D/3C+1+Jk8UDU/q7/yDoijUxlSednbIj1nDM1nOrXTHBXryKTRBT2dJ28TvUwrWLc24t8Kyo5NW+PG0ShnEJcEF7xqHU63tBAzFxU3EgwVsiA09k+usuNa3R0SbLCO8uWBWLL2vFGgkX1pJG3hJ8k/UfTKjVBIOaNZ4e4LU5+wwOfnrtIxUMe6GUOFDV+Q+ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 05:37:00 -0000 --f46d042ef48df4cbad04df7b37f6 Content-Type: text/plain; charset=UTF-8 Martin, you're right; that was overly harsh of me. Adam, I apologize. I'll be civil in the future. On Tue, Jun 18, 2013 at 3:25 PM, Martin Thomson wrote: > I agree with Peter, except for this bit: > > On 18 June 2013 15:16, Peter Thatcher wrote: > > Adam, I think you're confused. > > Adam is much harder to confuse than you think, or than he professes. > > Speaking of burning it all down and starting over. If you want a > house-related analogy, that's not quite correct. It's refusing to > build an extension because the old house, while legally fit for > habitation, is falling down around your ears. Since you only need > foundations, it's not that big a job (though I'll grant you that it's > bigger than many people realize, even with that smaller scope). > --f46d042ef48df4cbad04df7b37f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Martin, you're right; that was overly harsh of me. =C2= =A0Adam, I apologize. =C2=A0I'll be civil in the future.


    On Tue, Jun 18, 2013 a= t 3:25 PM, Martin Thomson <martin.thomson@gmail.com> = wrote:
    I agree with Peter, except for this bit:

    On 18 June 2013 15:16, Peter Thatcher <pthatcher@google.com> wrote:
    > Adam, I think you're confused.

    Adam is much harder to confuse than you think, or than he professes.<= br>
    Speaking of burning it all down and starting over. =C2=A0If you want a
    house-related analogy, that's not quite correct. =C2=A0It's refusin= g to
    build an extension because the old house, while legally fit for
    habitation, is falling down around your ears. =C2=A0Since you only need
    foundations, it's not that big a job (though I'll grant you that it= 's
    bigger than many people realize, even with that smaller scope).

    --f46d042ef48df4cbad04df7b37f6-- From prvs=8882e23220=christer.holmberg@ericsson.com Tue Jun 18 23:34:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6828E21F9EC2 for ; Tue, 18 Jun 2013 23:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC2LA0+9eBrF for ; Tue, 18 Jun 2013 23:34:47 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E094C21F9F14 for ; Tue, 18 Jun 2013 23:34:44 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-c0-51c15103e095 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 42.AD.15700.30151C15; Wed, 19 Jun 2013 08:34:43 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 08:34:43 +0200 From: Christer Holmberg To: Peter Thatcher , Martin Thomson Thread-Topic: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Thread-Index: AQHObEI/LKM23biSMEicZL6ip01H1Jk7xwcAgAACKQCAAB+igIAAApYAgAB4ZYCAADHZMA== Date: Wed, 19 Jun 2013 06:34:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> References: <51C0C1A0.9010107@nostrum.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3AE500ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvrS5z4MFAg6WtRhbXzvxjtLi2/DWr xdp/7ewOzB47Z91l91iwqdRjyZKfTAHMUdw2SYklZcGZ6Xn6dgncGbNnPWIr+KJa8fjgXNYG xj0KXYycHBICJhL3Dp1ghbDFJC7cW8/WxcjFISRwmFHizZoVLCAJIYFFjBLbZsV3MXJwsAlY SHT/0wYJiwiESRz7spQJxGYWUJU4f+gcI4gtLOAh0bnwIjNIuYiAp8Tys1Uw5f/uTgBbxQJU vnrKarASXgFfiWk7zCC2djNLnPo/jxmkhlMgUKLrQysbiM0IdNr3U2ugVolL3HoynwniZAGJ JXvOM0PYohIvH/9jBZnJLJAvsecg2JW8AoISJ2c+YZnAKDILSfcshKpZSKogSnQkFuz+xAZh a0ssW/iaGcY+c+AxE7L4Akb2VYzsuYmZOenlhpsYgXF0cMtv3R2Mp86JHGKU5mBREuf9cGpX oJBAemJJanZqakFqUXxRaU5q8SFGJg5OEMEl1cAYsrB2UmaDCoPKqQZu31MT2atn5/dHOK8v k7aac+1ha77H5zsOdT2bf8/R9JU8P+nsxOW1W64cWLv7YtBVNU73O9MjZv/RrJt65aTL95UB 3/i/n9fwWeue/Pk+OytLXUq2j9JKK61D8qKr/37Z8bchftu9K4aRBjuOROT0miUE6Rs82//h c+5/JZbijERDLeai4kQAzGEChHYCAAA= Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 06:34:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3AE500ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We need to be very clear what we talk about, or some people are always goin= g to be confused :) So, AFAIK, the discussion is about SDP O/A usage in the API, only in the AP= I, and nowhere but the API. Whatever people us on the wire is outside the scope. Right? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Peter Thatcher [pthatcher@google.com] To: Martin Thomson [martin.thomson@gmail.com] CC: rtcweb@ietf.org [rtcweb@ietf.org] Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Martin, you're right; that was overly harsh of me. Adam, I apologize. I'l= l be civil in the future. On Tue, Jun 18, 2013 at 3:25 PM, Martin Thomson > wrote: I agree with Peter, except for this bit: On 18 June 2013 15:16, Peter Thatcher > wrote: > Adam, I think you're confused. Adam is much harder to confuse than you think, or than he professes. Speaking of burning it all down and starting over. If you want a house-related analogy, that's not quite correct. It's refusing to build an extension because the old house, while legally fit for habitation, is falling down around your ears. Since you only need foundations, it's not that big a job (though I'll grant you that it's bigger than many people realize, even with that smaller scope). --_000_7594FB04B1934943A5C02806D1A2204B1C3AE500ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hi,
     
    We need to be very clear what we talk about, or= some people are always going to be confused :)
     
    So, AFAIK, the discussion is about SDP O/A usag= e in the API, only in the API, and nowhere but the API.
     
    Whatever people us on the wire is outside the s= cope.
     
    Right?
     
    Regards,
     
    Christer
     


    Sent from Windows using TouchDown= (www.nitrodesk.com)

    -----Original Message-----
    From: Peter Thatcher [pthatcher@google.com]
    To: Martin Thomson [martin.thomson@gmail.com]
    CC: rtcweb@ietf.org [rtcweb@ietf.org]
    Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate t= o be re-opened
    Martin, you're right; that was overly harsh of me.  A= dam, I apologize.  I'll be civil in the future.


    On Tue, Jun 18, 2013 at 3:25 PM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
    I agree with Peter, except for this bit:

    On 18 June 2013 15:16, Peter Thatcher <pthatcher@google.com> wrote:
    > Adam, I think you're confused.

    Adam is much harder to confuse than you think, or than he professes.

    Speaking of burning it all down and starting over.  If you want a
    house-related analogy, that's not quite correct.  It's refusing to
    build an extension because the old house, while legally fit for
    habitation, is falling down around your ears.  Since you only need
    foundations, it's not that big a job (though I'll grant you that it's
    bigger than many people realize, even with that smaller scope).

    --_000_7594FB04B1934943A5C02806D1A2204B1C3AE500ESESSMB209erics_-- From pthatcher@google.com Tue Jun 18 23:50:03 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D9621F9D64 for ; Tue, 18 Jun 2013 23:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-741LrQoQtb for ; Tue, 18 Jun 2013 23:49:58 -0700 (PDT) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by ietfa.amsl.com (Postfix) with ESMTP id 84AFB21F9A35 for ; Tue, 18 Jun 2013 23:49:58 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x11so4741062pdj.29 for ; Tue, 18 Jun 2013 23:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Xe+QTvLDEbPGYhzar8F/PkZsf58T1WqmCJ/rghPuZuM=; b=ZhvTdH6v990U+AGlRyQ32MElu4IKWyArELlCinWDHPKtJriI302m3ataGDpHTM6ETr Eagu7QKDuwKim94M0yg6SrlQuw5ilcasMoVlBlRV1piTHzw+jVJelX0oPldfqmg+Xzu4 yz2nILKHWhFQ2WnHzRbsqzP76RJcU2nfWRYm0AVP7B6XY1g6DaIvYNOns1b9wBKgk5ll QVh5lLnM2nwJF7kWfz3xujbwY/wlvQfqq8wDYVvDRXbdcYjeODyxQobQ431mRrcpxQEc 8ZMJU5d8AdPyVD+m9LKMsuVlghXVknzOfTJ90YDQ5Mt5icwFoO6GEVGrFZohnJGtLHd/ p+Jw== 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=Xe+QTvLDEbPGYhzar8F/PkZsf58T1WqmCJ/rghPuZuM=; b=GRfErL/F+QJzAP1gCw2dz58lj/spyTpmaBJ//JVuBz8ofU4BX08bP6TKo+NjggjrsT W1vpXj/UtM9IuEm830AUsM79vLYgTGhzknmFglbdxzh7A17xiltYH7Q85VDxoyuzikiZ fZz9QSlcNDGYjifW3DgY9R0Q166eZpIgRppRkfZMOpJfYtlTymK4wEYIbYbmAHuaLV6d q4rXWMMJsPawX++WkbPZ11IwB5jGbSih/SuOKDp/I4OsSQtIGpL6xvd2f96bxroRpyjm /IuLy8EjO2uw0j+BiY9k5f84HZw6YDSmNlJd95rS5QNob0xiRxKdNnxH5ONFjeirnEzP k7aQ== X-Received: by 10.66.240.70 with SMTP id vy6mr5482617pac.70.1371624590104; Tue, 18 Jun 2013 23:49:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Tue, 18 Jun 2013 23:49:09 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Tue, 18 Jun 2013 23:49:09 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b15aba9757faa04df7c3c14 X-Gm-Message-State: ALoCoQlm3uWZ2SuvrLLNn9QtZSYAawn2PZtjLYjjuLaSAPzfaOvGnCRV75r5YypRnBK1xGwZ6/m7tk39pTwLvhgAJfW+8o9Ag+HrDa15IoQNCLaBV1zRrlqdllwnhpwH1lA4HtN09AGjU/RaKdhCkMDi4bOthUL4IWMFZLvLhE6yeZVLaIq5DcFdqP4nzHyrlz52SoONAPU/ Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 06:50:03 -0000 --047d7b15aba9757faa04df7c3c14 Content-Type: text/plain; charset=UTF-8 Correct my if I'm wrong, but the API already leaves what goes over the wire completely up to the JS app. So we couldn't re-open a debate of "SDP or not SDP" for the wire format, because there's nothing to debate. We already decided it would be left to the JS to decide. The only thing left to debate is the API. Or am I wrong? On Tue, Jun 18, 2013 at 11:34 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > We need to be very clear what we talk about, or some people are always > going to be confused :) > > So, AFAIK, the discussion is about SDP O/A usage in the API, only in the > API, and nowhere but the API. > > Whatever people us on the wire is outside the scope. > > Right? > > Regards, > > Christer > > > > Sent from *Windows* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Peter Thatcher [pthatcher@google.com] > *To:* Martin Thomson [martin.thomson@gmail.com] > *CC:* rtcweb@ietf.org [rtcweb@ietf.org] > *Subject:* Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened > Martin, you're right; that was overly harsh of me. Adam, I apologize. > I'll be civil in the future. > > > On Tue, Jun 18, 2013 at 3:25 PM, Martin Thomson wrote: > >> I agree with Peter, except for this bit: >> >> On 18 June 2013 15:16, Peter Thatcher wrote: >> > Adam, I think you're confused. >> >> Adam is much harder to confuse than you think, or than he professes. >> >> Speaking of burning it all down and starting over. If you want a >> house-related analogy, that's not quite correct. It's refusing to >> build an extension because the old house, while legally fit for >> habitation, is falling down around your ears. Since you only need >> foundations, it's not that big a job (though I'll grant you that it's >> bigger than many people realize, even with that smaller scope). >> > > --047d7b15aba9757faa04df7c3c14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Correct my if I'm wrong, but the API already leaves wh= at goes over the wire completely up to the JS app. =C2=A0So we couldn't= re-open a debate of "SDP or not SDP" for the wire format, becaus= e there's nothing to debate. =C2=A0We already decided it would be left = to the JS to decide. =C2=A0The only thing left to debate is the API. =C2=A0=

    Or am I wrong?



    On Tue, Jun 18, 2013 at 11:34 PM= , Christer Holmberg <christer.holmberg@ericsson.com> wrote:
    Hi,
    =C2=A0
    We need to be very clear what we talk about, or= some people are always going to be confused :)
    =C2=A0
    So, AFAIK, the discussion is about SDP O/A usag= e in the API, only in the API, and nowhere but the API.
    =C2=A0
    Whatever people us on the wire is outside the s= cope.
    =C2=A0
    Right?
    =C2=A0
    Regards,
    =C2=A0
    Christer
    =C2=A0


    Sent from Windows using TouchDown= (www.nitrodesk.com<= /a>)

    -----Original Message-----
    From: Peter Thatcher [    pthatcher@google.com]
    To: Martin Thomson [martin.thomson@gmail.com]
    CC: rtcweb@ietf= .org [rtcweb@ietf.= org]
    Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate t= o be re-opened
    Martin, you're right; that was overly harsh of me. =C2= =A0Adam, I apologize. =C2=A0I'll be civil in the future.


    On Tue, Jun 18, 2013 at 3:25 PM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
    I agree with Peter, except for this bit:

    On 18 June 2013 15:16, Peter Thatcher <pthatcher@google.com> wrote:
    > Adam, I think you're confused.

    Adam is much harder to confuse than you think, or than he professes.

    Speaking of burning it all down and starting over. =C2=A0If you want a
    house-related analogy, that's not quite correct. =C2=A0It's refusin= g to
    build an extension because the old house, while legally fit for
    habitation, is falling down around your ears. =C2=A0Since you only need
    foundations, it's not that big a job (though I'll grant you that it= 's
    bigger than many people realize, even with that smaller scope).


    --047d7b15aba9757faa04df7c3c14-- From prvs=98825cdfba=christer.holmberg@ericsson.com Tue Jun 18 23:59:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F21A21F9F61 for ; Tue, 18 Jun 2013 23:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.764 X-Spam-Level: X-Spam-Status: No, score=-5.764 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zJKOYgGUP24 for ; Tue, 18 Jun 2013 23:59:40 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B73D521F9F51 for ; Tue, 18 Jun 2013 23:59:39 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-7c-51c156da219a Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DF.60.15700.AD651C15; Wed, 19 Jun 2013 08:59:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 08:59:37 +0200 From: Christer Holmberg To: Peter Thatcher Thread-Topic: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Thread-Index: AQHObEI/LKM23biSMEicZL6ip01H1Jk7xwcAgAACKQCAAB+igIAAApYAgAB4ZYCAADHZMP//4oGAgAAkc4k= Date: Wed, 19 Jun 2013 06:59:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3AE7CF@ESESSMB209.ericsson.se> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3AE7CFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvre6tsIOBBrsvK1tcO/OP0eLa8tes Fmv/tbM7MHvsnHWX3WPBplKPJUt+MgUwR3HbJCWWlAVnpufp2yVwZzTcf8VUsMSxYtXTw4wN jB0WXYycHBICJhItryczQ9hiEhfurWfrYuTiEBI4zChx78ElRghnEaPE7HWPgTIcHGwCFhLd /7RBGkQENCUmT25mBbGZBYIklp0/wgRiCwt4SHQuvMgMUi4i4Cmx/GwVRHmSxM4LSxhBbBYB VYn13b9YQUp4BXwlLj7khtg0jUVi3qLNYGM4BQIl9m36zQ5iMwLd9v3UGiaIVeISt57MZ4K4 WUBiyZ7zUPeLSrx8/A9sJrNAvsS5Y4IgYV4BQYmTM5+wTGAUmYWkexZC1SwkVRAlOhILdn9i g7C1JZYtfM0MY5858JgJWXwBI/sqRvbcxMyc9HLDTYzASDq45bfuDsZT50QOMUpzsCiJ8344 tStQSCA9sSQ1OzW1ILUovqg0J7X4ECMTByeI4JJqYLTfLuO00PS1Mu+vVxJr3qvz8q83PmzR HHSsYcJSFg8FBZXj7TdWTS25llpe8/PEzyb5vw8fTf9SFLdtrZDMNL3VAg8Ohe6d1vCVy/pd 4wGp0zUBV5ieNC80qFnKbqr0tXXOuWovpvvMa17GmccfviKtVL8w6reqH9u+Dg7J27W9Tk2O dXJTRZVYijMSDbWYi4oTASGs78V3AgAA Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 06:59:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3AE7CFESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have the same understanding as you. But, just to make sure everyone know = what is discussed :) Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Peter Thatcher [pthatcher@google.com] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: Martin Thomson [martin.thomson@gmail.com]; rtcweb_ietf.org [rtcweb@ietf= .org] Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Correct my if I'm wrong, but the API already leaves what goes over the wire= completely up to the JS app. So we couldn't re-open a debate of "SDP or n= ot SDP" for the wire format, because there's nothing to debate. We already= decided it would be left to the JS to decide. The only thing left to deba= te is the API. Or am I wrong? On Tue, Jun 18, 2013 at 11:34 PM, Christer Holmberg > wrote: Hi, We need to be very clear what we talk about, or some people are always goin= g to be confused :) So, AFAIK, the discussion is about SDP O/A usage in the API, only in the AP= I, and nowhere but the API. Whatever people us on the wire is outside the scope. Right? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Peter Thatcher [pthatcher@google.com] To: Martin Thomson [martin.thomson@gmail.com] CC: rtcweb@ietf.org [rtcweb@ietf.org] Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Martin, you're right; that was overly harsh of me. Adam, I apologize. I'l= l be civil in the future. On Tue, Jun 18, 2013 at 3:25 PM, Martin Thomson > wrote: I agree with Peter, except for this bit: On 18 June 2013 15:16, Peter Thatcher > wrote: > Adam, I think you're confused. Adam is much harder to confuse than you think, or than he professes. Speaking of burning it all down and starting over. If you want a house-related analogy, that's not quite correct. It's refusing to build an extension because the old house, while legally fit for habitation, is falling down around your ears. Since you only need foundations, it's not that big a job (though I'll grant you that it's bigger than many people realize, even with that smaller scope). --_000_7594FB04B1934943A5C02806D1A2204B1C3AE7CFESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hi,
     
    I have the same understanding as you. But, just= to make sure everyone know what is discussed :)
     
    Regards,
     
    Christer
     


    Sent from Windows using TouchDown= (www.nitrodesk.com)

    -----Original Message-----
    From: Peter Thatcher [pthatcher@google.com]
    To: Christer Holmberg [christer.holmberg@ericsson.com]
    CC: Martin Thomson [martin.thomson@gmail.com]; rtcweb_ietf.org [rtcw= eb@ietf.org]
    Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate t= o be re-opened
    Correct my if I'm wrong, but the API already leaves what g= oes over the wire completely up to the JS app.  So we couldn't re-open= a debate of "SDP or not SDP" for the wire format, because there'= s nothing to debate.  We already decided it would be left to the JS to decide.  The only thing left to debate is the AP= I.  

    Or am I wrong?



    On Tue, Jun 18, 2013 at 11:34 PM, Christer Holmb= erg <chr= ister.holmberg@ericsson.com> wrote:
    Hi,
     
    We need to be very clear what we talk about, or= some people are always going to be confused :)
     
    So, AFAIK, the discussion is about SDP O/A usag= e in the API, only in the API, and nowhere but the API.
     
    Whatever people us on the wire is outside the s= cope.
     
    Right?
     
    Regards,
     
    Christer
     


    Sent from Windows using TouchDown= (www.nitrodesk.com<= /a>)

    -----Original Message-----
    From: Peter Thatcher [    pthatcher@google.com]
    To: Martin Thomson [martin.thomson@gmail.com]
    CC: rtcweb@ietf= .org [rtcweb@ietf.= org]
    Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate t= o be re-opened
    Martin, you're right; that was overly harsh of me.  A= dam, I apologize.  I'll be civil in the future.


    On Tue, Jun 18, 2013 at 3:25 PM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
    I agree with Peter, except for this bit:

    On 18 June 2013 15:16, Peter Thatcher <pthatcher@google.com> wrote:
    > Adam, I think you're confused.

    Adam is much harder to confuse than you think, or than he professes.

    Speaking of burning it all down and starting over.  If you want a
    house-related analogy, that's not quite correct.  It's refusing to
    build an extension because the old house, while legally fit for
    habitation, is falling down around your ears.  Since you only need
    foundations, it's not that big a job (though I'll grant you that it's
    bigger than many people realize, even with that smaller scope).


    --_000_7594FB04B1934943A5C02806D1A2204B1C3AE7CFESESSMB209erics_-- From ibc@aliax.net Wed Jun 19 01:39:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9ABD21F9FAC for ; Wed, 19 Jun 2013 01:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ws-6PQZrXYtu for ; Wed, 19 Jun 2013 01:38:56 -0700 (PDT) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id A3D8921F9FAA for ; Wed, 19 Jun 2013 01:38:56 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id 1so3052741qee.26 for ; Wed, 19 Jun 2013 01:38: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=d/giM1N8zS5DzALVy2vZymyDZswiFMMHCdyBIy+fqUc=; b=KCdkmGjkRhvVmsc0rk2t0B5GedthehU9rJybqrj5oDdqb3vzZFxtCHAM3Wf/oEuJzA qmMbfbYLG60DlnFJMjzGFrhJ6BvTr84qbyl3lmEHKJx1x3fUSaCmNKvsRDEq7P0ayFaq wx29DqxpCfFOFqGMdz+CRujXq1oaAYhFZrA+ryfVonL0towj3epFzB4wjv9mYlP4oSFX xKMkGCUlE+45xKciLA0dwFPG7Tj1KlUmYbnTvN7etFEgOG7J0Qae7vo4YRPXuMJsc+si 7U2RNEElcantRbxhkPyccVugk074qL48/HZgQNfTdp0ZRdMKBKOYSmHjEua6ch6ggaLD PGEw== X-Received: by 10.49.81.244 with SMTP id d20mr2085171qey.33.1371631135971; Wed, 19 Jun 2013 01:38:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 01:38:35 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 19 Jun 2013 10:38:35 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk2lWwj0pFHuSIRgcCl8hWFAfxDESdsnubHgKP+p9YXNFDfPbfQ0fdvTim61/U9C3S3+5ob Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 08:39:01 -0000 2013/6/19 Christer Holmberg : > We need to be very clear what we talk about, or some people are always go= ing > to be confused :) > > So, AFAIK, the discussion is about SDP O/A usage in the API, only in the > API, and nowhere but the API. > > Whatever people us on the wire is outside the scope. Hi Christer, I do not dare to summarize what we request in a single response, and I don't want to say something that "I didn't want to say" ;) IMHO this thread clearly describes what we request, i.e. in these exact mai= ls: - http://www.ietf.org/mail-archive/web/rtcweb/current/msg07895.html - http://www.ietf.org/mail-archive/web/rtcweb/current/msg07896.html - http://www.ietf.org/mail-archive/web/rtcweb/current/msg07899.html My "non-normative" summary: I don't think that the discussion is just about "SDP O/A usage in the API". We don't want a replacement for SDP, nor a new representation of SDP, nor to deal with blob strings between the JS layer and the WebRTC layer. In short we want something like a JS wrapper of the native WebRTC API, to directly manage media/transport parameters and media streams without having to pass a monolithic and unmanageable SDP blob between the JS and the WebRTC layer. And once the JS makes all the API calls to get the required media parameters, the JS can send them to the remote peer in the way it prefers (which may be via a SDP created by the JS app, or via an AJAX request for sending codecs/media-types info followed by a WebSocket connection for sending ICE candidates one by one, or serialized in JSON via a previously open DataChannel session... or whatever mechanism available in the Web and browsers). For sure, other participants in this thread can improve/fix my "summary". Please. re-read the 3 links above, IMHO they should clearly describe what we are requesting for :) Best regards. -- I=C3=B1aki Baz Castillo From prvs=58822a6647=christer.holmberg@ericsson.com Wed Jun 19 01:42:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3446121F9FB9 for ; Wed, 19 Jun 2013 01:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.629 X-Spam-Level: X-Spam-Status: No, score=-5.629 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksmUU+I0RqcC for ; Wed, 19 Jun 2013 01:42:05 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B07D921F9E88 for ; Wed, 19 Jun 2013 01:42:04 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-58-51c16edbaffc Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D9.BE.15700.BDE61C15; Wed, 19 Jun 2013 10:42:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 10:42:03 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Thread-Index: AQHObEI/LKM23biSMEicZL6ip01H1Jk7xwcAgAACKQCAAB+igIAAApYAgAB4ZYCAADHZMIAAARSAgAAh3BA= Date: Wed, 19 Jun 2013 08:42:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3AEA92@ESESSMB209.ericsson.se> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@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.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvre7tvIOBBjP2SFlM32djsfZfO7sD k8e5hvfsHkuW/GQKYIritklKLCkLzkzP07dL4M64cmUPU8EkqYpdb5exNjDukexi5OSQEDCR aNy1kxnCFpO4cG89WxcjF4eQwGFGiT9tuxghnEWMEqfnT2XqYuTgYBOwkOj+pw3SICJgI/Hv wgV2EJtZQFXi/KFzjCC2sICHxO1ne1lAykUEPCWWn62CKE+SaLt9F6yEBaj86envYHt5BXwl fkyczwJiCwnMYJHYcNMKxOYUCJS4dO8eWD0j0G3fT61hglglLnHryXwmiJsFJJbsOQ91v6jE y8f/WEHWSggoSizvlwMxmQU0Jdbv0ofoVJSY0v2QHWKroMTJmU9YJjCKzUIydBZCxywkHbOQ dCxgZFnFyJ6bmJmTXm64iREYGwe3/NbdwXjqnMghRmkOFiVx3g+ndgUKCaQnlqRmp6YWpBbF F5XmpBYfYmTi4AQRXFINjEkqOQ3Xz23SEolcsc7sZrxhLt+12zV3KnZlNFsu+OSr7dTjurvP NUzh+ISrnyMKm+L8w26+4V11bOFEv/q7b/ierWtdfGsrz8ed4iWy66ZXxz/wD5GbMmHblK1P Q9kmrpv/Tvr8xUfd/9mPhF/4nLb/eP8sN4t/cbnrl/tXhX/I4ov2Sf29VVqJpTgj0VCLuag4 EQCWsNJuYAIAAA== Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 08:42:10 -0000 ScOxYWtpLA0KDQpZb3UgYXJlIHRoZSBvbmUgd2hvIHJlcXVlc3RlZCB0aGUgZGViYXRlIHRvIGJl IHJlLW9wZW5lZC4gQXJlIHlvdSBzYXlpbmcgdGhhdCBJIG5lZWQgdG8gZ28gdGhyb3VnaCBwcmV2 aW91cyBkaXNjdXNzaW9ucyB0byBmaWd1cmUgb3V0IHdoYXQgeW91IHdhbnQgdG8gZGViYXRlIC0g b3IgdG8gZmlndXJlIG91dCB3aGF0IHlvdSBUSElOSyB5b3Ugd2FudCB0byBkZWJhdGU/IDopDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86aWJjQGFsaWF4Lm5ldF0gDQpTZW50OiAxOS4g a2Vzw6RrdXV0YSAyMDEzIDExOjM5DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcNCkNjOiBydGN3ZWJf aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBSZXF1ZXN0aW5nICJTRFAgb3Igbm90IFNE UCIgZGViYXRlIHRvIGJlIHJlLW9wZW5lZA0KDQoyMDEzLzYvMTkgQ2hyaXN0ZXIgSG9sbWJlcmcg PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT46DQo+IFdlIG5lZWQgdG8gYmUgdmVyeSBj bGVhciB3aGF0IHdlIHRhbGsgYWJvdXQsIG9yIHNvbWUgcGVvcGxlIGFyZSBhbHdheXMgDQo+IGdv aW5nIHRvIGJlIGNvbmZ1c2VkIDopDQo+DQo+IFNvLCBBRkFJSywgdGhlIGRpc2N1c3Npb24gaXMg YWJvdXQgU0RQIE8vQSB1c2FnZSBpbiB0aGUgQVBJLCBvbmx5IGluIA0KPiB0aGUgQVBJLCBhbmQg bm93aGVyZSBidXQgdGhlIEFQSS4NCj4NCj4gV2hhdGV2ZXIgcGVvcGxlIHVzIG9uIHRoZSB3aXJl IGlzIG91dHNpZGUgdGhlIHNjb3BlLg0KDQoNCkhpIENocmlzdGVyLA0KDQpJIGRvIG5vdCBkYXJl IHRvIHN1bW1hcml6ZSB3aGF0IHdlIHJlcXVlc3QgaW4gYSBzaW5nbGUgcmVzcG9uc2UsIGFuZCBJ IGRvbid0IHdhbnQgdG8gc2F5IHNvbWV0aGluZyB0aGF0ICJJIGRpZG4ndCB3YW50IHRvIHNheSIg OykNCg0KSU1ITyB0aGlzIHRocmVhZCBjbGVhcmx5IGRlc2NyaWJlcyB3aGF0IHdlIHJlcXVlc3Qs IGkuZS4gaW4gdGhlc2UgZXhhY3QgbWFpbHM6DQoNCi0gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50L21zZzA3ODk1Lmh0bWwNCi0gaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50L21zZzA3ODk2Lmh0bWwNCi0g aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50L21zZzA3 ODk5Lmh0bWwNCg0KDQpNeSAibm9uLW5vcm1hdGl2ZSIgc3VtbWFyeToNCg0KSSBkb24ndCB0aGlu ayB0aGF0IHRoZSBkaXNjdXNzaW9uIGlzIGp1c3QgYWJvdXQgIlNEUCBPL0EgdXNhZ2UgaW4gdGhl IEFQSSIuIFdlIGRvbid0IHdhbnQgYSByZXBsYWNlbWVudCBmb3IgU0RQLCBub3IgYSBuZXcgcmVw cmVzZW50YXRpb24gb2YgU0RQLCBub3IgdG8gZGVhbCB3aXRoIGJsb2Igc3RyaW5ncyBiZXR3ZWVu IHRoZSBKUyBsYXllciBhbmQgdGhlIFdlYlJUQyBsYXllci4gSW4gc2hvcnQgd2Ugd2FudCBzb21l dGhpbmcgbGlrZSBhIEpTIHdyYXBwZXIgb2YgdGhlIG5hdGl2ZSBXZWJSVEMgQVBJLCB0byBkaXJl Y3RseSBtYW5hZ2UgbWVkaWEvdHJhbnNwb3J0IHBhcmFtZXRlcnMgYW5kIG1lZGlhIHN0cmVhbXMg d2l0aG91dCBoYXZpbmcgdG8gcGFzcyBhIG1vbm9saXRoaWMgYW5kIHVubWFuYWdlYWJsZSBTRFAg YmxvYiBiZXR3ZWVuIHRoZSBKUyBhbmQgdGhlIFdlYlJUQyBsYXllci4gQW5kIG9uY2UgdGhlIEpT IG1ha2VzIGFsbCB0aGUgQVBJIGNhbGxzIHRvIGdldCB0aGUgcmVxdWlyZWQgbWVkaWEgcGFyYW1l dGVycywgdGhlIEpTIGNhbiBzZW5kIHRoZW0gdG8gdGhlIHJlbW90ZSBwZWVyIGluIHRoZSB3YXkg aXQgcHJlZmVycyAod2hpY2ggbWF5IGJlIHZpYSBhIFNEUCBjcmVhdGVkIGJ5IHRoZSBKUyBhcHAs IG9yIHZpYSBhbiBBSkFYIHJlcXVlc3QgZm9yIHNlbmRpbmcgY29kZWNzL21lZGlhLXR5cGVzIGlu Zm8gZm9sbG93ZWQgYnkgYSBXZWJTb2NrZXQgY29ubmVjdGlvbiBmb3Igc2VuZGluZyBJQ0UgY2Fu ZGlkYXRlcyBvbmUgYnkgb25lLCBvciBzZXJpYWxpemVkIGluIEpTT04gdmlhIGEgcHJldmlvdXNs eSBvcGVuIERhdGFDaGFubmVsIHNlc3Npb24uLi4gb3Igd2hhdGV2ZXIgbWVjaGFuaXNtIGF2YWls YWJsZSBpbiB0aGUgV2ViIGFuZCBicm93c2VycykuDQoNCkZvciBzdXJlLCBvdGhlciBwYXJ0aWNp cGFudHMgaW4gdGhpcyB0aHJlYWQgY2FuIGltcHJvdmUvZml4IG15ICJzdW1tYXJ5Ii4NCg0KUGxl YXNlLiByZS1yZWFkIHRoZSAzIGxpbmtzIGFib3ZlLCBJTUhPIHRoZXkgc2hvdWxkIGNsZWFybHkg ZGVzY3JpYmUgd2hhdCB3ZSBhcmUgcmVxdWVzdGluZyBmb3IgOikNCg0KDQpCZXN0IHJlZ2FyZHMu DQoNCg0KDQotLQ0KScOxYWtpIEJheiBDYXN0aWxsbw0KPGliY0BhbGlheC5uZXQ+DQo= From ibc@aliax.net Wed Jun 19 01:55:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A8821F9F9B for ; Wed, 19 Jun 2013 01:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9fiMq-TQ93Z for ; Wed, 19 Jun 2013 01:55:10 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id F387021F9F47 for ; Wed, 19 Jun 2013 01:55:09 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id n20so266203qaj.13 for ; Wed, 19 Jun 2013 01:55:09 -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=T9PcpmD2hmL2fHdbqeLSOnB3AoxbIO3jI+1UDw4tWLU=; b=e/eKggS/KKhLp+ruQZ9PJVQ9iXG/suLVL1EIDygWORkJHONr6MfB0vzXLJtKb3RsUY odYlgQIlEsQQTS9shhDy8V23rcGRQkEaad3jOsKOPjA+CJX4Al9b7EG33yb6harSmXlV A+Wje/pmxNkvBJAMcmH6R7aVp2COACstoG/EU/loFi+FzppZGh0yxg/t/k02G0pqT7om I7btrmXibhs1N3G7Ti6R1UTWS8kc7Z33xWsbJoT+BH3qMWhTN89u9WXUFjTTbnhiHuWw +DhjiKa+ONpEt8ce4IWzsNVpV0mBLc29VKdoHWy/WidAhIPE/Y0d3i6GWxwGTdaNj9Mj JlRg== X-Received: by 10.49.35.233 with SMTP id l9mr2179464qej.23.1371632109271; Wed, 19 Jun 2013 01:55:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 01:54:49 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3AEA92@ESESSMB209.ericsson.se> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3AEA92@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 19 Jun 2013 10:54:49 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkctVukTMPKSSEiRSSxxPqUSK2GGYskrgtiKeZFBlyO2QOT4wvz6jqRWpIzyaHP7sw8FbXT Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 08:55:11 -0000 2013/6/19 Christer Holmberg : > I=C3=B1aki, > > You are the one who requested the debate to be re-opened. Are you saying = that I need to go through previous discussions to figure out what you want = to debate - or to figure out what you THINK you want to debate? :) Hi Christer, As far as I see I not alone in this venture :) Anyhow, if others agree, take the paragraph in my previous mail (My "non-normative" summary) as a small summary of what we want to debate and propose. Regards. P.S: But IMHO the complete rationale for this request is better described in the 3 links I told you ;) -- I=C3=B1aki Baz Castillo From michelg@upperside.fr Wed Jun 19 04:56:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD3621F9BAF for ; Wed, 19 Jun 2013 04:56:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdXvlDJPh2mR for ; Wed, 19 Jun 2013 04:56:46 -0700 (PDT) Received: from smtp01.msg.oleane.net (smtp01.msg.oleane.net [62.161.4.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8E621F9BA4 for ; Wed, 19 Jun 2013 04:56:45 -0700 (PDT) Received: from MichelGosseDel (AAubervilliers-752-1-8-186.w90-35.abo.wanadoo.fr [90.35.219.186]) (authenticated) by smtp01.msg.oleane.net (MSA) with ESMTP id r5JBugMX005414 for ; Wed, 19 Jun 2013 13:56:43 +0200 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Wed, 19 Jun 2013 13:56:52 +0200 Message-ID: <004e01ce6ce4$16bbe900$4433bb00$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01CE6CF4.DA45F180" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5s4Vug8RiqGuuqQCWUje/EUOPmzw== Content-Language: fr X-PMX-Spam: Probability=8% X-PFSI-Info: PMX 5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.19.114218 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [rtcweb] WebRTC 2013 Paris: CFP for startup speed dating X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 11:56:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004F_01CE6CF4.DA45F180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Upperside is reaching out to startup companies or internal innovators at larger companies to propose their service or product to be presented at the conference. 5 finalists will be chosen to get on stage for 10 minutes each to pitch and demo their solution. Out of the 5 finalists one will win the best of show prize. More info: http://www.uppersideconferences.com/webrtc2013/webrtc2013intro.html ------=_NextPart_000_004F_01CE6CF4.DA45F180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Upperside is reaching out to startup companies or internal innovators = at larger companies to propose their service or product to be presented = at the conference.

    5 finalists will be chosen to get on stage for 10 minutes each to = pitch and demo their solution. Out of the 5 finalists one will win the = best of show prize.

    More info: http://www.uppersideconferences.com/webrtc2013/webrtc2013intro.html

     

    ------=_NextPart_000_004F_01CE6CF4.DA45F180-- From michael@voip.co.uk Wed Jun 19 05:26:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B412F21F9113 for ; Wed, 19 Jun 2013 05:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oOj0fAkxoQD for ; Wed, 19 Jun 2013 05:25:59 -0700 (PDT) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) by ietfa.amsl.com (Postfix) with SMTP id 4456021F8CDD for ; Wed, 19 Jun 2013 05:25:59 -0700 (PDT) Received: from mail-wi0-f173.google.com ([209.85.212.173]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKUcGjVgFhtoPDn7or0Y/frUx1Sgjlvwcz@postini.com; Wed, 19 Jun 2013 05:25:59 PDT Received: by mail-wi0-f173.google.com with SMTP id hq4so609694wib.12 for ; Wed, 19 Jun 2013 05:25: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=EBPMR8wpwbBuuaEye0HBb7teU/K6Ya3yaEgWu+SoLSY=; b=caSKazLiT4Vxym0x9ORYP2aawMVO2IF8cwlOrvFKfDP1hu9hLxRSmzHmYrefXQOpIK o5jWmXGDwLXQs8w8ruGlcL/sBn+f3GR4lpy6sbqLyWBEiKZzu/9Q+s7Kj25aHY1LRBwb VYqyNqiRR0snYL9lcSek70PWm+8IlTqk0SUbVnPaTA0lSaDP9kcEfhuf6VC5IOzqdLzK bQO0Kcx77Od+hFBCrZEY44YUk2KbvzblxQb+03xXPoGQ3zSHRcZt8t8R9j04Q0Q8dpkb hcS8psiUuu/+xYIfBlDhamRS+D9yLT0keGSOZvqULCtL05Mayn6zBzy0q+RoAqolHIya dDyA== X-Received: by 10.194.103.73 with SMTP id fu9mr1983110wjb.70.1371644757440; Wed, 19 Jun 2013 05:25:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.103.73 with SMTP id fu9mr1983106wjb.70.1371644757378; Wed, 19 Jun 2013 05:25:57 -0700 (PDT) Received: by 10.194.164.234 with HTTP; Wed, 19 Jun 2013 05:25:57 -0700 (PDT) In-Reply-To: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> Date: Wed, 19 Jun 2013 13:25:57 +0100 Message-ID: From: Michael Procter To: "Matthew Kaufman (SKYPE)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlxQA8S0EO5TftBdg7hVLm88vBK6pEYqkoOANGztlbF5gUqXDqgQm046iFZYpvYJnNRFU0PlRig6h35C/8WOjmCSG0VXbqeZCulJl4VaZG071R77aBCbXv79FBpWLDNf+8twYk5QYmmq8uSk19l2fSimsGtcg== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 12:26:19 -0000 On 18 June 2013 22:16, Matthew Kaufman (SKYPE) wrote: > Your diagram is missing the part where the browser either learns the key > that it is supposed to ask EKT to set or tells your SIP/SDES side what > key it set using EKT. Either way, those keys go over HTTPS to/from the > browser, yes? I don't understand this part of your argument. I was under the impression that using DTLS-EKT meant we could avoid having keying information visible to Javascript in the browser whilst still interoperating with legacy SRTP UAs that determine their own transmission keys. In your example, I thought it would work like this: your PBX <-(SDES in SIP)-> my sip server <-(??)-> my media relay <-(DTLS-EKT)-> browser The PBX chooses its transmission key, and advertises it through SDES/SDP. The browser chooses its transmission key and advertises it through DTLS-EKT. The media gateway has the job of matching up the SDES pieces with the EKT pieces, and thereafter forwarding packets. Yes, there is some call control coordination to do between the web server and the sip server/media relay, but no keying information needs to pass to the web server, nor on to the Javascript running in the browser. Have I missed a use-case? Is there a requirement to set the browser's transmission key to a specific value (in which case, you are correct that it would have to pass over HTTPS at least) too? Regards, Michael From harald@alvestrand.no Wed Jun 19 05:33:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A939621F9C1E for ; Wed, 19 Jun 2013 05:33:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3w6FWoo+op2 for ; Wed, 19 Jun 2013 05:33:21 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B2FF721F9C19 for ; Wed, 19 Jun 2013 05:33:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0F82039E1C4 for ; Wed, 19 Jun 2013 14:33: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 oPbYDDHywEN6 for ; Wed, 19 Jun 2013 14:33:17 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B615739E1C2 for ; Wed, 19 Jun 2013 14:33:17 +0200 (CEST) Message-ID: <51C1A50D.2010703@alvestrand.no> Date: Wed, 19 Jun 2013 14:33:17 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51BFFB65.2020203@jitsi.org> <51C051AB.6030505@makk.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 12:33:27 -0000 On 06/19/2013 04:35 AM, Silvia Pfeiffer wrote: > On Tue, Jun 18, 2013 at 10:25 PM, Max Jonas Werner wrote: >> Hej Silvia, >> >> On 18.06.2013 08:25, Silvia Pfeiffer wrote:> On Tue, Jun 18, 2013 at >> 4:17 PM, Emil Ivov wrote: >>>> On 18.06.13, 03:00, Silvia Pfeiffer wrote: >>>>> What I would like to see, though, is a bit different from what you've >>>>> proposed. In particular, the MediaFlowDescription object is the one >>>>> object that I believe is supposed to enable JS developers to do "SDP >>>>> hacking" without having to understand SDP. Unfortunately, the way in >>>>> which it is currently written, this API doesn't help a JS developer >>>>> much. There are properties in that object like "ssrc" that mean >>>>> nothing unless you understand SDP. >>>> SSRC is really just a flow identifier and it actually comes from RTP, not >>>> SDP. >>> OK, could we call it rtpflowId or mediaflowId or peerflowId or >>> something? And what exactly are the other identifiers? >>> (You will notice that I am really naive wrt SDP, sorry!) >> Do you really want to create a second "terminology world"? For people >> who don't know what SSRC means (because they don't know RTP) it may seem >> reasonable but to those who already know RTP you'd have to explain >> "yeah, rtpflowId is actually SSRC." So the term SSRC would have to be >> included in the spec anyway. > You can leave mention of SSRC to a comment in the spec next to rtpflowId. > >> I'm not sure if having different names for the same thing would lead to >> less confusion. > If SSRC is the name it's given in SDP and we want to get away from > SDP, this would be a first step, wouldn't it? SSRC is the name it's given in RTP, and we have (so far) had consensus on using RTP. From silviapfeiffer1@gmail.com Wed Jun 19 05:37:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0780C21F9374 for ; Wed, 19 Jun 2013 05:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8IOMygkRnkp for ; Wed, 19 Jun 2013 05:37:54 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0015621F9C02 for ; Wed, 19 Jun 2013 05:37:33 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id ef5so5991986obb.29 for ; Wed, 19 Jun 2013 05:37: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:from:date:message-id:subject:to :cc:content-type; bh=OjkqjfksbweqgMLfkH7nwaPbMdQFccqKijlorpgAyu0=; b=SNlLa2u4/tlGaybzteS5o/tvjZNWUpiK/MB1KFyCp8Xku/D4DmN/3x96ePJhJHm17a 9PSqHowCp3+ZJb4DMSWSXn01M9k16PVwSfC+PEadIQWhZm/9S71JbQB9BDryWSZww7z+ 18EBATqEzXIwSA5ByFZv2XF3JvfdYXxAcSmuyAawvCLHXpMvx1NWMmJ4Mz0gr5MkLSPx K0rRo9FuhJgc9kJ9PnKz+x3UsRvHIADxNt+ABWJQABqrrAJK5xlOuHblJA50PecoJNf0 06ygp06gJwnFyNSJu05rIzv0qqqbAy5NAl8FoY31M49mT3GZ3UIYGZTaz+/IdEDKXteg Qv7g== X-Received: by 10.60.162.98 with SMTP id xz2mr1913192oeb.7.1371645446643; Wed, 19 Jun 2013 05:37:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.116.71 with HTTP; Wed, 19 Jun 2013 05:37:06 -0700 (PDT) In-Reply-To: <51C1A50D.2010703@alvestrand.no> References: <51BFFB65.2020203@jitsi.org> <51C051AB.6030505@makk.es> <51C1A50D.2010703@alvestrand.no> From: Silvia Pfeiffer Date: Wed, 19 Jun 2013 22:37:06 +1000 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 12:37:55 -0000 On Wed, Jun 19, 2013 at 10:33 PM, Harald Alvestrand wrote: > On 06/19/2013 04:35 AM, Silvia Pfeiffer wrote: >> >> On Tue, Jun 18, 2013 at 10:25 PM, Max Jonas Werner wrote: >>> >>> Hej Silvia, >>> >>> On 18.06.2013 08:25, Silvia Pfeiffer wrote:> On Tue, Jun 18, 2013 at >>> 4:17 PM, Emil Ivov wrote: >>>>> >>>>> On 18.06.13, 03:00, Silvia Pfeiffer wrote: >>>>>> >>>>>> What I would like to see, though, is a bit different from what you've >>>>>> proposed. In particular, the MediaFlowDescription object is the one >>>>>> object that I believe is supposed to enable JS developers to do "SDP >>>>>> hacking" without having to understand SDP. Unfortunately, the way in >>>>>> which it is currently written, this API doesn't help a JS developer >>>>>> much. There are properties in that object like "ssrc" that mean >>>>>> nothing unless you understand SDP. >>>>> >>>>> SSRC is really just a flow identifier and it actually comes from RTP, >>>>> not >>>>> SDP. >>>> >>>> OK, could we call it rtpflowId or mediaflowId or peerflowId or >>>> something? And what exactly are the other identifiers? >>>> (You will notice that I am really naive wrt SDP, sorry!) >>> >>> Do you really want to create a second "terminology world"? For people >>> who don't know what SSRC means (because they don't know RTP) it may seem >>> reasonable but to those who already know RTP you'd have to explain >>> "yeah, rtpflowId is actually SSRC." So the term SSRC would have to be >>> included in the spec anyway. >> >> You can leave mention of SSRC to a comment in the spec next to rtpflowId. >> >>> I'm not sure if having different names for the same thing would lead to >>> less confusion. >> >> If SSRC is the name it's given in SDP and we want to get away from >> SDP, this would be a first step, wouldn't it? > > > SSRC is the name it's given in RTP, and we have (so far) had consensus on > using RTP. Ah ok, I thought it was a SDP parameter. S. From sergio.garcia.murillo@gmail.com Wed Jun 19 06:13:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874C721F9C22 for ; Wed, 19 Jun 2013 06:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EJR4+h9tLmP for ; Wed, 19 Jun 2013 06:13:26 -0700 (PDT) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE1B21F9C20 for ; Wed, 19 Jun 2013 06:13:26 -0700 (PDT) Received: by mail-bk0-f42.google.com with SMTP id jk13so2378336bkc.29 for ; Wed, 19 Jun 2013 06:13:25 -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; bh=w0r4Ds4LwAuXDPmw9TpTyZH3YNgRchkbvGGPfdrqydU=; b=RP/17b8n76al1ns0gCX7yphz++X/CD9S7uNWOba9XqQc33FQJkAskHW/BZu5uTMhjB 1I48n7eZVb3u5329XHPg2ZA6zz8A8pr5M5fuv7ypikb3xBCS/eUFcEvNLkKfdno8RVs1 0g82ZSgROoutciNUyHFjY8P015C9Qn6YyN2SVNAfS5Klnnl8vqF6EqXTEcthovlWMagD 0C4114lqpr36fzqhtdghicTFIeFZtmNZUsGh0vWPHdgSs5D6iznur5jGi47BN5Y2AWQo gvSB0f89SzcmAUV8/SfMar7PqvrhFE/O9zlGJJgCkTr0f/UW/XEvj7ceW4jdI25xhJwp WZGA== X-Received: by 10.204.53.3 with SMTP id k3mr378697bkg.152.1371647605248; Wed, 19 Jun 2013 06:13:25 -0700 (PDT) Received: from [192.168.1.53] (45.Red-83-53-66.dynamicIP.rima-tde.net. [83.53.66.45]) by mx.google.com with ESMTPSA id oy6sm7921956bkb.14.2013.06.19.06.13.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 06:13:24 -0700 (PDT) Message-ID: <51C1AE77.5010105@gmail.com> Date: Wed, 19 Jun 2013 15:13:27 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51C0269B.5070200@telecomitalia.it> <51C069CD.6000804@hookflash.com>, In-Reply-To: Content-Type: multipart/alternative; boundary="------------080601090804040605060205" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 13:13:27 -0000 This is a multi-part message in MIME format. --------------080601090804040605060205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit To be fair, that use case should already had been resolved much more easily long time ago:
    It isn't SDP that's the problem. It is the offer/answer semantics.

    Here's a real simple example of the problem: If I have a web browser that can do RTP A/V, I should be able to send a form post or XHR to ask my security camera to start streaming me RTP video to a specific address and port. The browser doesn't need to do ICE connectivity tests, because it is only going to receive video.

    I should be able to use a few lines of JavaScript to initialize the UDP/RTP receive port and wire it to a video window, set up the codec mapping, and ask it for its local address and port so I can tell the camera where to send things. But that isn't how it works at all. Instead I need to run, in JavaScript, the entire offer/answer exchange from the security camera's point of view, extract the relevant information from the SDP blob, and then send it off. (Never mind that I also need to have DTLS-SRTP added to my camera, even though I'm sending unencrypted RTP from it all over the rest of my LAN to other receivers that aren't browsers)

    Same thing if I have a two-way radio system that can talk RTP and ICE and which has its own proprietary way of setting up connections... again, need to write a whole SDP parser *and* state machine to run the "fake" offer/answer exchange. 

    Pain. In. The. Ass.

    Matthew Kaufman

    From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Iñaki Baz Castillo [ibc@aliax.net]
    Sent: Tuesday, June 18, 2013 7:48 AM
    To: rtcweb@ietf.org
    Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

    2013/6/18 Robin Raymond <robin@hookflash.com>
    SDP is clearly the WRONG technical choice. It was wrong from the start but I think there was a great misunderstanding that it was required or SIP wouldn't be compatible with WebRTC. Since the strong majority at the table were SIP guys because they are the "established" industry it became the 'way to do it' despite how horrible it is for the future. So here we are today...


    Dear WG Chairs,

    With all due respect, IMHO there is enough material to reopen the "SDP or not SDP" debate so I would like to request it to the WG.

    I would also appreciate that those in favour of mandating SDP as the core communication for WebRTC explain their rationale again (given the number of arguments against SDP and the frustration SDP is causing), and also that they give arguments and responses to all the SDP related issues exposed in this thread, that are nicely summarized in this mail:



    Really thanks a lot.


    --
    Iñaki Baz Castillo
    <ibc@aliax.net> 


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

    --------------080601090804040605060205-- From bernard_aboba@hotmail.com Wed Jun 19 06:46:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F297C21F9649 for ; Wed, 19 Jun 2013 06:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZhUrE5Z6iqb for ; Wed, 19 Jun 2013 06:46:07 -0700 (PDT) Received: from blu0-omc1-s31.blu0.hotmail.com (blu0-omc1-s31.blu0.hotmail.com [65.55.116.42]) by ietfa.amsl.com (Postfix) with ESMTP id E57D021F9263 for ; Wed, 19 Jun 2013 06:46:06 -0700 (PDT) Received: from BLU169-W121 ([65.55.116.7]) by blu0-omc1-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jun 2013 06:46:06 -0700 X-TMN: [kDzEQC7M1QAphhHAQ0RCRTZIayhmT4Vm] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_dea97f7c-f593-4285-a085-dcd72ca85531_" From: Bernard Aboba To: Michael Procter Date: Wed, 19 Jun 2013 06:46:06 -0700 Importance: Normal In-Reply-To: References: , , , <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com>, <51BAC9BC.6070708@ericsson.com>, <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com>, <51C02EE8.5070809@ericsson.com>, , , , MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jun 2013 13:46:06.0952 (UTC) FILETIME=[59306680:01CE6CF3] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 13:46:14 -0000 --_dea97f7c-f593-4285-a085-dcd72ca85531_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Michael said: >=20 > The PBX chooses its transmission key=2C and advertises it through > SDES/SDP. The browser chooses its transmission key and advertises it > through DTLS-EKT. The media gateway has the job of matching up the > SDES pieces with the EKT pieces=2C and thereafter forwarding packets. [BA] Since the PBX can only handle SDES=2C and the media server speaksDTLS/= SRTP-EKT=2C the media server needs to provide the DTLS/SRTP-EKTkey to the = SIP server so that it can be signaled to the PBX within SDES/SDP. Similarly= =2C the SIP server needs to provide the SDES key signaled by thePBX to the = media server so that it can communicate this in DTLS/SRTP-EKT. Therefore th= e PBX=2C media server=2C SIP server and browser endpoint end up possessing = the keys=2C which is less than ideal. = --_dea97f7c-f593-4285-a085-dcd72ca85531_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Michael said: =3B
    =
    >=3B
    >=3B The PBX chooses its transmission key=2C and advertis= es it through
    >=3B SDES/SDP. The browser chooses its transmission key= and advertises it
    >=3B through DTLS-EKT. The media gateway has the jo= b of matching up the
    >=3B SDES pieces with the EKT pieces=2C and there= after forwarding packets.

    [BA] Since the PBX can only han= dle SDES=2C and the media server speaks
    DTLS/SRTP-EKT=2C  =3B= the media server needs to provide the DTLS/SRTP-EKT
    key to the SI= P server so that it can be signaled to the PBX within SDES/SDP. =3B
    Similarly=2C the SIP server needs to provide the SDES key signaled b= y the
    PBX to the media server so that it can communicate this in = DTLS/SRTP-EKT. =3B
    Therefore the PBX=2C media server=2C SIP s= erver and browser endpoint =3B
    end up possessing the =3B<= span style=3D"font-size: 12pt=3B ">keys=2C which is less than ideal. = =3B
    = --_dea97f7c-f593-4285-a085-dcd72ca85531_-- From robin@hookflash.com Wed Jun 19 06:58:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69BF21F9BCC for ; Wed, 19 Jun 2013 06:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.696, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJ39S2gLrugg for ; Wed, 19 Jun 2013 06:58:37 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 37CD021F9C0B for ; Wed, 19 Jun 2013 06:58:37 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 16so13563642iea.31 for ; Wed, 19 Jun 2013 06:58:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=zy0AeMWQq5rke8oEd5iyCVXWltJ0y5yqbEY66Np9lUY=; b=o0WTTJaYjShCfroyqUlLAOxawjV+NghIQhkH6miA5l7k2639yT+PMQYfxzhydReRF0 YYeoZjkLrDAweesXksGF8XtTs5btT2J1jHyiG0EDpieiwNQFaFNRckcVg8e83Z27nv2J In8HXNDJtDJ0rM4rZ1gWd3sfczOOZkLy2XRFWNpQD7ewLMCOidvLZLbair2MLdcwsniG 0iwqvsxwoUz4Fm2QLO+q1t8hVIzNSkayXRHhXvPrwFFVvY8NqSMqnTZMl6f/fyd6gCFz Z83eKz9DUliRML8ERa0PocIpnpW41o5IAmNGGHjTJYFqL2P5D5BkN2oW/uoNJ6truPH1 l0OQ== X-Received: by 10.50.26.40 with SMTP id i8mr10318913igg.20.1371650316637; Wed, 19 Jun 2013 06:58:36 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id vc13sm6276916igb.1.2013.06.19.06.58.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 06:58:35 -0700 (PDT) Message-ID: <51C1B907.8060508@hookflash.com> Date: Wed, 19 Jun 2013 09:58:31 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Peter Thatcher References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020804050002070508040504" X-Gm-Message-State: ALoCoQmWMtKwSAsRdSL3nMUw1A/fZSnvKd9G4fGiK0QfY+1I4Kt9F4kn+y5dksijoPEk7Dyf30rt Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 13:58:38 -0000 This is a multi-part message in MIME format. --------------020804050002070508040504 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit The trouble is not that we can choose to send whatever we want over the wire. I know we can. If the WebRTC API is left with SDP as it stands, I'll dissect the SDP from the browser, reinterpret and reconstruct on the SDP on the remote side. That is NOT the issue. The summary of what I want/believe: 1) I want as close to raw access to RTP/ICE streams, media, sources, outputs, codecs as viable. Obviously doing the actual transmission, encoding/decoding from JS is not feasible (yet), nor is secure [ICE must occur for mutual agreement to exchange data between peers], but having controls for how these components are wired together is extremely feasible from JS and would allow immensely powerful apps to be produced from JS. 2) I don't want my primary interface to control media/RTP engines to be via obtaining or providing SDPs to the browser (or any alternative serialized format); especially given that SDP requires a round trip offer/answer to the remote party to affect change (e.g. it's entirely possible to do that stateless and one-sided). The SPD interface API is a monolithic do-everything serialized format to control an engine but extremely badly/poorly/short sighted (regardless if it is SDP or whatever instead), and it's wholly unneeded. 3) I don't want a replacement for SDP with another more "pretty" format like JSON. 4) I want no specified requirement from the browser to have any particular form of media negotiation API requirement what-so-ever (regardless if I can opt to substitute with my own format on the wire or not) 5) Using SDP with offer/answer build into the browser binary is a horribly BAD technical choice (even for SIP folks) and must be stopped, see: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html I too want to understand the rational for keeping something as bad as SDP with offer/answer as the primary mechanism for controlling the media components and interaction to those component and more importantly, I'd too would like to open debate to agreeing or not to provide a lower layer API rather than a media negotiation API as a complete substitute alternative to SDP with offer/answer. If we can agree that it's far superior to have a lower level media/RTC component API rather than a media negotiation API, then we can propose what that API could look like (and there are people who have already have starting proposals). I'd throw my hat in the ring to propose such and API if necessary as I've written such engines from scratch before. But I don't want to waste time proposing ore reviewing such an API which will be summarily dismissed because people are so stuck on requiring a media negotiation API built into the browser binary, and specifically SDP with offer/answer in this case. Anyone who argues that they need/want that simple SDP media negotiation API must understand that a lower level API would allow a wrapper API to produce the same WebRTC API the have today but be built entirely from JavaScript upon a lower level API. Thus they can have their "just add-milk" baking API. But those of us who need control of the raw ingredients beyond the "just add milk" can still innovate. -Robin > Peter Thatcher > 19 June, 2013 2:49 AM > Correct my if I'm wrong, but the API already leaves what goes over the > wire completely up to the JS app. So we couldn't re-open a debate of > "SDP or not SDP" for the wire format, because there's nothing to > debate. We already decided it would be left to the JS to decide. The > only thing left to debate is the API. > > Or am I wrong? > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Christer Holmberg > 19 June, 2013 2:34 AM > Hi, > We need to be very clear what we talk about, or some people are always > going to be confused :) > So, AFAIK, the discussion is about SDP O/A usage in the API, only in > the API, and nowhere but the API. > Whatever people us on the wire is outside the scope. > Right? > Regards, > Christer > > > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Peter Thatcher [pthatcher@google.com] > *To:* Martin Thomson [martin.thomson@gmail.com] > *CC:* rtcweb@ietf.org [rtcweb@ietf.org] > *Subject:* Re: [rtcweb] Requesting "SDP or not SDP" debate to be > re-opened > Martin, you're right; that was overly harsh of me. Adam, I apologize. > I'll be civil in the future. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Peter Thatcher > 19 June, 2013 1:36 AM > Martin, you're right; that was overly harsh of me. Adam, I apologize. > I'll be civil in the future. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Martin Thomson > 18 June, 2013 6:25 PM > I agree with Peter, except for this bit: > > Adam is much harder to confuse than you think, or than he professes. > > Speaking of burning it all down and starting over. If you want a > house-related analogy, that's not quite correct. It's refusing to > build an extension because the old house, while legally fit for > habitation, is falling down around your ears. Since you only need > foundations, it's not that big a job (though I'll grant you that it's > bigger than many people realize, even with that smaller scope). > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Peter Thatcher > 18 June, 2013 6:16 PM > Adam, I think you're confused. As Ted pointed out, there are two > different uses of SDP: 1. as a control surface, 2. as a message > format for signalling. SDPNG was trying to replace SDP for #2. While > I believe this thread was started entirely focused on #1. So you're > talking about different things. > > So far the only time spent on trying to replace or avoid SDP for #1 > has been "comment 22", and to a lesser extent the proposal I just made > for adding 2 methods to PeerConnection (createLocalStream and > createRemoteStream). I think it's incorrect to conclude that we > should never try to improve #1 just because other in the past failed > to replace #2. They're very different. > > I also don't think we should burn down WebRTC and start over, but > despite what some seem to think, we don't have to choose between "burn > it down" and "never improve it". There are many options other than > the two extremes. > > > > By the way, a gentle reminder: SDP is not the only way to do #2. I > work on a rather large system almost entirely build around Jingle, > without a hint of SDP, and it works just fine. Much better than SDP > would have, I think. Just because SDPNG didn't work out doesn't mean > there will never be any way other to do signalling than SDP. > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------020804050002070508040504 Content-Type: multipart/related; boundary="------------060708060802060804060601" --------------060708060802060804060601 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
    The trouble is not that we can choose to send whatever we want over the wire. I know we can. If the WebRTC API is left with SDP as it stands, I'll dissect the SDP from the browser, reinterpret and reconstruct on the SDP on the remote side. That is NOT the issue.

    The summary of what I want/believe:
    1) I want as close to raw access to RTP/ICE streams, media, sources, outputs, codecs as viable. Obviously doing the actual transmission, encoding/decoding from JS is not feasible (yet), nor is secure [ICE must occur for mutual agreement to exchange data between peers], but having controls for how these components are wired together is extremely feasible from JS and would allow immensely powerful apps to be produced from JS.
    2) I don't want my primary interface to control media/RTP engines to be via obtaining or providing SDPs to the browser (or any alternative serialized format); especially given that SDP requires a round trip offer/answer to the remote party to affect change (e.g. it's entirely possible to do that stateless and one-sided). The SPD interface API is a monolithic do-everything serialized format to control an engine but extremely badly/poorly/short sighted (regardless if it is SDP or whatever instead), and it's wholly unneeded.
    3) I don't want a replacement for SDP with another more "pretty" format like JSON.
    4) I want no specified requirement from the browser to have any particular form of media negotiation API requirement what-so-ever (regardless if I can opt to substitute with my own format on the wire or not)
    5) Using SDP with offer/answer build into the browser binary is a horribly BAD technical choice (even for SIP folks) and must be stopped, see: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html

    I too want to understand the rational for keeping something as bad as SDP with offer/answer as the primary mechanism for controlling the media components and interaction to those component and more importantly, I'd too would like to open debate to agreeing or not to provide a lower layer API rather than a media negotiation API as a complete substitute alternative to SDP with offer/answer.

    If we can agree that it's far superior to have a lower level media/RTC component API rather than a media negotiation API, then we can propose what that API could look like (and there are people who have already have starting proposals). I'd throw my hat in the ring to propose such and API if necessary as I've written such engines from scratch before. But I don't want to waste time proposing ore reviewing such an API which will be summarily dismissed because people are so stuck on requiring a media negotiation API built into the browser binary, and specifically SDP with offer/answer in this case.

    Anyone who argues that they need/want that simple SDP media negotiation API must understand that a lower level API would allow a wrapper API to produce the same WebRTC API the have today but be built entirely from JavaScript upon a lower level API. Thus they can have their "just add-milk" baking API. But those of us who need control of the raw ingredients beyond the "just add milk" can still innovate.

    -Robin


    19 June, 2013 2:49 AM
    Correct my if I'm wrong, but the API already leaves what goes over the wire completely up to the JS app.  So we couldn't re-open a debate of "SDP or not SDP" for the wire format, because there's nothing to debate.  We already decided it would be left to the JS to decide.  The only thing left to debate is the API.  

    Or am I wrong?




    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    19 June, 2013 2:34 AM
    Hi,
     
    We need to be very clear what we talk about, or some people are always going to be confused :)
     
    So, AFAIK, the discussion is about SDP O/A usage in the API, only in the API, and nowhere but the API.
     
    Whatever people us on the wire is outside the scope.
     
    Right?
     
    Regards,
     
    Christer
     


    Sent from Windows using TouchDown (www.nitrodesk.com)
    -----Original Message-----
    From: Peter Thatcher [pthatcher@google.com]
    To: Martin Thomson [martin.thomson@gmail.com]
    CC: rtcweb@ietf.org [rtcweb@ietf.org]
    Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
    Martin, you're right; that was overly harsh of me.  Adam, I apologize.  I'll be civil in the future.



    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    19 June, 2013 1:36 AM
    Martin, you're right; that was overly harsh of me.  Adam, I apologize.  I'll be civil in the future.



    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    18 June, 2013 6:25 PM
    I agree with Peter, except for this bit:

    Adam is much harder to confuse than you think, or than he professes.

    Speaking of burning it all down and starting over. If you want a
    house-related analogy, that's not quite correct. It's refusing to
    build an extension because the old house, while legally fit for
    habitation, is falling down around your ears. Since you only need
    foundations, it's not that big a job (though I'll grant you that it's
    bigger than many people realize, even with that smaller scope).
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    18 June, 2013 6:16 PM
    Adam, I think you're confused.  As Ted pointed out, there are two different uses of SDP: 1.  as a control surface, 2. as a message format for signalling.  SDPNG was trying to replace SDP for #2.  While I believe this thread was started entirely focused on #1.  So you're talking about different things.

    So far the only time spent on trying to replace or avoid SDP for #1 has been "comment 22", and to a lesser extent the proposal I just made for adding 2 methods to PeerConnection (createLocalStream and createRemoteStream).   I think it's incorrect to conclude that we should never try to improve #1 just because other in the past failed to replace #2.  They're very different.

    I also don't think we should burn down WebRTC and start over, but despite what some seem to think, we don't have to choose between "burn it down" and "never improve it".  There are many options other than the two extremes.



    By the way, a gentle reminder: SDP is not the only way to do #2.  I work on a rather large system almost entirely build around Jingle, without a hint of SDP, and it works just fine.  Much better than SDP would have, I think.  Just because SDPNG didn't work out doesn't mean there will never be any way other to do signalling than SDP.




    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    --------------060708060802060804060601 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------060708060802060804060601-- --------------020804050002070508040504-- From pthatcher@google.com Wed Jun 19 07:58:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C878821F9BF0 for ; Wed, 19 Jun 2013 07:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjs5MjpgbXVl for ; Wed, 19 Jun 2013 07:58:29 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBBD21F9BEE for ; Wed, 19 Jun 2013 07:58:28 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc8so5159955pbc.18 for ; Wed, 19 Jun 2013 07:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IbxZtcDHXapTXFJs9Rhq32hHSwUa+IRDifxRXZGWRQU=; b=VFw9Trx20nrpYtFnFbzLKq9IaS76flgKAFCylktqe+vXBMJmJBZy25dPm7fw0Sf/02 uKnTVBWJ8p/s2ue0bxdCsuHziIaR3EeLxEV/HFhxWTlJWBiVPchFSNRalalPHf9H9+Wo fEU0Acu9jLq2tLFjmab9MNKTsnEBJSZNFoTesVpv38k6INTunxHB3ymd2W/shGfy4V2v U0scQ+FFUnKJAyi0KXcHHD3oW9dfah8KHBQwWO4vCoAlZ54wbTkb2WaPWA5xULh+W6Nc ET02/UtZx6A7cCANOTAH2OniZnM8CxAFdbJpWGOmbjiVfCRrxSQz55iRCen5Jsoh65DO FA6w== 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=IbxZtcDHXapTXFJs9Rhq32hHSwUa+IRDifxRXZGWRQU=; b=BxpxXRVoT0cxB9nRtv8yuKy4615Pu50OmCLzaBUU5cRzyE9TAwILDiwtRF3ikEFsxN xTWXt/xgSBHLsMjgg1vlfc3latT9TplrX0FEo+RK9LpHCpcqxc+5DeEBxdkuIcThwmfr iK3nEBZ1Gm1LbUVHANyCGyCPLOdSrXxWBcGmbdH6ax3EXCuxkVVGNwMUPabdvhyobM9G pf0AwBJ0EKuSagiqSKx2/cR39J8wEb+9xPHrfjQy6t3I/c6ILSDUlrJXXxLW9w+/XNM2 Mv7up6/wthIFoGvO+5BH+sq42cZN037GFYAUL1hiELe0SGRyH6gIbEsOL7BNu8OheC6/ mrHA== X-Received: by 10.66.251.202 with SMTP id zm10mr7223068pac.53.1371653905330; Wed, 19 Jun 2013 07:58:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 07:57:42 -0700 (PDT) In-Reply-To: References: <51BFCBE9.5070406@hookflash.com> From: Peter Thatcher Date: Wed, 19 Jun 2013 07:57:42 -0700 Message-ID: To: Silvia Pfeiffer Content-Type: multipart/related; boundary=047d7b15a385c84b8004df830f1e X-Gm-Message-State: ALoCoQm5P2m5Ftj2dzQ7HhbatlokGnCpXqRGHwxy9c5eJ4SRYPZVbLhk8r/vlY/3BaAE7UBA61Bw/UwgjRefGLnUjtPm+UZL6L931Uqmr4v6yyPMqG9vYYI++CbhjEPLD8yUrMnmlMcKfndaxRSNCu95MvyaviukIY5/N7TWEldY/orlnUPll2XQDGVxe7ZxSkq+Ndxf1odR Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 14:58:31 -0000 --047d7b15a385c84b8004df830f1e Content-Type: multipart/alternative; boundary=047d7b15a385c84b7f04df830f1d --047d7b15a385c84b7f04df830f1d Content-Type: text/plain; charset=UTF-8 On Mon, Jun 17, 2013 at 8:27 PM, Silvia Pfeiffer wrote: > > > On Tue, Jun 18, 2013 at 12:54 PM, Robin Raymond wrote: > >> >> I actually need access to the raw controls like SSRC, detailed ICE >> candidate control, encryption keying, etc, and as much control over how >> media should be controlled/behave as possible. Those things are extremely >> important for interoperability and signaling and have specific meaning for >> those who deal with that kind of stuff daily. >> > > Sure - but if you need to hack SDP directly, you're already able to do > that. > > > What we'd like is the same power as before (setting all these parameters) without parsing SDP and serializing SDP. My proposal allows (optionally) for just that for MediaStreams, but not for transports. > However, as a JavaScript developer, you likely need a simple high level >> API. Why should you care about all that low level junk? It's meaningless >> nonsense to you. >> >> Real-Time Communication is hard because there is a lot involved, >> especially if there is any kind of compatibility, advanced features or >> network control. Nobody wants a difficult API for the sake of being >> difficult, especially for a sleek language like JavaScript. It's more that >> it's just necessary if we audio/video people want to do some really cool >> features that work with new or existing platforms, devices and services. >> >> But we can have the best of both worlds! >> > > Agreed, that's what I'm after, but not as a library, but rather as part of > the WebRTC API. > I think the best the WebRTC API can do is make a clean API at the "right" abstraction level and then let libraries build on that. For example, a Jingle library or a p2p mesh library or a multiway video library. We can't expect the API to be all things to all people, nor can we expect it to be so high level that it precludes many useful use cases. > > > >> There are many people who are in this RTC domain who can wrap that lower >> level API to give very simple and easy to understand conceptual APIs that >> abstract that weird funky stuff away. I'd be one of those people to offer >> such a simpler library (along with many others I'm sure). >> > > I think you should write a proposal! > > >> In some way, it's not all that dissimilar with DOM and CSS3, etc.; jQuery >> and jQuery UI (and other libraries) create wrappers to make access and >> control easier but for those who need to raw control they have it. Most >> people use wrappers and toolkits when they are trying to do the standard >> stuff, but someone put together the APIs originally to make common use >> cases. >> > > jQuery was necessary because HTML did not evolve. Now that a lot of the > jQuery APIs have been added to HTML directly, you can even get away pretty > well without using jQuery. > > On a side note, I agree that SDP should go (and quickly) but it's not the >> format that's the problem. Granted, it is obtuse. But it's not just that; >> it's a monolithic do-everything offer/answer model that offers very little >> control and the API to control the browser's RTC is effectively via >> manipulation of the SDP. Yuck! Even if it were fancier and prettier JSON, >> it would still be an ugly do-everything monolithic object with a sketchy >> offer/answer model that is brittle and offered very little real-scenario >> controls for those whom need it. It's absolutely horrible and is in good >> need of quick deprecation. >> > > Right - by providing a higher level abstraction of it, you'd enable that > stuff underneath to be replaced. I don't have a good handle on SDP, so but > I think what is proposed can be improved. If you have any ideas on how to, > this would be a good time to help out, IMHO. > I think we can split the discussion of APIs into two separate parts: media streams and transports. For media streams, I think what I propose allows for JS apps to handle MediaStreams without SDP and without O/A, while working well with what we already have working. It's not just pretty JSON. It gives what I consider a clean API at approximately the "right" level of abstraction for MediaSteams. The other half of the equation is transports. I have some ideas on how that could be done in a clean API at the "right" abstraction, but I haven't proposed anything yet specifically because I don't want to blow everything up at once. I'd like to try and accomplish this incrementally. > Cheers, > Silvia. > > >> -Robin >> >> >> >> >> Silvia Pfeiffer >> 17 June, 2013 9:00 PM >> Hi Peter, all, >> >> I'm looking at all this from the view of a JS developer and I am >> really excited that there is movement in this space. Having hit my >> head hard against the limitations of the current WebRTC API and being >> forced to learn SDP to achieve some of the less common use cases, I'm >> feeling the pain. I am therefore happy to see that there is a proposal >> for a higher-level API with similarities to the Microsoft's CU-WebRTC >> proposal and I hope that together with Microsoft's input this can >> become a really useful API. >> >> What I would like to see, though, is a bit different from what you've >> proposed. In particular, the MediaFlowDescription object is the one >> object that I believe is supposed to enable JS developers to do "SDP >> hacking" without having to understand SDP. Unfortunately, the way in >> which it is currently written, this API doesn't help a JS developer >> much. There are properties in that object like "ssrc" that mean >> nothing unless you understand SDP. >> >> I would therefore like to recommend making the properties on the >> MediaFlowDescription more semantic - in particular giving them better >> names - such that a JS developer really doesn't have to understand SDP >> to create/change media flow descriptions. Can we find better names for >> id, transportId and ssrc that are more explicitly expressing what >> they stand for and when a JS developer would actually change them? >> >> It would be nice if the MediaFlowDescription was abstract enough such >> that in future it doesn't matter if SDP is actually underneath (with >> offer/answer), but that's not actually my main goal. What I'm after is >> an API that can be used without having to understand what is >> underneath. >> >> Thanks for listening and HTH, >> Silvia. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> Peter Thatcher >> 17 June, 2013 8:57 AM >> Google is in full support of "Plan B" for encoding multiple media sources >> in SDP, and would like to see the Plan A vs. Plan B decision resolved soon. >> Recently, though, a third option, called "NoPlan" has been proposed, but >> it lacked the details of what a JS API would look like for NoPlan. Cullen >> asked to see such an API proposal, and so I have worked with Emil to make >> one. He will be adding it to the NoPlan draft, but I will also include it >> in this email. >> >> Again, Google is in full support of "Plan B". But if Plan A vs. Plan B >> cannot be decided, then we support NoPlan with the following additions to >> the WebRTC JS API as an option that allows implementing either Plan A or >> Plan B in Javascript. And even if Plan A vs. Plan B is resolved, these >> API additions would still be a big improvement for those WebRTC >> applications that don't use SDP for signalling. >> >> It is a bit long because I have added many comments and examples, but the >> actually additions only include two new methods on PeerConnection and a few >> new dictionaries. So don't be overwhelmed :). >> >> >> >> Intro: This follows the model of createDataChannel, which has a JS method >> on PeerConnection that makes it possible to add data channels without going >> through SDP. Furthermore, just like createDataChannel allows 2 ways to >> handle neogitation (the "I know what I'm doing; Here's what I want to >> send; Let me signal everything" mode and the "please take care of it for >> me; send an OPEN message" mode), this also has 2 ways to handle >> negotiation (the "I know what I'm doing; Here's what I want to send; Let me >> signal everything" mode and the "please take care of it for me; send SDP >> back and forth" mode). >> >> Following the success of createDataChannel, this allows simple >> applications to Just Work and more advanced applications to easily control >> what they need to. In particular, it's possible to use this API to >> implement either Plan A or Plan B. >> >> // The following two method are added to RTCPeerConnection >> partial interface RTCPeerConnection { >> // Create a stream that is used to send a source stream. >> // The MediaSendStream.description can be used for signalling. >> // No media is sent until addStream(MediaSendStream) is called. >> LocalMediaStream createLocalStream(MediaStream sourceStream); >> >> // Create a stream that is used to receive media from the remote side, >> // given the parameters signalled from MedaiSendStream.description. >> MediaStream createRemoteStream(MediaStreamDescription description); >> } >> >> >> interface LocalMediaStream implements MediaStream { >> // This can be changed at any time, but especially before calling >> // PeerConnection.addStream >> attribute MediaStreamDescription description; >> } >> >> >> // Represents the parameters used to either send or receive a stream >> // over a PeerConnection. >> dictionary MediaStreamDescription { >> MediaStreamTrackDescription[] tracks; >> } >> >> >> // Represents the parameters used to either send or receive a track over >> // a PeerConnection. A track has many "flows", which can be grouped >> // together. >> dictionary MediaStreamTrackDescription { >> // Same as the MediaStreamTrack.id >> DOMString id; >> >> // Same as the MediaStreamTrack.kind >> DOMString kind; >> >> // A track can have many "flows", such as for Simulcast, FEC, etc. >> // And they can be grouped in arbitrary ways. >> MediaFlowDescription[] flows; >> MediaFlowGroup[] flowGroups; >> } >> >> // Represents the parameters used to either send or receive a "flow" >> // over a PeerConnection. A "flow" is a media that arrives with a >> // single, unique SSRC. One to many flows together make up the media >> // for a track. For example, there may be Simulcast, FEC, and RTX >> // flows. >> dictionay MediaFlowDescription { >> // The "flow id" must be unique to the track, but need not be unique >> // outside of the track (two tracks could both have a flow with the >> // same flow ID). >> DOMString id; >> >> // Each flow can go over its own transport. If the JS sets this to a >> // transportId that doesn't have a transport setup already, the >> // browser will use SDP negotiation to setup a transport to back that >> // transportId. If This is set to an MID in the SDP, then that MID's >> // transport is used. >> DOMString transportId; >> >> // The SSRC used to send the flow. >> unsigned int ssrc; >> >> // When used as receive parameters, this indicates the possible list >> // of codecs that might come in for this flow. For exmample, a given >> // receive flow could be setup to receive any of OPUS, ISAC, or PCMU. >> // When used as send parameters, this indicates that the first codec >> // should be used, but the browser can use send other codecs if it >> // needs to because of either bandwidth or CPU constraints. >> MediaCodecDescription[] codecs; >> } >> >> >> dictionary MediaFlowGroup { >> DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc >> DOMString[] flowids; >> } >> >> dictionary MediaCodecDescription { >> unsigned byte payloadType; >> DOMString name; >> unsigned int? clockRate; >> unsigned int? bitRate; >> // A grab bag of other fmtp that will need to be further defined. >> MediaCodecParam[] params; >> } >> >> dictionary MediaCodecParam { >> DOMString key; >> DOMString value; >> } >> >> >> Notes: >> >> - When LocalMediaStreams are added using addStream, onnegotiatedneeded is >> not called, and those streams are never reflected in future SDP exchanges. >> Indeed, it would be impossible to put them in the SDP without first >> resolving if that would be Plan A SDP or Plan B SDP. >> >> - Just like piles of attributes would need to be defined for Plan A and >> for Plan B, similar attributes would need to be defined here (Luckily, >> much work has already been done figuring out what those parameters are :). >> >> >> Pros: >> >> - Either Plan A or Plan B or could be implemented in Javascript using >> this API >> - It exposes all the same functionality to the Javascript as SDP, but in >> a much nicer format that is much easier to work with. >> - Any other signalling mechanism, such as Jingle or CLUE could be >> implemented using this API. >> - There is almost no risk of signalling glare. >> - Debugging errors with misconfigured descriptions should be much easier >> with this than with large SDP blobs. >> >> >> Cons: >> >> - Now there are two slightly different ways to add streams: by creating a >> LocalMediaStream first, and not. This is, however, analogous to setting >> "negotiated: true" in createDataChannel. On way is "Just Work", and the >> other is more advanced control. >> >> - All the options in MediaCodecDescription are a bit complicated. >> Really, this is only necessary because Plan A requires being able to >> specify codec parameters per SSRC, and set each flow on different >> transports. If we did not have this requirement, we could simplify. >> >> >> Example Usage: >> >> // Imagine I have MyApp, handles creating a PeerConnection, >> // signalling, and rendering streams. This is how the new API could be >> // used. >> var peerConnection = MyApp.createPeerConnection(); >> >> // On sender side: >> var stream = MyApp.getMediaStream(); >> var localStream = peerConnection.createSendStream(stream); >> sendStream.description = MyApp.modifyStream(localStream.description) >> MyApp.signalAddStream(localStream.description, function(response)) { >> if (!response.rejected) { >> // Media will not be sent. >> peerConnection.addStream(localStream); >> } >> } >> >> // On receiver side: >> MyApp.onAddStreamSignalled = function(streamDescription) { >> var stream = peerConnection.createReceiveStream(streamDescription); >> MyApp.renderStream(stream); >> } >> >> >> // In this exchange, the MediaStreamDescription signalled from the >> // sender to the receiver may have looked something like this: >> >> { >> tracks: [ >> { >> id: "audio1", >> kind: "audio", >> flows: [ >> { >> id: "main", >> transportId: "transport1", >> ssrc: 1111, >> codecs: [ >> { >> payloadType: 111, >> name: "opus", >> // ... more codec details >> }, >> { >> payloadType: 112, >> name: "pcmu", >> // ... more codec details >> }] >> }] >> }, >> { >> id: "video1", >> kind: "video", >> flows: [ >> { >> id: "sim0", >> transportId: "transport2", >> ssrc: 2222, >> codecs: [ >> { >> payloadType: 122, >> name: "vp8" >> // ... more codec details >> }] >> }, >> { >> id: "sim1", >> transportId: "transport2", >> ssrc: 2223, >> codecs: [ >> { >> payloadType: 122, >> name: "vp8", >> // ... more codec details >> }] >> }, >> { >> id: "sim2", >> transportId: "transport2", >> ssrc: 2224, >> codecs: [ >> { >> payloadType: 122, >> name: "vp8", >> // ... more codec details >> }] >> }, >> >> { >> id: "sim0fec", >> transportId: "transport2", >> ssrc: 2225, >> codecs: [ >> { >> payloadType: 122, >> name: "vp8", >> // ... >> }] >> }], >> flowGroups: [ >> { >> semantics: "SIM", >> ssrcs: [2222, 2223, 2224] >> }, >> { >> semantics: "FEC", >> ssrcs: [2222, 2225] >> }] >> }] >> } >> >> >> Constructive feedback is welcome :). >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --047d7b15a385c84b7f04df830f1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Mon, Jun 17, 2013 at 8:27 PM, Silvia Pfeiffer = <silviapf= eiffer1@gmail.com> wrote:


    On Tu= e, Jun 18, 2013 at 12:54 PM, Robin Raymond <robin@hookflash.com><= /span> wrote:

    I actually need access to the raw controls like SSRC, detailed ICE=20 candidate control, encryption keying, etc, and as much control over how=20 media should be controlled/behave as possible. Those things are=20 extremely important for interoperability and signaling and have specific meaning for those who deal with that kind of stuff daily.

    Sure - but if you need to hack SDP directly= , you're already able to do that.



    What we'd l= ike is the same power as before (setting all these parameters) without pars= ing SDP and serializing SDP. =C2=A0My proposal allows (optionally) for just= that for MediaStreams, but not for transports.
    =C2=A0
    However, as a JavaScript develope= r, you likely need a simple high level=20 API. Why should you care about all that low level junk? It's meaningles= s nonsense to you.

    Real-Time Communication is hard because there is a lot involved,=20 especially if there is any kind of compatibility, advanced features or=20 network control. Nobody wants a difficult API for the sake of being=20 difficult, especially for a sleek language like JavaScript. It's more= =20 that it's just necessary if we audio/video people want to do some reall= y cool features that work with new or existing platforms, devices and=20 services.

    But we can have the best of both worlds!
    Agreed, that's what I'm after, but not as a libra= ry, but rather as part of the WebRTC API.

    I think the best the WebRTC API can do is make a clean API a= t the "right" abstraction level and then let libraries build on t= hat. =C2=A0For example, a Jingle library or a p2p mesh library or a multiwa= y video library. =C2=A0We can't expect the API to be all things to all = people, nor can we expect it to be so high level that it precludes many use= ful use cases.
    =C2=A0
    =C2= =A0
    =
    =C2=A0
    There are many= =20 people who are in this RTC domain who can wrap that lower level API to=20 give very simple and=20 easy to understand conceptual APIs that abstract that weird funky stuff=20 away. I'd be one of those people to offer such a simpler library (along= =20 with many others I'm sure).

    I think you should write a proposal!
    =C2=A0
    In some way, it's not a= ll that dissimilar with DOM and CSS3, etc.;=20 jQuery and jQuery UI (and other libraries) create wrappers to make=20 access and control easier but for those who need to raw control they=20 have it. Most people use wrappers and toolkits when they are trying to=20 do the standard stuff, but someone put together the APIs originally to=20 make common use cases.

    jQuery was necessary because HTML did not evolve. Now that a lot of the = jQuery APIs have been added to HTML directly, you can even get away pretty = well without using jQuery.

    <= span>On a side note, I agree that SDP should go (and quickly) but it's = not=20 the format that's the problem. Granted, it is obtuse. But it's not = just=20 that; it's a monolithic do-everything offer/answer model that offers=20 very little control and the API to control the browser's RTC is=20 effectively via manipulation of the SDP. Yuck! Even if it were fancier=20 and prettier JSON, it would still be an ugly do-everything monolithic=20 object with a sketchy offer/answer model that is brittle and offered=20 very little real-scenario controls for those whom need it. It's=20 absolutely horrible and is in good need of quick deprecation.

    Right - by providing a higher lev= el abstraction of it, you'd enable that stuff underneath to be replaced= . I don't have a good handle on SDP, so but I think what is proposed ca= n be improved. If you have any ideas on how to, this would be a good time t= o help out, IMHO.

    I think we can split the discussion = of APIs into two separate parts: media streams and transports. =C2=A0For me= dia streams, I think what I propose allows for JS apps to handle MediaStrea= ms without SDP and without O/A, while working well with what we already hav= e working. =C2=A0It's not just pretty JSON. =C2=A0It gives what I consi= der a clean API at approximately the "right" level of abstraction= for MediaSteams.


    The other half of the equation is transp= orts. =C2=A0I have some ideas on how that could be done in a clean API at t= he "right" abstraction, but I haven't proposed anything yet s= pecifically because I don't want to blow everything up at once. =C2=A0I= 'd like to try and accomplish this incrementally.


    Cheers,
    Silvia.=C2=A0


    -Robin




    <= /div>
    =20 17 June, 2013=20 9:00 PM
    =
    Hi Peter, all,

    I'm=20 looking at all this from the view of a JS developer and I am
    really=20 excited that there is movement in this space. Having hit my
    head hard against the limitations of the current WebRTC API and being
    forced=20 to learn SDP to achieve some of the less common use cases, I'm
    feeli= ng the pain. I am therefore happy to see that there is a proposal
    for a higher-level API with similarities to the Microsoft's CU-WebRTC
    pro= posal and I hope that together with Microsoft's input this can
    become a= =20 really useful API.

    What I would like to see, though, is a bit=20 different from what you've
    proposed. In particular, the=20 MediaFlowDescription object is the one
    object that I believe is=20 supposed to enable JS developers to do "SDP
    hacking" without = having=20 to understand SDP. Unfortunately, the way in
    which it is currently=20 written, this API doesn't help a JS developer
    much. There are=20 properties in that object like "ssrc" that mean
    nothing unless= you=20 understand SDP.

    I would therefore like to recommend making the=20 properties on the
    MediaFlowDescription more semantic - in particular=20 giving them better
    names - such that a JS developer really doesn't= =20 have to understand SDP
    to create/change media flow descriptions. Can=20 we find better names for
    id, transportId and ssrc that are more=20 explicitly expressing what
    they stand for and when a JS developer=20 would actually change them?

    It would be nice if the=20 MediaFlowDescription was abstract enough such
    that in future it=20 doesn't matter if SDP is actually underneath (with
    offer/answer), bu= t that's not actually my main goal. What I'm after is
    an API that= can=20 be used without having to understand what is
    underneath.

    Thanks for listening and HTH,
    Silvia.

    _____= __________________________________________
    rtcweb mailing list
    rtcwe= b@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    =20 17 June, 2013=20 8:57 AM
    Google is in full support of "Plan B" for encoding multiple media sourc= es in=20 SDP, and would like to see the Plan A vs. Plan B decision resolved soon. =C2=A0Recently, though, a third option, called "NoPlan" has been= proposed,=20 but it lacked the details of what a JS API would look like for NoPlan.=20 =C2=A0Cullen asked to see such an API proposal, and so I have worked with= =20 Emil to make one. =C2=A0He will be adding it to the NoPlan draft, but I wil= l=20 also include it in this email.

    Again, Google is in full support of "Plan B". =C2=A0But if Pl= an A vs.=20 Plan B cannot be decided, then we support NoPlan with the following=20 additions to the WebRTC JS API as an option that allows implementing=20 either Plan A or Plan B =C2=A0in Javascript. =C2=A0And even if Plan A vs. P= lan B=20 is resolved, these API additions would still be a big improvement for=20 those WebRTC applications that don't use SDP for signalling.

    It is a bit long because I have added many comments and examples,=20 but the actually additions only include two new methods on=20 PeerConnection and a few new dictionaries. =C2=A0So don't be overwhelme= d :).



    Intro: This follows the= =20 model of createDataChannel, which has a JS method on PeerConnection that makes it possible to add data channels without going through SDP.=20 =C2=A0Furthermore, just like createDataChannel allows 2 ways to handle=20 neogitation (the "I know what I'm doing; =C2=A0Here's what I w= ant to send;=20 Let me signal everything" mode and the "please take care of it fo= r me;=20 =C2=A0send an OPEN message" mode), this also has 2 ways to handle nego= tiation (the "I know what I'm doing; Here's what I want to send; Let = me signal=20 everything" mode and the "please take care of it for me; =C2=A0se= nd SDP back=20 and forth" mode).=C2=A0
    = =C2=A0
    Following the success of=20 createDataChannel, this allows simple applications to Just Work and more advanced applications to easily control what they need to. =C2=A0In=20 particular, it's possible to use this API to implement either Plan A or= =20 Plan B.

    // The following two method are= =20 added to RTCPeerConnection
    partial interface RTCPeerConnection {
    =C2= =A0// Create a stream that is used to send a source stream.
    =C2=A0// The=20 MediaSendStream.description can be used for signalling.
    =C2=A0// No media is sent until addStream(MediaSendStream) is called.
    =C2=A0LocalMediaStream=20 createLocalStream(MediaStream sourceStream);

    =C2=A0// Create a stream that is used to receive media from the remote= =20 side,
    =C2=A0// given the parameters signalled from=20 MedaiSendStream.description.
    =C2=A0MediaStream=20 createRemoteStream(MediaStreamDescription description);
    }


    interface LocalMediaStream implements MediaStream {
    =C2=A0 = // This can be changed at any time, but especially before calling
    =C2=A0 /= /=20 PeerConnection.addStream
    =C2=A0 attribute MediaStreamDescripti= on=20 description;
    }

    // Represents the parameters used to either send or receive a stream=C2=A0
    = // over a=C2=A0PeerConnection.
    dic= tionary=20 MediaStreamDescription {
    =C2=A0 MediaStreamTrackDescription[] tracks; }


    // Represents the parameters used to either send or receive a=20 track over // a=C2=A0PeerConnection. =C2=A0A track has many "flows&quo= t;, which can be=20 grouped=C2=A0
    // together.
    dictionary=20 MediaStreamTrackDescription {
    =C2=A0 // Same as the MediaStreamTrack.id<= br>=C2=A0 DOMString id;

    =C2=A0 // Same as the MediaStreamTrack.kind
    =C2=A0= =20 DOMString kind; =C2=A0

    =C2=A0 // A track can have many "flows", such as for Simulcas= t, FEC, etc.
    =C2=A0 // And they can be grouped in arbitrary ways.
    =C2=A0=20 MediaFlowDescription[] flows;
    =C2=A0 MediaFlowGroup[] flowGroups;
    }

    // Represents the parameters used to either send or receive a "flow"=C2=A0
    // over a=C2=A0PeerConnection. =C2=A0A "flow&q= uot; is a=20 media that arrives with a=C2=A0
    = // single, unique SSRC. =C2=A0One to = many=20 flows together make up the media=C2=A0
    // for a track. =C2=A0For=C2=A0exampl= e, there=20 may be Simulcast, FEC, and RTX=C2=A0
    // flows.
    dictionay MediaFlowDescription {
    =C2=A0 // The "flow id" must = be unique to the track, but need not be unique=C2=A0
    =C2=A0 // outside=C2=A0of the track (two tracks=20 could both have a flow with the=C2=A0
    = =C2=A0 // same flow ID).
    =C2=A0 DO= MString id;

    =C2=A0 // Each flow can go over its own transport. =C2=A0If the JS sets this to a=
    =C2=A0 // transportId that doesn't have a transport setup already, the= =C2=A0
    =C2=A0 // browser = will use SDP negotiation to=20 setup a transport to back that=C2=A0
    = =C2=A0 // transportId. =C2=A0If=C2=A0= This is set to an=20 MID in the SDP, then that MID's=C2=A0
    =C2=A0 // transport is used.
    =C2= =A0=20 DOMString transportId;

    =C2=A0 // The SSRC used to send the flow.
    = =C2=A0=20 unsigned int ssrc;

    =C2= =A0=20 // When used as receive parameters, this indicates the possible list=C2=A0<= /font>
    = =C2=A0 // of codecs that might come i= n for=20 this flow. =C2=A0For exmample, a given=C2=A0
    =C2=A0 // receive=C2=A0flow could be = setup to=20 receive any of OPUS, ISAC, or PCMU.
    =C2=A0 // When used as send=20 parameters, this indicates that the first codec=C2=A0
    =C2=A0 // should=C2=A0be used, but th= e browser can use send other codecs if it=C2=A0
    =C2=A0 // needs to because=C2=A0of either bandwidth or CPU constraints.
    =C2=A0 MediaCodecDescription[] codecs;
    }


    dictionary=20 MediaFlowGroup {
    =C2=A0 DOMString type; =C2=A0// "SIM" for Sim= ulcast, "FEC" for FEC, etc
    =C2=A0 DOMString[] flowids;
    }

    dictionary=20 MediaCodecDescription {
    =C2=A0 unsigned byte payloadType;
    =C2=A0 DOMS= tring=20 name;
    =C2=A0 unsigned int? clockRate;
    =C2=A0 unsigned int? bitRate;
    =C2=A0 // A grab bag of other fmtp th= at=20 will need to be further defined.
    =C2=A0 MediaCodecParam[] params; =C2=A0=
    }

    dictionary MediaCodecParam {
    =C2=A0 DOMString key;
    =C2=A0 DOMString value;
    }


    Notes:

    - When LocalMediaStreams are added using=20 addStream, onnegotiatedneeded is not called, and those streams are never reflected in future SDP exchanges. =C2=A0Indeed, it would be impossible to= =20 put them in the SDP without first resolving if that would be Plan A SDP=20 or Plan B SDP.
    =
    - Just like piles of attributes would=20 need to be defined for Plan A and for Plan B, similar attributes would=20 need to be defined here (Luckily, =C2=A0much work has already been done=20 figuring out what those parameters are :).


    Pros:

    - Either Plan A or Plan B or could be implemented=20 in Javascript using this API
    - It exposes all the same functionality=20 to the Javascript as SDP, but in a much nicer format that is much easier to work with.
    - Any other signalling mechanism, such as Jingle or CLUE could be=20 implemented using this API.
    - There is almost no risk of signalling=20 glare.
    - Debugging errors with misconfigured descriptions should be=20 much easier with this than with large SDP blobs.


    Cons:

    - Now there are two slightly different ways to add streams: by creating a=20 LocalMediaStream first, and not. =C2=A0This is, however, analogous to setti= ng "negotiated: true" in createDataChannel. =C2=A0On way is "J= ust Work", and=20 the other is more advanced control.
    =
    - All the options in=20 MediaCodecDescription are a bit complicated. =C2=A0Really, this is only=20 necessary because Plan A requires being able to specify codec parameters per SSRC, and set each flow on different transports. =C2=A0If we did not= =20 have this requirement, we could simplify.


    Example Usage:

    // Imagine I have MyApp, handles creating a PeerConnection,
    // signalling, and rendering streams. =C2=A0This is how= =20 the new API could be=C2=A0
    // used.
    var peerConnection =3D=20 MyApp.createPeerConnection();

    // On sender side:
    var stream =3D= =20 MyApp.getMediaStream();
    var localStream =3D=20 peerConnection.createSendStream(stream);
    sendStream.description =3D MyApp.modifyStream(localStream.description)
    M= yApp.signalAddStream(localStream.description, function(response)) {
    =C2=A0 if (!response.rejected) {
    =C2=A0 =C2=A0= // Media=20 will not be sent.
    =C2=A0 =C2=A0 peerConnection.addStream(localStream); =C2=A0 }
    }

    // On receiver side:
    MyApp.onAddStreamSignalled =3D= =20 function(streamDescription) {
    =C2=A0 var stream =3D=20 peerConnection.createReceiveStream(streamDescription);
    =C2=A0 MyApp.renderStream(stream);}


    // In this exchange, the MediaStreamDescription signalled from the=C2=A0
    // sender to=C2=A0the receiver may ha= ve=20 looked something like this:

    {
    =C2=A0 tracks: [
    =C2=A0 {
    =C2= =A0 =C2=A0 id:=20 "audio1",
    =C2=A0 =C2=A0 kind: "audio",
    =C2=A0 =C2= =A0 flows: [
    =C2=A0 =C2=A0 {
    =C2=A0 =C2=A0 =C2=A0=C2=A0    id:=20 "main",
    =C2=A0 = =C2=A0 =C2=A0 transportId: "transport1",
    =C2=A0 = =C2=A0 =C2=A0 ssrc:=20 1111,
    =C2=A0 =C2=A0 =C2=A0 codecs: = [
    =C2=A0 = =C2=A0 =C2=A0 {
    =C2=A0 =C2=A0 =C2= =A0 =C2=A0 payloadType: 111, =C2=A0 = =C2=A0 =C2=A0 =C2=A0 name:=20 "opus",
    =C2=A0 =C2=A0 =C2= =A0 =C2=A0 // ... more codec=20 details
    = =C2=A0 =C2=A0 = =C2=A0 },
    =C2=A0 =C2=A0 = =C2=A0 {=C2=A0
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 112,
    =C2=A0 =C2=A0 =C2=A0 =C2= =A0 name: "pcmu",
    =C2=A0 =C2=A0 = =C2=A0 =C2=A0=C2=A0// ... more codec details
    =C2=A0 =C2=A0 = =C2=A0 }]
    =C2=A0 =C2=A0}]=C2=A0},
    =C2=A0{
    =C2=A0 =C2=A0 id: "video1",
    =C2=A0 = =C2=A0 kind:=20 "video",
    <= span style=3D"font-family:'courier new',monospace">=C2=A0 =C2=A0 fl= ows: [
    = =C2=A0 =C2=A0 {=
    =C2=A0 =C2=A0 = =C2=A0 id: "sim0",
    =C2=A0 =C2=A0 =C2=A0 transportId:=20 "transport2",
    =C2=A0 = =C2=A0 =C2=A0 ssrc:=20 2222,
    =C2=A0 =C2=A0 =C2=A0 codecs: = [
    =C2=A0 = =C2=A0 =C2=A0 {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 122,
    =C2=A0 = =C2=A0 =C2=A0 =C2=A0 name:=20 "vp8"
    =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0// ... more codec details
    = =C2=A0 =C2=A0 = =C2=A0 }]
    =C2=A0 =C2=A0},
    =C2=A0 =C2=A0{
    = =C2=A0 =C2=A0 =C2=A0id: "sim1",
    =C2=A0 =C2=A0 =C2=A0transportId: "transport2",
    =C2=A0 =C2=A0 =C2=A0s= src: 2223,
    =C2=A0 =C2=A0 =C2=A0codecs: [
    =C2=A0 =C2=A0 =C2=A0{
    =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 122,
    =C2=A0 = =C2=A0 =C2=A0 =C2=A0name: "vp8",
    =C2=A0 =C2=A0 =C2=A0 =C2=A0    // ...=20 more codec details
    =C2=A0 = =C2=A0 =C2=A0}]
    =C2=A0 =C2=A0},
    =C2=A0 =C2=A0{
    =C2=A0 =C2=A0 =C2=A0id: "sim2",=C2=A0 =C2=A0 =C2=A0transportId: "transport2",
    =C2=A0 =C2=A0 =C2=A0ssrc: 2224,
    =C2=A0 =C2=A0 =C2=A0codecs: [
    =C2=A0 = =C2=A0 =C2=A0{
    =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 122,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "vp8",
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<= /font>// ... more codec details
    =C2=A0 =C2=A0 =C2=A0}]
    =C2=A0 =C2=A0},

    =C2=A0 =C2=A0{
    =C2=A0 = =C2=A0 =C2=A0id: "sim0fec",
    =C2=A0 =C2=A0 =C2=A0transportId: "transport2",
    =C2=A0 =C2=A0 =C2=A0ssrc: 2225,
    =C2=A0 =C2= =A0 =C2=A0codecs: [
    =C2=A0 =C2=A0 =C2=A0{
    =C2=A0 =C2=A0 =C2=A0=20 =C2=A0payloadType: 122,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "vp8"= ,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0// ...
    =C2=A0 =C2=A0 =C2=A0}]
    =C2=A0 =C2=A0}],
    =C2=A0 =C2=A0flowGroups: [=C2=A0 =C2=A0{
    =C2=A0 =C2=A0 =C2=A0semantics: "SIM",
    =C2= =A0 =C2=A0 =C2=A0ssrcs: [2222, 2223, 2224]
    =C2=A0 =C2=A0},
    =C2=A0 =C2=A0= {
    =C2=A0 =C2=A0 =C2=A0semantics: "FEC",
    =C2=A0 =C2=A0 =C2=A0ssrcs: [2222, 2225]
    =C2=A0 =C2=A0}]
    =C2=A0}]
    }


    Constructive feedback is welcome :).
    _______________________________________________
    rtcweb mailing=20 list
    rtcweb@ietf.or= g
    https://www.ietf.org/mailman/listinfo/rtcweb


    --047d7b15a385c84b7f04df830f1d-- --047d7b15a385c84b8004df830f1e Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 6b11cf39ae4323a6_0.1.1 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkI CQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkLEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAARCAAZABkDAREA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwBvi7xt L/ZUvifVora/u5rGG8uJ57KKaWWWSJSSWZSeWbgdAMAYAAr1sRUhRw8pM86hGVauoo8kPxO8dWMM Nx4l8JaTp1rPGJYnfR4XSRPXd5Yx+Ga+XoZn72krn0VXLVy6xPV/hh4z0vxVb2l/BDYRFLlIZBDa wqyNkYKuqhlPOQQcg/SvqsJiKeJpXR81iaMsNUsO/wCGlvjF/wBD9f8A/fKf/E1fsqfYXtZ9znYr hNetfDmmmRYDK2lYkf8AiZTD8uPfkfjXm5tb6jNtHblabxsEj3/xi2p6t4QPhe8+FqBPtDW0VqLm Pe0eM+apxgewznFfn2GhHm02R+iVIS5Nj5U0TQL74VfGu48PNdRR6ZrUvmW0GGPkldjjkfKeTInH 92vqstr+yqxgup8lmmG5qcpvdHN/2qf+fpP++T/jX0/Mz5qxa8JalrnxI8baZ8IPCP7vVdPtlu7+ eQGEWf2SMNIGHXcrLgjAJbC9TXkZsnVw3s49WenlsPZVfay6H2Be/DHxM+g6LqvkardtrEUOoQG2 UujvIikjzCcIe3zcgZwcV8fQw1aM+XufbvN8O6PM3qj5e+OngXW/hl8cY/EWs3V1c21tb2d1fy7t 8NkWH+rDHouN3PdiT3r3IU3QrQ5dWrNnzlas8XCT2TukcB/wjPjL/on/AIl/8FE3/wARXu/Xo/ys 8P6rLujoPFv/ACfR8Vf+uTf+i7esJ7I7I7P1PTvCP/Ig2H/Xsv8AM1wrdBUPM/Gv/JSdF/7CGhf+ lcda0/iZcf4a+Z+qVUI//9k= --047d7b15a385c84b8004df830f1e Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 6b11cf39ae4323a6_0.1.2 /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQECAQEB AQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAARCAAZABkDAREA AhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUKBwAAAAAAAAACAQME BQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAAAAAAAAAAAAADAAEEAv/E ACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oADAMBAAIRAxEAPwDuEt+gW/UL et6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJVIl7eXLCaZIGwBl3TY8epPx2+jy2 ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJ Ew/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx+a69/JSf9alIlste0VzaNpeFrcT9KKymotyi aZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mRUfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRD nu5azS8miKqjOTVkKqS/psG37fo1Fbabeg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GA cpOwBeN+U8/IkGbsiS8b7ryogmbzhbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH 4hPOI0DkjZtaJtFxuVEbIUUiyeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJ nYn9dnAQWl722p4ot37yzqnlfp6FrqbwawG8/9k= --047d7b15a385c84b8004df830f1e-- From michael@voip.co.uk Wed Jun 19 08:00:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F0621F84F2 for ; Wed, 19 Jun 2013 08:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKVhNTWNi+bK for ; Wed, 19 Jun 2013 08:00:53 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with SMTP id C25EB21F8517 for ; Wed, 19 Jun 2013 08:00:51 -0700 (PDT) Received: from mail-we0-f176.google.com ([74.125.82.176]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKUcHHmS+qQmqh/6ZzVZzhcMnrv40EDCRK@postini.com; Wed, 19 Jun 2013 08:00:51 PDT Received: by mail-we0-f176.google.com with SMTP id t56so4504979wes.21 for ; Wed, 19 Jun 2013 08:00: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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+tYKxv4w4ocPPMrUWA5hwxwWv3yql5Ltbpl/sUy6qu8=; b=UcCEgw6hHbyBLhGnYQzUrqjeTgxO0iEJNwhaYo7a4fuCcyyCnt0UpKsAIPXw9Y6nQK lRZlr39aQxTbpiHHVJGhTI4CYyIBXs6fsUpPVyfxNpBB6KylXngV/qlU8wYvKE6IWXHY RL1wIpkN8MWR02W/Ckggd8wv6SlLhh9tJJ9q3RgeSWVG+sK0kPvZN6SIeUmo5GWVXuj7 pufShUMhqSW2pPc26Izlf2YLeETcBt4jaAQphFBBLGxACiAZTr6oAOoxNwVHJWm1ypia OiqQ+2smDCK2c0Owky5KV4rQzaQsHTLL5+gFFvS7+tGWXZk0tBDqFeI+CmV5Wg63b+1d 8New== X-Received: by 10.180.160.144 with SMTP id xk16mr10447930wib.62.1371654040415; Wed, 19 Jun 2013 08:00:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.144 with SMTP id xk16mr10447923wib.62.1371654040278; Wed, 19 Jun 2013 08:00:40 -0700 (PDT) Received: by 10.194.164.234 with HTTP; Wed, 19 Jun 2013 08:00:40 -0700 (PDT) In-Reply-To: References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> Date: Wed, 19 Jun 2013 16:00:40 +0100 Message-ID: From: Michael Procter To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm2licKY9kID0l4mj7ZLZMHSXSCJVDYP55YWg7E+UhQN+07zm9uO0V+K5wX3VbNFNSEDVTcAx+LVNuIajCu9aDVsAA5U+XPJaG21Sx7HYrFU3qPPoutwfWqzZAbh1nyZmjuE0KpcM1RwUmgHci2HDLY612ccQ== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 15:00:59 -0000 On 19 June 2013 14:46, Bernard Aboba wrote: > Michael said: >> >> The PBX chooses its transmission key, and advertises it through >> SDES/SDP. The browser chooses its transmission key and advertises it >> through DTLS-EKT. The media gateway has the job of matching up the >> SDES pieces with the EKT pieces, and thereafter forwarding packets. > > [BA] Since the PBX can only handle SDES, and the media server speaks > DTLS/SRTP-EKT, the media server needs to provide the DTLS/SRTP-EKT > key to the SIP server so that it can be signaled to the PBX within SDES/SDP. > Similarly, the SIP server needs to provide the SDES key signaled by the > PBX to the media server so that it can communicate this in DTLS/SRTP-EKT. > Therefore the PBX, media server, SIP server and browser endpoint > end up possessing the keys, which is less than ideal. Well indeed. The point I was querying was Matthew's assertion that the keys also needed to be available to the web server and the Javascript app in the browser (and hence transferred over HTTPS), for both SDES and EKT approaches. I don't see why this should be true for EKT, which therefore highlights a fairly significant (IMHO) difference in the security properties of an EKT-based solution. I'm not currently claiming a preference for one over the other, but I think this difference should be considered in the context of the whole picture. Regards, Michael From pthatcher@google.com Wed Jun 19 08:16:17 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2461821F8F5C for ; Wed, 19 Jun 2013 08:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrYl9LHuVTXj for ; Wed, 19 Jun 2013 08:16:15 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id ED8CE21F909A for ; Wed, 19 Jun 2013 08:16:12 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp16so5181885pbb.0 for ; Wed, 19 Jun 2013 08:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VE+2PoyfDnBDgeVQnG4Lx6eu4nnCcIEgQCyHVJ+aVLw=; b=RSKQL965MPhHxcbrIGPcDFlGzKAsViLjcgqxMbaV9T4OmRoWrq3Aa2IZYxjxlp1wtK PnKvqItSdC0RENcYnRD5MBkIYWXe+TicasQ63i6Kmb72R1tMTyiI+EIIVdbHD4v3EV8S AJUnWGcdtGFol7McaOBn8gHE/nNpYi3znvmqQWxSg4Cyz+JwXIjpQagPJDVgQMPdvIA6 DiepAJa4RrnCINNaeLyYNszIEKYKLjRg7zYHKaWTCr7maXhFomlgkEjQnx1WDBYg3tPk IdeV10s/IhkXyO8fin5b54EzkR+idTR1pGzaXGktRqftfC2U9X+joF6/HYtN5e8hfjQ9 9uqQ== 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=VE+2PoyfDnBDgeVQnG4Lx6eu4nnCcIEgQCyHVJ+aVLw=; b=MCQ2WYmxAHEhwMA7aMqbvsPR0O6d6+esKqUdN1glD697uhs6RF/rMOGXQ3SquEPKH/ yaJCKa3B0Bn9znPgLzrgoObFL+HHUu8NQDwh/1PI8aAFlnX5TRij17pXjV7gl18uFEDv PG4a1HbF3iPuSItyMVi0BkAQe8QJHAfhpLMhXLnAfuzQ7ayQxwdA/40Whzv8oHlZcRZS 8oTTb0jFQ7qd8Bt7WpL0L5spC6ghgEtG6UWL82U7shzpvzUVJmGnoksKmoWsPnh+8FuU l0aJMiSpmZwD3GO/OD+uKAwVaVEDq4kDP/iYCqy/ZDWD7A+QMEJG3CJOYaN8tku0/wvx Ygdw== X-Received: by 10.66.83.7 with SMTP id m7mr7311560pay.150.1371654972205; Wed, 19 Jun 2013 08:16:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 08:15:31 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Wed, 19 Jun 2013 08:15:31 -0700 Message-ID: To: Silvia Pfeiffer Content-Type: multipart/alternative; boundary=f46d042ef48d5f815104df834f2d X-Gm-Message-State: ALoCoQnQgd1zUQxXsHxHtcOaLwO3zQ5d/o4fV9LIkMTXkW/z8mh/PR3+4DzF+e/U1QKZfX8sL6I45Ee8FM6H3WDkSz1APi8MTl8B4dYaxO+BMEoD6OTwMacSgR8eTOA8bFgnxnlMLqi1/WGqvWKe09ZbAKY1gsD/OWqMKBk0ZW27BX+Rro6tBAQQvIhhYi0mAyaD4lOG6wn5 Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 15:16:17 -0000 --f46d042ef48d5f815104df834f2d Content-Type: text/plain; charset=UTF-8 On Mon, Jun 17, 2013 at 6:00 PM, Silvia Pfeiffer wrote: > Hi Peter, all, > > I'm looking at all this from the view of a JS developer and I am > really excited that there is movement in this space. Having hit my > head hard against the limitations of the current WebRTC API and being > forced to learn SDP to achieve some of the less common use cases, I'm > feeling the pain. I am therefore happy to see that there is a proposal > for a higher-level API with similarities to the Microsoft's CU-WebRTC > proposal and I hope that together with Microsoft's input this can > become a really useful API. > I hope so as well. Unfortunately, Microsoft's input seems to be "our way or the highway" and the input of others seems to be "SDP ought to be enough for anybody". My thinking is that we can make incremental improvements toward a cleaner API without being so extreme at either end. And I hope I can find others that think similarly. What I would like to see, though, is a bit different from what you've > proposed. In particular, the MediaFlowDescription object is the one > object that I believe is supposed to enable JS developers to do "SDP > hacking" without having to understand SDP. Unfortunately, the way in > which it is currently written, this API doesn't help a JS developer > much. There are properties in that object like "ssrc" that mean > nothing unless you understand SDP. > Actually, it helps some JS developer a lot. It happens to be very good for the JS I am writing :). > > I would therefore like to recommend making the properties on the > MediaFlowDescription more semantic - in particular giving them better > names - such that a JS developer really doesn't have to understand SDP > to create/change media flow descriptions. Can we find better names for > id, transportId and ssrc that are more explicitly expressing what > they stand for and when a JS developer would actually change them? > > I did my best with the names. I passionate about good names for things, but we have certain constraints we have to work within. ssrc is an RTP name that cannot be avoided. "id" of a track is the same as the MediaStreamTrack.id, so it's already well defined in the rest of the API. TransportId is a little more hairy, since there is no clean API for transports, so it has to refer to the SDP. I could have called it transportSdpMid to be more clear what it is, but I doubt you would have liked that name :). Are there any others that you don't like? > It would be nice if the MediaFlowDescription was abstract enough such > that in future it doesn't matter if SDP is actually underneath (with > offer/answer), MediaFlowDescription isn't using SDP underneath. There would be no SDP between the JS and the browser if MediaFlowDescription were used. And, it isn't offer/answer either (unless you implement offer/answer on top it, obviously. It's the JS's choice of what to do). > but that's not actually my main goal. What I'm after is > an API that can be used without having to understand what is > underneath. > For signalling, what's in MediaStreamTrackDescription must be serialized, sent to the receiving side, and deserialized. That is a pretty fundamental requirement, and short of deciding all RTP parameters a priori, there's no way to do RTC without doing so. So, you at least will need to know how to accomplish that. Of course, a library on to of the WebRTC API may provide you that signaling so you don't have to. But the WG has, correctly, decided to leave the decision of the signalling to the JS and not back it into the API. > > Thanks for listening and HTH, > Silvia. > > > On Mon, Jun 17, 2013 at 10:57 PM, Peter Thatcher > wrote: > > Google is in full support of "Plan B" for encoding multiple media > sources in > > SDP, and would like to see the Plan A vs. Plan B decision resolved soon. > > Recently, though, a third option, called "NoPlan" has been proposed, but > it > > lacked the details of what a JS API would look like for NoPlan. Cullen > > asked to see such an API proposal, and so I have worked with Emil to make > > one. He will be adding it to the NoPlan draft, but I will also include > it > > in this email. > > > > Again, Google is in full support of "Plan B". But if Plan A vs. Plan B > > cannot be decided, then we support NoPlan with the following additions to > > the WebRTC JS API as an option that allows implementing either Plan A or > > Plan B in Javascript. And even if Plan A vs. Plan B is resolved, these > API > > additions would still be a big improvement for those WebRTC applications > > that don't use SDP for signalling. > > > > It is a bit long because I have added many comments and examples, but the > > actually additions only include two new methods on PeerConnection and a > few > > new dictionaries. So don't be overwhelmed :). > > > > > > > > Intro: This follows the model of createDataChannel, which has a JS > method on > > PeerConnection that makes it possible to add data channels without going > > through SDP. Furthermore, just like createDataChannel allows 2 ways to > > handle neogitation (the "I know what I'm doing; Here's what I want to > send; > > Let me signal everything" mode and the "please take care of it for me; > send > > an OPEN message" mode), this also has 2 ways to handle negotiation (the > "I > > know what I'm doing; Here's what I want to send; Let me signal > everything" > > mode and the "please take care of it for me; send SDP back and forth" > > mode). > > > > Following the success of createDataChannel, this allows simple > applications > > to Just Work and more advanced applications to easily control what they > need > > to. In particular, it's possible to use this API to implement either > Plan A > > or Plan B. > > > > // The following two method are added to RTCPeerConnection > > partial interface RTCPeerConnection { > > // Create a stream that is used to send a source stream. > > // The MediaSendStream.description can be used for signalling. > > // No media is sent until addStream(MediaSendStream) is called. > > LocalMediaStream createLocalStream(MediaStream sourceStream); > > > > // Create a stream that is used to receive media from the remote side, > > // given the parameters signalled from MedaiSendStream.description. > > MediaStream createRemoteStream(MediaStreamDescription description); > > } > > > > > > interface LocalMediaStream implements MediaStream { > > // This can be changed at any time, but especially before calling > > // PeerConnection.addStream > > attribute MediaStreamDescription description; > > } > > > > > > // Represents the parameters used to either send or receive a stream > > // over a PeerConnection. > > dictionary MediaStreamDescription { > > MediaStreamTrackDescription[] tracks; > > } > > > > > > // Represents the parameters used to either send or receive a track over > // > > a PeerConnection. A track has many "flows", which can be grouped > > // together. > > dictionary MediaStreamTrackDescription { > > // Same as the MediaStreamTrack.id > > DOMString id; > > > > // Same as the MediaStreamTrack.kind > > DOMString kind; > > > > // A track can have many "flows", such as for Simulcast, FEC, etc. > > // And they can be grouped in arbitrary ways. > > MediaFlowDescription[] flows; > > MediaFlowGroup[] flowGroups; > > } > > > > // Represents the parameters used to either send or receive a "flow" > > // over a PeerConnection. A "flow" is a media that arrives with a > > // single, unique SSRC. One to many flows together make up the media > > // for a track. For example, there may be Simulcast, FEC, and RTX > > // flows. > > dictionay MediaFlowDescription { > > // The "flow id" must be unique to the track, but need not be unique > > // outside of the track (two tracks could both have a flow with the > > // same flow ID). > > DOMString id; > > > > // Each flow can go over its own transport. If the JS sets this to a > > // transportId that doesn't have a transport setup already, the > > // browser will use SDP negotiation to setup a transport to back that > > // transportId. If This is set to an MID in the SDP, then that MID's > > // transport is used. > > DOMString transportId; > > > > // The SSRC used to send the flow. > > unsigned int ssrc; > > > > // When used as receive parameters, this indicates the possible list > > // of codecs that might come in for this flow. For exmample, a given > > // receive flow could be setup to receive any of OPUS, ISAC, or PCMU. > > // When used as send parameters, this indicates that the first codec > > // should be used, but the browser can use send other codecs if it > > // needs to because of either bandwidth or CPU constraints. > > MediaCodecDescription[] codecs; > > } > > > > > > dictionary MediaFlowGroup { > > DOMString type; // "SIM" for Simulcast, "FEC" for FEC, etc > > DOMString[] flowids; > > } > > > > dictionary MediaCodecDescription { > > unsigned byte payloadType; > > DOMString name; > > unsigned int? clockRate; > > unsigned int? bitRate; > > // A grab bag of other fmtp that will need to be further defined. > > MediaCodecParam[] params; > > } > > > > dictionary MediaCodecParam { > > DOMString key; > > DOMString value; > > } > > > > > > Notes: > > > > - When LocalMediaStreams are added using addStream, onnegotiatedneeded is > > not called, and those streams are never reflected in future SDP > exchanges. > > Indeed, it would be impossible to put them in the SDP without first > > resolving if that would be Plan A SDP or Plan B SDP. > > > > - Just like piles of attributes would need to be defined for Plan A and > for > > Plan B, similar attributes would need to be defined here (Luckily, much > > work has already been done figuring out what those parameters are :). > > > > > > Pros: > > > > - Either Plan A or Plan B or could be implemented in Javascript using > this > > API > > - It exposes all the same functionality to the Javascript as SDP, but in > a > > much nicer format that is much easier to work with. > > - Any other signalling mechanism, such as Jingle or CLUE could be > > implemented using this API. > > - There is almost no risk of signalling glare. > > - Debugging errors with misconfigured descriptions should be much easier > > with this than with large SDP blobs. > > > > > > Cons: > > > > - Now there are two slightly different ways to add streams: by creating a > > LocalMediaStream first, and not. This is, however, analogous to setting > > "negotiated: true" in createDataChannel. On way is "Just Work", and the > > other is more advanced control. > > > > - All the options in MediaCodecDescription are a bit complicated. > Really, > > this is only necessary because Plan A requires being able to specify > codec > > parameters per SSRC, and set each flow on different transports. If we > did > > not have this requirement, we could simplify. > > > > > > Example Usage: > > > > // Imagine I have MyApp, handles creating a PeerConnection, > > // signalling, and rendering streams. This is how the new API could be > > // used. > > var peerConnection = MyApp.createPeerConnection(); > > > > // On sender side: > > var stream = MyApp.getMediaStream(); > > var localStream = peerConnection.createSendStream(stream); > > sendStream.description = MyApp.modifyStream(localStream.description) > > MyApp.signalAddStream(localStream.description, function(response)) { > > if (!response.rejected) { > > // Media will not be sent. > > peerConnection.addStream(localStream); > > } > > } > > > > // On receiver side: > > MyApp.onAddStreamSignalled = function(streamDescription) { > > var stream = peerConnection.createReceiveStream(streamDescription); > > MyApp.renderStream(stream); > > } > > > > > > // In this exchange, the MediaStreamDescription signalled from the > > // sender to the receiver may have looked something like this: > > > > { > > tracks: [ > > { > > id: "audio1", > > kind: "audio", > > flows: [ > > { > > id: "main", > > transportId: "transport1", > > ssrc: 1111, > > codecs: [ > > { > > payloadType: 111, > > name: "opus", > > // ... more codec details > > }, > > { > > payloadType: 112, > > name: "pcmu", > > // ... more codec details > > }] > > }] > > }, > > { > > id: "video1", > > kind: "video", > > flows: [ > > { > > id: "sim0", > > transportId: "transport2", > > ssrc: 2222, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8" > > // ... more codec details > > }] > > }, > > { > > id: "sim1", > > transportId: "transport2", > > ssrc: 2223, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... more codec details > > }] > > }, > > { > > id: "sim2", > > transportId: "transport2", > > ssrc: 2224, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... more codec details > > }] > > }, > > > > { > > id: "sim0fec", > > transportId: "transport2", > > ssrc: 2225, > > codecs: [ > > { > > payloadType: 122, > > name: "vp8", > > // ... > > }] > > }], > > flowGroups: [ > > { > > semantics: "SIM", > > ssrcs: [2222, 2223, 2224] > > }, > > { > > semantics: "FEC", > > ssrcs: [2222, 2225] > > }] > > }] > > } > > > > > > Constructive feedback is welcome :). > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > --f46d042ef48d5f815104df834f2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Mon, Jun 17, 2013 at 6:00 PM, Silvia Pfeiffer = <silviapf= eiffer1@gmail.com> wrote:
    Hi Peter, all,

    I'm looking at all this from the view of a JS developer and I am
    really excited that there is movement in this space. Having hit my
    head hard against the limitations of the current WebRTC API and being
    forced to learn SDP to achieve some of the less common use cases, I'm feeling the pain. I am therefore happy to see that there is a proposal
    for a higher-level API with similarities to the Microsoft's CU-WebRTC proposal and I hope that together with Microsoft's input this can
    become a really useful API.

    I hope so a= s well. =C2=A0Unfortunately, Microsoft's input seems to be "our wa= y or the highway" and the input of others seems to be "SDP=C2=A0<= span style=3D"color:rgb(0,0,0);font-family:georgia,'times new roman'= ;,serif;font-size:14px;line-height:17.40625px">ought to be enough for anybo= dy". =C2=A0My thinking is that we can make incremental improvem= ents toward a cleaner API without being so extreme at either end. =C2=A0And= I hope I can find others that think similarly.


    What I would like to see, though, is a bit different from what you've proposed. In particular, the MediaFlowDescription object is the one
    object that I believe is supposed to enable JS developers to =C2=A0do "= ;SDP
    hacking" without having to understand SDP. Unfortunately, the way in which it is currently written, this API doesn't help a JS developer
    much. There are properties in that object like "ssrc" that mean nothing unless you understand SDP.

    Actu= ally, it helps some JS developer a lot. =C2=A0It happens to be very good fo= r the JS I am writing :).
    =C2=A0

    I would therefore like to recommend making the properties on the
    MediaFlowDescription more semantic - in particular giving them better
    names - such that a JS developer really doesn't have to understand SDP<= br> to create/change media flow descriptions. Can we find better names for
    =C2=A0id, transportId and ssrc that are more explicitly expressing what
    they stand for and when a JS developer would actually change them?


    I did my best with the names. =C2=A0 I= passionate about good names for things, but we have certain constraints we= have to work within. =C2=A0ssrc is an RTP name that cannot be avoided. =C2= =A0"id" of a track is the same as the MediaStreamTrack.id, so it&= #39;s already well defined in the rest of the API. =C2=A0TransportId is a l= ittle more hairy, since there is no clean API for transports, so it has to = refer to the SDP. =C2=A0I could have called it transportSdpMid to be more c= lear what it is, but I doubt you would have liked that name :). =C2=A0Are t= here any others that you don't like?
    =C2=A0
    It would be nice if the MediaFlowDescription was abstract enough such
    that in future it doesn't matter if SDP is actually underneath (with offer/answer),

    MediaFlowDescription isn= 9;t using SDP underneath. =C2=A0There would be no SDP between the JS and th= e browser if MediaFlowDescription were used. =C2=A0And, it isn't offer/= answer either (unless you implement offer/answer on top it, obviously. =C2= =A0It's the JS's choice of what to do).

    =C2=A0
    but that's not actuall= y my main goal. What I'm after is
    an API that can be used without having to understand what is
    underneath.

    For signalling, what's = in MediaStreamTrackDescription must be serialized, sent to the receiving si= de, and deserialized. =C2=A0That is a pretty fundamental requirement, and s= hort of deciding all RTP parameters a priori, there's no way to do RTC = without doing so. =C2=A0So, you at least will need to know how to accomplis= h that. =C2=A0Of course, a library on to of the WebRTC API may provide you = that signaling so you don't have to. =C2=A0But the WG has, correctly, d= ecided to leave the decision of the signalling to the JS and not back it in= to the API.


    =C2=A0

    Thanks for listening and HTH,
    Silvia.


    On Mon, Jun 17, 2013 at 10:57 PM, Peter Thatcher <pthatcher@google.com> wrote:
    > Google is in full support of "Plan B" for encoding multiple = media sources in
    > SDP, and would like to see the Plan A vs. Plan B decision resolved soo= n.
    > Recently, though, a third option, called "NoPlan" has been p= roposed, but it
    > lacked the details of what a JS API would look like for NoPlan. =C2=A0= Cullen
    > asked to see such an API proposal, and so I have worked with Emil to m= ake
    > one. =C2=A0He will be adding it to the NoPlan draft, but I will also i= nclude it
    > in this email.
    >
    > Again, Google is in full support of "Plan B". =C2=A0But if P= lan A vs. Plan B
    > cannot be decided, then we support NoPlan with the following additions= to
    > the WebRTC JS API as an option that allows implementing either Plan A = or
    > Plan B =C2=A0in Javascript. =C2=A0And even if Plan A vs. Plan B is res= olved, these API
    > additions would still be a big improvement for those WebRTC applicatio= ns
    > that don't use SDP for signalling.
    >
    > It is a bit long because I have added many comments and examples, but = the
    > actually additions only include two new methods on PeerConnection and = a few
    > new dictionaries. =C2=A0So don't be overwhelmed :).
    >
    >
    >
    > Intro: This follows the model of createDataChannel, which has a JS met= hod on
    > PeerConnection that makes it possible to add data channels without goi= ng
    > through SDP. =C2=A0Furthermore, just like createDataChannel allows 2 w= ays to
    > handle neogitation (the "I know what I'm doing; =C2=A0Here= 9;s what I want to send;
    > Let me signal everything" mode and the "please take care of = it for me; =C2=A0send
    > an OPEN message" mode), this also has 2 ways to handle negotiatio= n (the "I
    > know what I'm doing; Here's what I want to send; Let me signal= everything"
    > mode and the "please take care of it for me; =C2=A0send SDP back = and forth"
    > mode).
    >
    > Following the success of createDataChannel, this allows simple applica= tions
    > to Just Work and more advanced applications to easily control what the= y need
    > to. =C2=A0In particular, it's possible to use this API to implemen= t either Plan A
    > or Plan B.
    >
    > // The following two method are added to RTCPeerConnection
    > partial interface RTCPeerConnection {
    > =C2=A0// Create a stream that is used to send a source stream.
    > =C2=A0// The MediaSendStream.description can be used for signalling. > =C2=A0// No media is sent until addStream(MediaSendStream) is called.<= br> > =C2=A0LocalMediaStream createLocalStream(MediaStream sourceStream); >
    > =C2=A0// Create a stream that is used to receive media from the remote= side,
    > =C2=A0// given the parameters signalled from MedaiSendStream.descripti= on.
    > =C2=A0MediaStream createRemoteStream(MediaStreamDescription descriptio= n);
    > }
    >
    >
    > interface LocalMediaStream implements MediaStream {
    > =C2=A0 // This can be changed at any time, but especially before calli= ng
    > =C2=A0 // PeerConnection.addStream
    > =C2=A0 attribute MediaStreamDescription description;
    > }
    >
    >
    > // Represents the parameters used to either send or receive a stream > // over a PeerConnection.
    > dictionary MediaStreamDescription {
    > =C2=A0 MediaStreamTrackDescription[] tracks;
    > }
    >
    >
    > // Represents the parameters used to either send or receive a track ov= er //
    > a PeerConnection. =C2=A0A track has many "flows", which can = be grouped
    > // together.
    > dictionary MediaStreamTrackDescription {
    > =C2=A0 // Same as the MediaStreamTrack.id
    > =C2=A0 DOMString id;
    >
    > =C2=A0 // Same as the MediaStreamTrack.kind
    > =C2=A0 DOMString kind;
    >
    > =C2=A0 // A track can have many "flows", such as for Simulca= st, FEC, etc.
    > =C2=A0 // And they can be grouped in arbitrary ways.
    > =C2=A0 MediaFlowDescription[] flows;
    > =C2=A0 MediaFlowGroup[] flowGroups;
    > }
    >
    > // Represents the parameters used to either send or receive a "fl= ow"
    > // over a PeerConnection. =C2=A0A "flow" is a media that arr= ives with a
    > // single, unique SSRC. =C2=A0One to many flows together make up the m= edia
    > // for a track. =C2=A0For example, there may be Simulcast, FEC, and RT= X
    > // flows.
    > dictionay MediaFlowDescription {
    > =C2=A0 // The "flow id" must be unique to the track, but nee= d not be unique
    > =C2=A0 // outside of the track (two tracks could both have a flow with= the
    > =C2=A0 // same flow ID).
    > =C2=A0 DOMString id;
    >
    > =C2=A0 // Each flow can go over its own transport. =C2=A0If the JS set= s this to a
    > =C2=A0 // transportId that doesn't have a transport setup already,= the
    > =C2=A0 // browser will use SDP negotiation to setup a transport to bac= k that
    > =C2=A0 // transportId. =C2=A0If This is set to an MID in the SDP, then= that MID's
    > =C2=A0 // transport is used.
    > =C2=A0 DOMString transportId;
    >
    > =C2=A0 // The SSRC used to send the flow.
    > =C2=A0 unsigned int ssrc;
    >
    > =C2=A0 // When used as receive parameters, this indicates the possible= list
    > =C2=A0 // of codecs that might come in for this flow. =C2=A0For exmamp= le, a given
    > =C2=A0 // receive flow could be setup to receive any of OPUS, ISAC, or= PCMU.
    > =C2=A0 // When used as send parameters, this indicates that the first = codec
    > =C2=A0 // should be used, but the browser can use send other codecs if= it
    > =C2=A0 // needs to because of either bandwidth or CPU constraints.
    > =C2=A0 MediaCodecDescription[] codecs;
    > }
    >
    >
    > dictionary MediaFlowGroup {
    > =C2=A0 DOMString type; =C2=A0// "SIM" for Simulcast, "F= EC" for FEC, etc
    > =C2=A0 DOMString[] flowids;
    > }
    >
    > dictionary MediaCodecDescription {
    > =C2=A0 unsigned byte payloadType;
    > =C2=A0 DOMString name;
    > =C2=A0 unsigned int? clockRate;
    > =C2=A0 unsigned int? bitRate;
    > =C2=A0 // A grab bag of other fmtp that will need to be further define= d.
    > =C2=A0 MediaCodecParam[] params;
    > }
    >
    > dictionary MediaCodecParam {
    > =C2=A0 DOMString key;
    > =C2=A0 DOMString value;
    > }
    >
    >
    > Notes:
    >
    > - When LocalMediaStreams are added using addStream, onnegotiatedneeded= is
    > not called, and those streams are never reflected in future SDP exchan= ges.
    > Indeed, it would be impossible to put them in the SDP without first > resolving if that would be Plan A SDP or Plan B SDP.
    >
    > - Just like piles of attributes would need to be defined for Plan A an= d for
    > Plan B, similar attributes would need to be defined here (Luckily, =C2= =A0much
    > work has already been done figuring out what those parameters are :).<= br> >
    >
    > Pros:
    >
    > - Either Plan A or Plan B or could be implemented in Javascript using = this
    > API
    > - It exposes all the same functionality to the Javascript as SDP, but = in a
    > much nicer format that is much easier to work with.
    > - Any other signalling mechanism, such as Jingle or CLUE could be
    > implemented using this API.
    > - There is almost no risk of signalling glare.
    > - Debugging errors with misconfigured descriptions should be much easi= er
    > with this than with large SDP blobs.
    >
    >
    > Cons:
    >
    > - Now there are two slightly different ways to add streams: by creatin= g a
    > LocalMediaStream first, and not. =C2=A0This is, however, analogous to = setting
    > "negotiated: true" in createDataChannel. =C2=A0On way is &qu= ot;Just Work", and the
    > other is more advanced control.
    >
    > - All the options in MediaCodecDescription are a bit complicated. =C2= =A0Really,
    > this is only necessary because Plan A requires being able to specify c= odec
    > parameters per SSRC, and set each flow on different transports. =C2=A0= If we did
    > not have this requirement, we could simplify.
    >
    >
    > Example Usage:
    >
    > // Imagine I have MyApp, handles creating a PeerConnection,
    > // signalling, and rendering streams. =C2=A0This is how the new API co= uld be
    > // used.
    > var peerConnection =3D MyApp.createPeerConnection();
    >
    > // On sender side:
    > var stream =3D MyApp.getMediaStream();
    > var localStream =3D peerConnection.createSendStream(stream);
    > sendStream.description =3D MyApp.modifyStream(localStream.description)=
    > MyApp.signalAddStream(localStream.description, function(response)) { > =C2=A0 if (!response.rejected) {
    > =C2=A0 =C2=A0 // Media will not be sent.
    > =C2=A0 =C2=A0 peerConnection.addStream(localStream);
    > =C2=A0 }
    > }
    >
    > // On receiver side:
    > MyApp.onAddStreamSignalled =3D function(streamDescription) {
    > =C2=A0 var stream =3D peerConnection.createReceiveStream(streamDescrip= tion);
    > =C2=A0 MyApp.renderStream(stream);
    > }
    >
    >
    > // In this exchange, the MediaStreamDescription signalled from the
    > // sender to the receiver may have looked something like this:
    >
    > {
    > =C2=A0 tracks: [
    > =C2=A0 {
    > =C2=A0 =C2=A0 id: "audio1",
    > =C2=A0 =C2=A0 kind: "audio",
    > =C2=A0 =C2=A0 flows: [
    > =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 id: "main",
    > =C2=A0 =C2=A0 =C2=A0 transportId: "transport1",
    > =C2=A0 =C2=A0 =C2=A0 ssrc: 1111,
    > =C2=A0 =C2=A0 =C2=A0 codecs: [
    > =C2=A0 =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 111,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 name: "opus",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 },
    > =C2=A0 =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 112,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 name: "pcmu",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 }]
    > =C2=A0 =C2=A0}]
    > =C2=A0},
    > =C2=A0{
    > =C2=A0 =C2=A0 id: "video1",
    > =C2=A0 =C2=A0 kind: "video",
    > =C2=A0 =C2=A0 flows: [
    > =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 id: "sim0",
    > =C2=A0 =C2=A0 =C2=A0 transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0 ssrc: 2222,
    > =C2=A0 =C2=A0 =C2=A0 codecs: [
    > =C2=A0 =C2=A0 =C2=A0 {
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 name: "vp8"
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... more codec details
    > =C2=A0 =C2=A0 =C2=A0 }]
    > =C2=A0 =C2=A0},
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0id: "sim1",
    > =C2=A0 =C2=A0 =C2=A0transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0ssrc: 2223,
    > =C2=A0 =C2=A0 =C2=A0codecs: [
    > =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "vp8",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0// ... more codec details
    > =C2=A0 =C2=A0 =C2=A0}]
    > =C2=A0 =C2=A0},
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0id: "sim2",
    > =C2=A0 =C2=A0 =C2=A0transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0ssrc: 2224,
    > =C2=A0 =C2=A0 =C2=A0codecs: [
    > =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "vp8",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0// ... more codec details
    > =C2=A0 =C2=A0 =C2=A0}]
    > =C2=A0 =C2=A0},
    >
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0id: "sim0fec",
    > =C2=A0 =C2=A0 =C2=A0transportId: "transport2",
    > =C2=A0 =C2=A0 =C2=A0ssrc: 2225,
    > =C2=A0 =C2=A0 =C2=A0codecs: [
    > =C2=A0 =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0payloadType: 122,
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0name: "vp8",
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0// ...
    > =C2=A0 =C2=A0 =C2=A0}]
    > =C2=A0 =C2=A0}],
    > =C2=A0 =C2=A0flowGroups: [
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0semantics: "SIM",
    > =C2=A0 =C2=A0 =C2=A0ssrcs: [2222, 2223, 2224]
    > =C2=A0 =C2=A0},
    > =C2=A0 =C2=A0{
    > =C2=A0 =C2=A0 =C2=A0semantics: "FEC",
    > =C2=A0 =C2=A0 =C2=A0ssrcs: [2222, 2225]
    > =C2=A0 =C2=A0}]
    > =C2=A0}]
    > }
    >
    >
    > Constructive feedback is welcome :).
    >
    > ________________________= _______________________
    > rtcweb mailing list
    > rtcweb@ietf.org
    > https://www.ietf.org/mailman/listinfo/rtcweb
    >

    --f46d042ef48d5f815104df834f2d-- From pthatcher@google.com Wed Jun 19 08:47:17 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B65921F9D5E for ; Wed, 19 Jun 2013 08:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q69NvAEdqz+3 for ; Wed, 19 Jun 2013 08:47:16 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A242521F9D22 for ; Wed, 19 Jun 2013 08:47:16 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lf11so5246817pab.24 for ; Wed, 19 Jun 2013 08:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PdsgXqCo8V4k2c6pm/7nU2gNWaht6ABr5nL/BmnHyHk=; b=AUl57kZtXqNOOPLfHWsAOxGqrXl4pe0EbzThCT9dZDzN/Wr/6SCJA7FlmrbPgFXGDN mtzv/Df+ElC94Rwwue2/t5uywCXlbSPb4qq2w5niyDf8pRIO/JPGN4TaCwbHz19jz6UM 6pqLjnRUkvByxrNlEko0LPuyRHsapaFMhBSVFB7pvoCgltJbHQx4aF8LmGroqzjal/tz BWxFaD4qEX4ZkiVVcanh1Ysk0IxGjeGNnf7Kz90XQRr6p2M4R3lPuiNlCLl+WqynpA+8 +bGrP6+EUmSlYKs2AN5EA5+9GmEi11V55wvGrK13g5fL6zqjGohSlpivEpPOIHjIesy6 bgIQ== 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=PdsgXqCo8V4k2c6pm/7nU2gNWaht6ABr5nL/BmnHyHk=; b=IBoT0QSQySryQ1BIMsKpu+Db+Ez8JKUMptrTsMtQO6S/Cm4tX6nbPQpCwIIX8mgDqT O9M/LeiFlsE5VGZGpg9MUEHeZ8vicXW14CSsVGwBh0spUaTToQIuiIWnvoYGbO2HKRDS zem4wmu7972AK2JKRN481zzdntYzbMsHqBmygVR764yF+C1bUpLrVduFwUVE5W2B8++e JUPsqsYyWYS8iSadztZ1+ps134Rhkp+lpbDQfqRKQwhYw/lF80gt+25NE+yJ+H8AEt9o sxhXsSUZi3P0xJtmx1Ksnyhc5pLssNzQZttFA9POwuXWNP2l1hUYa4YgIA7vke1Flfzn 0ShQ== X-Received: by 10.68.1.226 with SMTP id 2mr3432430pbp.150.1371656836274; Wed, 19 Jun 2013 08:47:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 08:46:36 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Wed, 19 Jun 2013 08:46:36 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=bcaec53148177af8fd04df83beab X-Gm-Message-State: ALoCoQmp0VdbZEqJRiXhV4BztbcK9QStFedzWZxwjrtldv0+hE06W0NwqgfFUfw0Zm5S3gJfflnPLcru1u8w3Em8kJnQwvEJBlJgQrGZZXt1Q0EWRiaQ2spZiXMgyoQfC3Cph+zyVTJe5e6YGnPV6BWtfx7VMS34MmfANRaiD8MvJLhEnvOmFAvNeShcf5QOAe/hZLKqSwbD Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 15:47:17 -0000 --bcaec53148177af8fd04df83beab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I put some comments inline, but I'd like to offer a few suggestinos to all of those in the "SDP Rebellion" fighting the "SDP Empire": - A clear, succinct description of what you need and why is a lot more useful and will lead to more progress than long rants about what you hate an why. - The WG usually likes use cases. Do you have any real world uses cases that the current API doesn't provider, or that makes painful? - It would be helpful to minimize the diff to the current API that you need. Saying "blow up everything and do it how I want" is hard do swallow (witness comment 22). Saying "here's a small change that would relieve a lot of pain" might make more progress (although even not's clear if even that's possible). On Wed, Jun 19, 2013 at 1:38 AM, I=C3=B1aki Baz Castillo wr= ote: > 2013/6/19 Christer Holmberg : > > We need to be very clear what we talk about, or some people are always > going > > to be confused :) > > > > So, AFAIK, the discussion is about SDP O/A usage in the API, only in th= e > > API, and nowhere but the API. > > > > Whatever people us on the wire is outside the scope. > > > Hi Christer, > > I do not dare to summarize what we request in a single response, and I > don't want to say something that "I didn't want to say" ;) > > IMHO this thread clearly describes what we request, i.e. in these exact > mails: > > - http://www.ietf.org/mail-archive/web/rtcweb/current/msg07895.html > - http://www.ietf.org/mail-archive/web/rtcweb/current/msg07896.html > - http://www.ietf.org/mail-archive/web/rtcweb/current/msg07899.html > > > My "non-normative" summary: > > I don't think that the discussion is just about "SDP O/A usage in the > API". We don't want a replacement for SDP, nor a new representation of > SDP, nor to deal with blob strings between the JS layer and the WebRTC > layer. Please at least agree with Christer that this is about the API, not about the signalling wire format. The API already allows whatever signalling wire format you want, and everything you mention from here on out is just the API. So please just say to Christer "yes, this is all about the API". It will make the rest of the discussion much more clear. > In short we want something like a JS wrapper of the native > WebRTC API, I work on the WebRTC implementation in Chrome, and I don't know what you mean by "native WebRTC API". Such a thing does not really exist. The implementation has three different layers of abstraction, each of which you might be referring to, but none of them which will give you what you want. The highest level uses SDP. The lowest level gives you media bits, but no ICE, SRTP, DTLS, or SCTP. The middle layer gives you all those things without SDP, but it still uses an abstract offer/answer for transport and RTP setup (and even has a Jingle implementation on top of that). None of those give you what you want. The "native WebRTC API" that you want to wrap doesn't exist. to directly manage media/transport parameters and media > streams without having to pass a monolithic and unmanageable SDP blob > between the JS and the WebRTC layer. That boils down to "the same power of the current API, without going through SDP". I think that's a clear requirement. So why don't you just say that? Would save everyone a lot of reading and misunderstanding. calls to get the required media parameters, the JS can send them to > the remote peer in the way it prefers (which may be via a SDP created > by the JS app, or via an AJAX request for sending codecs/media-types > info followed by a WebSocket connection for sending ICE candidates one > by one, or serialized in JSON via a previously open DataChannel > session... or whatever mechanism available in the Web and browsers). > > You already have that. > For sure, other participants in this thread can improve/fix my "summary". > > Please. re-read the 3 links above, IMHO they should clearly describe > what we are requesting for :) > > > Best regards. > > > > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec53148177af8fd04df83beab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I put some comments inline, but I'd like to offer a fe= w suggestinos to all of those in the "SDP Rebellion" fighting the= "SDP Empire":

    - A clear, succinct description= of what you need and why is a lot more useful and will lead to more progre= ss than long rants about what you hate an why.

    - The WG usually likes use cases. =C2=A0Do you have any= real world uses cases that the current API doesn't provider, or that m= akes painful? =C2=A0

    - It would be helpful to mini= mize the diff to the current API that you need. =C2=A0Saying "blow up = everything and do it how I want" is hard do swallow (witness comment 2= 2). =C2=A0Saying "here's a small change that would relieve a lot o= f pain" might make more progress (although even not's clear if eve= n that's possible).


    On Wed, = Jun 19, 2013 at 1:38 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net>= wrote:
    2013/6/19 Christer Holmberg <christer.holmberg@ericsson.com>:
    > We need to be very clear what we talk about, or some people are a= lways going
    > to be confused :)
    >
    > So, AFAIK, the discussion is about SDP O/A usage in the API, only in t= he
    > API, and nowhere but the API.
    >
    > Whatever people us on the wire is outside the scope.


    Hi Christer,

    I do not dare to summarize what we request in a single response, and I
    don't want to say something that "I didn't want to say" ;= )

    IMHO this thread clearly describes what we request, i.e. in these exact mai= ls:

    -     http://www.ietf.org/mail-archive/web/rtcweb/current/= msg07895.html
    - http://www.ietf.org/mail-archive/web/rtcweb/current/= msg07896.html
    - http://www.ietf.org/mail-archive/web/rtcweb/current/= msg07899.html


    My "non-normative" summary:

    I don't think that the discussion is just about "SDP O/A usage in = the
    API". We don't want a replacement for SDP, nor a new representatio= n of
    SDP, nor to deal with blob strings between the JS layer and the WebRTC
    layer.

    Please at least agree with Christer= that this is about the API, not about the signalling wire format. =C2=A0Th= e API already allows whatever signalling wire format you want, and everythi= ng you mention from here on out is just the API. =C2=A0So please just say t= o Christer "yes, this is all about the API". =C2=A0It will make t= he rest of the discussion much more clear.
    =C2=A0
    In short we want something like a JS wrap= per of the native
    WebRTC API,

    I work on the WebRTC implement= ation in Chrome, and I don't know what you mean by "native WebRTC = API". =C2=A0Such a thing does not really exist. =C2=A0The implementati= on has three different layers of abstraction, each of which you might be re= ferring to, but none of them which will give you what you want. =C2=A0The h= ighest level uses SDP. =C2=A0The lowest level gives you media bits, but no = ICE, SRTP, DTLS, or SCTP. =C2=A0The middle layer gives you all those things= without SDP, but it still uses an abstract offer/answer for transport and = RTP setup (and even has a Jingle implementation on top of that). =C2=A0None= of those give you what you want. =C2=A0The "native WebRTC API" t= hat you want to wrap doesn't exist.

    to directly manage media/transport paramete= rs and media
    streams without having to pass a monolithic and unmanageable SDP blob
    between the JS and the WebRTC layer.

    That = boils down to "the same power of the current API, without going throug= h SDP". =C2=A0I think that's a clear requirement. =C2=A0So why don= 't you just say that? =C2=A0Would save everyone a lot of reading and mi= sunderstanding.


    calls to get the required media parameters, the JS can send them to
    the remote peer in the way it prefers (which may be via a SDP created
    by the JS app, or via an AJAX request for sending codecs/media-types
    info followed by a WebSocket connection for sending ICE candidates one
    by one, or serialized in JSON via a previously open DataChannel
    session... or whatever mechanism available in the Web and browsers).


    You already have that.
    =C2= =A0
    For sure, other participants in this thread can improve/fix my "summar= y".

    Please. re-read the 3 links above, IMHO they should clearly describe
    what we are requesting for :)


    Best regards.



    --
    I=C3=B1aki Baz Castillo
    <ibc@aliax.net>= ;
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

    --bcaec53148177af8fd04df83beab-- From robin@hookflash.com Wed Jun 19 08:59:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C000421F9DC2 for ; Wed, 19 Jun 2013 08:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.112 X-Spam-Level: X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jq9IJEy+g12z for ; Wed, 19 Jun 2013 08:59:33 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 82E4A21F9DB1 for ; Wed, 19 Jun 2013 08:59:30 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va7so6099545obc.41 for ; Wed, 19 Jun 2013 08:59:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=+1NDFXjryrrUcrpd0gKi5jH8+P+jMyEK4sje3gXHgb8=; b=kITzcJSuTCmrNwQDZJsJPJpWS28lyZasDXKl2NTTxxP86TKJhOC4CCAZJECPHOAql9 UERprc5Pa52+ad4Bd07LOrUgqe2KNH8HvaEjWurDVjQMce38gudWhqqbkS2s5hBjBXRx xhYV8RnjvjNNZRO4DQ2wTWiBMnYLq7R+PrzpHcj34mY7RJg+yFXMoGGdkap1EBUdvXdt Dgx76iney2eJC9/ZLuHHujLmP/NpdyEwZwGpH7uh3FtGwaJ+MC/3vrdoDqM1/Dqpas1u CyH9oSUq5mYM5DfQqf4SkCAO+DxzrWoGdRQCQuVsQdhZycbiHs+UsEtq6zySMYufNaoj feVw== X-Received: by 10.60.60.196 with SMTP id j4mr2414256oer.37.1371657570114; Wed, 19 Jun 2013 08:59:30 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id i2sm25266566obz.11.2013.06.19.08.59.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 08:59:28 -0700 (PDT) Message-ID: <51C1D55D.6040905@hookflash.com> Date: Wed, 19 Jun 2013 11:59:25 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Peter Thatcher References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080705040102020905040401" X-Gm-Message-State: ALoCoQn6ccyKq9PNaqPA9jEJQ8G1QPvFpfxDQB8A7DsUFM7GZcRZsWlySp9IzyeO9DfUzgNf8YEK Cc: "" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 15:59:33 -0000 This is a multi-part message in MIME format. --------------080705040102020905040401 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Then why not move to a lower level API and do it as a shim (i.e. reverse polyfill)? If provided a lower level API that works without SDP where the individual network/media component wiring/attributes can be controlled, we could create the same WebRTC API that exists today for people who think "SDP out to be enough for anybody" layered on top of it; They lose absolutely nothing (in fact they gain a lot since now they can tweak the logic to be even more compatible with their networks and dynamically update it as needed instead of waiting for the next browser "patch" to be deployed everywhere on all platforms). The only different is that it's an JavaScript implementation rather than written in C++. They get what they want but we get what we need. That's the difference, they *want* this API as it "works/good enough for them", whereas many of *need* a lower level API to do anything sophisticated at all. As it stands, it makes many use cases for us who whom don't want to do basic SIP/SDP signaling extremely challenging, complex, ugly, brittle, if not outright impossible. I've explained many times why using SDP with offer/answer is horribly bad idea (and I can re-share those links if needed). -Robin > Peter Thatcher > 19 June, 2013 11:15 AM > > > > I hope so as well. Unfortunately, Microsoft's input seems to be "our > way or the highway" and the input of others seems to be "SDP ought to > be enough for anybody". My thinking is that we can make incremental > improvements toward a cleaner API without being so extreme at either > end. And I hope I can find others that think similarly. > > --------------080705040102020905040401 Content-Type: multipart/related; boundary="------------010604040403010401000601" --------------010604040403010401000601 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
    Then why not move to a lower level API and do it as a shim (i.e. reverse polyfill)?

    If provided a lower level API that works without SDP where the individual network/media component wiring/attributes can be controlled, we could create the same WebRTC API that exists today for people who think "SDP out to be enough for anybody" layered on top of it; They lose absolutely nothing (in fact they gain a lot since now they can tweak the logic to be even more compatible with their networks and dynamically update it as needed instead of waiting for the next browser "patch" to be deployed everywhere on all platforms). The only different is that it's an JavaScript implementation rather than written in C++. They get what they want but we get what we need.

    That's the difference, they *want* this API as it "works/good enough for them", whereas many of *need* a lower level API to do anything sophisticated at all. As it stands, it makes many use cases for us who whom don't want to do basic SIP/SDP signaling extremely challenging, complex, ugly, brittle, if not outright impossible. I've explained many times why using SDP with offer/answer is horribly bad idea (and I can re-share those links if needed).

    -Robin


    19 June, 2013 11:15 AM



    I hope so as well.  Unfortunately, Microsoft's input seems to be "our way or the highway" and the input of others seems to be "SDP ought to be enough for anybody".  My thinking is that we can make incremental improvements toward a cleaner API without being so extreme at either end.  And I hope I can find others that think similarly.


    --------------010604040403010401000601 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------010604040403010401000601-- --------------080705040102020905040401-- From harald@alvestrand.no Wed Jun 19 09:04:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C6C21F9A12 for ; Wed, 19 Jun 2013 09:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.548 X-Spam-Level: X-Spam-Status: No, score=-110.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8raZ+l6AGXt for ; Wed, 19 Jun 2013 09:04:05 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 84B5C21F9A65 for ; Wed, 19 Jun 2013 09:03:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0092139E128 for ; Wed, 19 Jun 2013 18:03:25 +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 q15Y0SxFknwU for ; Wed, 19 Jun 2013 18:03:23 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id BE86439E0E1 for ; Wed, 19 Jun 2013 18:03:23 +0200 (CEST) Message-ID: <51C1D64A.7000900@alvestrand.no> Date: Wed, 19 Jun 2013 18:03:22 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030806070207030803010706" Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 16:04:11 -0000 This is a multi-part message in MIME format. --------------030806070207030803010706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/19/2013 05:15 PM, Peter Thatcher wrote: > > > > On Mon, Jun 17, 2013 at 6:00 PM, Silvia Pfeiffer > > wrote: > > Hi Peter, all, > > I'm looking at all this from the view of a JS developer and I am > really excited that there is movement in this space. Having hit my > head hard against the limitations of the current WebRTC API and being > forced to learn SDP to achieve some of the less common use cases, I'm > feeling the pain. I am therefore happy to see that there is a proposal > for a higher-level API with similarities to the Microsoft's CU-WebRTC > proposal and I hope that together with Microsoft's input this can > become a really useful API. > > > I hope so as well. Unfortunately, Microsoft's input seems to be "our > way or the highway" and the input of others seems to be "SDP ought to > be enough for anybody". My thinking is that we can make incremental > improvements toward a cleaner API without being so extreme at either > end. And I hope I can find others that think similarly. > > > What I would like to see, though, is a bit different from what you've > proposed. In particular, the MediaFlowDescription object is the one > object that I believe is supposed to enable JS developers to do "SDP > hacking" without having to understand SDP. Unfortunately, the way in > which it is currently written, this API doesn't help a JS developer > much. There are properties in that object like "ssrc" that mean > nothing unless you understand SDP. > > > Actually, it helps some JS developer a lot. It happens to be very > good for the JS I am writing :). > And it might be really obvioius and come across as really condescending, but there's absolutely no way anyone can write sensible code to control the parameters of transmission or encoding without understanding how that controlling affects the transmission or encoding. Thus, as long as one uses RTP, one needs to understand concepts like payload types, SSRCs, RTP sessions, RTCP feedback and so on - OR accept that one programs to a higher level abstraction where these attributes are not visible, and accept that one does not have control over them. In some cases, interfaces can be made with "options" - so that if one doesn't care, one gets a sensible default, and if one does care, one can get detailed control - but sometimes, one has to pick the level of an interface. I'd like to think that we recognize that these tradeoffs have to be made. --------------030806070207030803010706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    On 06/19/2013 05:15 PM, Peter Thatcher wrote:



    On Mon, Jun 17, 2013 at 6:00 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
    Hi Peter, all,

    I'm looking at all this from the view of a JS developer and I am
    really excited that there is movement in this space. Having hit my
    head hard against the limitations of the current WebRTC API and being
    forced to learn SDP to achieve some of the less common use cases, I'm
    feeling the pain. I am therefore happy to see that there is a proposal
    for a higher-level API with similarities to the Microsoft's CU-WebRTC
    proposal and I hope that together with Microsoft's input this can
    become a really useful API.

    I hope so as well.  Unfortunately, Microsoft's input seems to be "our way or the highway" and the input of others seems to be "SDP ought to be enough for anybody".  My thinking is that we can make incremental improvements toward a cleaner API without being so extreme at either end.  And I hope I can find others that think similarly.


    What I would like to see, though, is a bit different from what you've
    proposed. In particular, the MediaFlowDescription object is the one
    object that I believe is supposed to enable JS developers to  do "SDP
    hacking" without having to understand SDP. Unfortunately, the way in
    which it is currently written, this API doesn't help a JS developer
    much. There are properties in that object like "ssrc" that mean
    nothing unless you understand SDP.

    Actually, it helps some JS developer a lot.  It happens to be very good for the JS I am writing :).
     

    And it might be really obvioius and come across as really condescending, but there's absolutely no way anyone can write sensible code to control the parameters of transmission or encoding without understanding how that controlling affects the transmission or encoding.

    Thus, as long as one uses RTP, one needs to understand concepts like payload types, SSRCs, RTP sessions, RTCP feedback and so on - OR accept that one programs to a higher level abstraction where these attributes are not visible, and accept that one does not have control over them.

    In some cases, interfaces can be made with "options" - so that if one doesn't care, one gets a sensible default, and if one does care, one can get detailed control - but sometimes, one has to pick the level of an interface.

    I'd like to think that we recognize that these tradeoffs have to be made.

    --------------030806070207030803010706-- From ibc@aliax.net Wed Jun 19 09:10:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDCE21F9E18 for ; Wed, 19 Jun 2013 09:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGeL18Jdddkq for ; Wed, 19 Jun 2013 09:10:33 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 07AD621F9E16 for ; Wed, 19 Jun 2013 09:10:29 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id n1so3092806qcx.8 for ; Wed, 19 Jun 2013 09:10: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=VhhFCc9TvdJpDyhI5a3Ps+/US2zjLQ13DbIidJ+FgjI=; b=D3TXIZSdf67d+SucfGg8YDfBq21qOSXTQ4YQitFOsbqgX96NMfqwynB0doDat2nfCs 5j5YzXyTq0VyT6VZzI5cuVvTRZs7Gqy/YP8l2mRqGU6Hq8MVtN1OkIaSJ20GnaAuPVrm C/gR9psE2BNCqKA6Mjc1hK91M5HqOrtQyJRAOQ4VkPnZL1DrSn4/SNDAcazkC76w3L+n QFKSf+eTKm93tbMrBxDJuyMi+PJEL2XDo96EkzyZF0attFUYcxiFlWsgbaH+/8Fe3/es P0pM559a9vmrhePcjbw3oXvZsRurtrahbr/Tn+VFC8CPqUb3yZX3M6DtsjPt+bw606HC vrKQ== X-Received: by 10.49.81.244 with SMTP id d20mr4391444qey.33.1371658229031; Wed, 19 Jun 2013 09:10:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 09:10:07 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 19 Jun 2013 18:10:07 +0200 Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnnMeFswOy0Kxmr3qyoTFsz9zX2sQLL20YxfJ/LVFFnJwU4RSBn1zC2UOFqjhWHm3OoKyQq Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 16:10:34 -0000 Hi Peter, for now just some comments (I agree that more use cases and other considerations must be provided): >> I don't think that the discussion is just about "SDP O/A usage in the >> API". We don't want a replacement for SDP, nor a new representation of >> SDP, nor to deal with blob strings between the JS layer and the WebRTC >> layer. > > > Please at least agree with Christer that this is about the API, not about > the signalling wire format. The API already allows whatever signalling w= ire > format you want, IMHO that is not entirely true. First of all, whichever the signaling protocol is, it must accomplish with SDP O/A semantics (since it must carry a SDP and receive a SDP to establish the communication). Second: Indeed the current spec does not mandate what should be sent in the wire. In practice that means we can use SIP over WebSocket, XMPP/Jingle over HTTP, or whatever. But in practice it also means that we must send a SDP in the wire. The SDP blob string can be hex-encoded/escaped/mangled/whatever by the JS app, but the SDP blob string generated by PeerConnection-A should arrive to PeerConnection-B. And since such a SDP is generated by the WebRTC stack and passed to the JS as an unmanageable blob string, the JS app cannot properly deal with it. So, currently WebRTC does not mandate the signaling protocol in-the-wire, but it does mandate the media signaling protocol in-the-wire (you need to pass a working SDP to the remote, sure), something that constrains the signaling protocol itself. > and everything you mention from here on out is just the > API. So please just say to Christer "yes, this is all about the API". I= t > will make the rest of the discussion much more clear. Ok, this is all about the API :) >> In short we want something like a JS wrapper of the native >> WebRTC API, > > > I work on the WebRTC implementation in Chrome, and I don't know what you > mean by "native WebRTC API". Such a thing does not really exist. The > implementation has three different layers of abstraction, each of which y= ou > might be referring to, but none of them which will give you what you want= . > The highest level uses SDP. The lowest level gives you media bits, but n= o > ICE, SRTP, DTLS, or SCTP. The middle layer gives you all those things > without SDP, but it still uses an abstract offer/answer for transport and > RTP setup (and even has a Jingle implementation on top of that). None of > those give you what you want. The "native WebRTC API" that you want to w= rap > doesn't exist. Ok, IMHO nobody is still requesting a specific JS API but just describing the features and capabilities such an API must provide. The "similar to native WebRTC API" is just a comment to help understanding what we mean, but of course each browser is free to implement its native API(s) as it prefers so the "JS wrapper" concept does not make sense. >> to directly manage media/transport parameters and media >> streams without having to pass a monolithic and unmanageable SDP blob >> between the JS and the WebRTC layer. > > > That boils down to "the same power of the current API, without going thro= ugh > SDP". I think that's a clear requirement. So why don't you just say tha= t? > Would save everyone a lot of reading and misunderstanding. You are right. >> calls to get the required media parameters, the JS can send them to >> the remote peer in the way it prefers (which may be via a SDP created >> by the JS app, or via an AJAX request for sending codecs/media-types >> info followed by a WebSocket connection for sending ICE candidates one >> by one, or serialized in JSON via a previously open DataChannel >> session... or whatever mechanism available in the Web and browsers). >> > > You already have that. Can I first send my codecs list, then (once the peer notifies me codecs compatibility) send the codecs preference order, then my ICE candidates and later (not just when ICE process terminates) signal the peer a "OK" message so we both start the multimedia audio/video/data communication, all of this with the current API? (I mean without parsing the SDP blob and splitting it into blob fragments). Best regards. -- I=C3=B1aki Baz Castillo From pthatcher@google.com Wed Jun 19 09:29:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15F021F9CC1 for ; Wed, 19 Jun 2013 09:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YSfhZo7H3yS for ; Wed, 19 Jun 2013 09:29:30 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 20D8F21F9C46 for ; Wed, 19 Jun 2013 09:29:15 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro2so5239770pbb.13 for ; Wed, 19 Jun 2013 09:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OFllY49bwArGAN4nwtFWH+2H/NUc+0lsgpaOlnYEN+Y=; b=K44WI8iYUqVjfSxV9jOdYT3qJ2D0krbY2gdkqvzO4Dlx589pdHQ8jfLjtPhPKCnREh 0Km23xEvg3+f6UWCFiJGEosD6y0Skj985caHwOzTKV0PIOQVB3QBiXHJ+4QFT+3IjLzi JCrQW6lLYgPrmmxxRx8zwjcGLrxBBB3C5G7egSZfMQwp2NWrfKxY+kKzP8FtR8TNiU/Q 0RJBV36o0zxaa/DDMGG809A073pXkyNKC0d+9xQqiR41kGb8r6RtpNyxp4YD5mEvJXpd cFL/rUFzqr2WQ4uZXBrVEXBPU2YlOl32pOF/KB61CF9wQ0Q5MGE50qjbogwqiJZVkp3a mVzQ== 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=OFllY49bwArGAN4nwtFWH+2H/NUc+0lsgpaOlnYEN+Y=; b=cepfZzCdIUl10dTAB2QSWqIrscunVMopLsUkN9Fp5AwER7vVw7OdNelGDHEEkQVV0M I014QHQnMyTRU+WnpJiotP4e8jF2gnM2p8XWswU6VMAlABiKgPbDJIvLSbWy1+6jLQhA sQfblm/jva3HjVm62s1kwPWwz/kZNzGNIUsuG87EyrtO6Qf5TsYGVgEP8p10Cp58THby gtMWpjR6WyxM2RBg+CH0cNWDQeDVQVZ6CIH/F/B44G7n0RvnJfvwNe37nVIbP7xKiRJ0 7v/0G9RRSnO/zlYmfpKXuavu8kOfLrRVZKvIvGnR5hLXQVVS1O05M+gKcY1QGWzmNo8t KlGg== X-Received: by 10.68.175.68 with SMTP id by4mr3625100pbc.53.1371659354784; Wed, 19 Jun 2013 09:29:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 09:28:31 -0700 (PDT) In-Reply-To: <51C1B907.8060508@hookflash.com> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> From: Peter Thatcher Date: Wed, 19 Jun 2013 09:28:31 -0700 Message-ID: To: Robin Raymond Content-Type: multipart/related; boundary=047d7bd6c6ac985ffd04df84541a X-Gm-Message-State: ALoCoQlzBwHVp9gjktiMHCD33MECksOEyG3xRmDdgUHW0u3gKfh4i6Bskjy5W4e6OZDTkDagxbgNJqjW8bk1BDZlVmxjVJ1IEIlfW7M4Xs+h+BrbdfgnU2AwLpxXV3GXpyq5moJQT8kGoKiYOExF1eqiolKKfc8ZkuFxZJwf21wX6Sfixax0AdUPZnVI25J6hwQRN6Hp5EOr Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 16:29:31 -0000 --047d7bd6c6ac985ffd04df84541a Content-Type: multipart/alternative; boundary=047d7bd6c6ac985ffb04df845419 --047d7bd6c6ac985ffb04df845419 Content-Type: text/plain; charset=UTF-8 I might be wrong, but I tried reading and understanding your whole email, and it seems to come down to "I don't want to use SDP or a different (JSON) form of SDP". That's a fine thing to request, but why don't you just say that? It would save everyone a lot of reading and confusion to be more concise. Or, if you have specific things you'd like to do but can't, what are they? I think that would help me, and others, understand more easily. Use cases would be helpful. On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond wrote: > > The trouble is not that we can choose to send whatever we want over the > wire. I know we can. If the WebRTC API is left with SDP as it stands, I'll > dissect the SDP from the browser, reinterpret and reconstruct on the SDP on > the remote side. That is NOT the issue. > > The summary of what I want/believe: > 1) I want as close to raw access to RTP/ICE streams, media, sources, > outputs, codecs as viable. Obviously doing the actual transmission, > encoding/decoding from JS is not feasible (yet), nor is secure [ICE must > occur for mutual agreement to exchange data between peers], but having > controls for how these components are wired together is extremely feasible > from JS and would allow immensely powerful apps to be produced from JS. > What would you like to do that you can't do via SDP right now? You said this isn't just about working through SDP. But I don't see anything concrete you can't do right now with sufficient SDP parsing/building/munging/hackery. > 2) I don't want my primary interface to control media/RTP engines to be > via obtaining or providing SDPs to the browser (or any alternative > serialized format); especially given that SDP requires a round trip > offer/answer to the remote party to affect change (e.g. it's entirely > possible to do that stateless and one-sided). The SPD interface API is a > monolithic do-everything serialized format to control an engine but > extremely badly/poorly/short sighted (regardless if it is SDP or whatever > instead), and it's wholly unneeded. > Short summary: "I don't want to use SDP". Right? 3) I don't want a replacement for SDP with another more "pretty" format > like JSON. > Short summary: "I don't want to use SDP or a different syntax for SDP". Right? 4) I want no specified requirement from the browser to have any particular > form of media negotiation API requirement what-so-ever (regardless if I can > opt to substitute with my own format on the wire or not) > Short summary: "I don't want to use SDP or a different syntax for SDP". Right? > 5) Using SDP with offer/answer build into the browser binary is a horribly > BAD technical choice (even for SIP folks) and must be stopped, see: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html > Short summary: "I don't want to use SDP". Right? > > > I too want to understand the rational for keeping something as bad as SDP > with offer/answer as the primary mechanism for controlling the media > components and interaction to those component and more importantly, I'd too > would like to open debate to agreeing or not to provide a lower layer API > rather than a media negotiation API as a complete substitute alternative to > SDP with offer/answer. > > If we can agree that it's far superior to have a lower level media/RTC > component API rather than a media negotiation API, then we can propose what > that API could look like (and there are people who have already have > starting proposals). I'd throw my hat in the ring to propose such and API > if necessary as I've written such engines from scratch before. But I don't > want to waste time proposing ore reviewing such an API which will be > summarily dismissed because people are so stuck on requiring a media > negotiation API built into the browser binary, and specifically SDP with > offer/answer in this case. > The WG may dislike and reject your proposal, but there's a bit of truth to the old mathematically incorrect sports adage "you miss 100% of the shots you don't take". Anyone who argues that they need/want that simple SDP media negotiation API > must understand that a lower level API would allow a wrapper API to produce > the same WebRTC API the have today but be built entirely from JavaScript > That depends on how low-level you go. If you go too low-level, it becomes infeasible to do things correctly and performantly in JavaScript. > upon a lower level API. Thus they can have their "just add-milk" baking > API. But those of us who need control of the raw ingredients beyond the > "just add milk" can still innovate. > > -Robin > > > Peter Thatcher > 19 June, 2013 2:49 AM > Correct my if I'm wrong, but the API already leaves what goes over the > wire completely up to the JS app. So we couldn't re-open a debate of "SDP > or not SDP" for the wire format, because there's nothing to debate. We > already decided it would be left to the JS to decide. The only thing left > to debate is the API. > > Or am I wrong? > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Christer Holmberg > 19 June, 2013 2:34 AM > Hi, > > We need to be very clear what we talk about, or some people are always > going to be confused :) > > So, AFAIK, the discussion is about SDP O/A usage in the API, only in the > API, and nowhere but the API. > > Whatever people us on the wire is outside the scope. > > Right? > > Regards, > > Christer > > > > Sent from *Windows* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Peter Thatcher [pthatcher@google.com] > *To:* Martin Thomson [martin.thomson@gmail.com] > *CC:* rtcweb@ietf.org [rtcweb@ietf.org] > *Subject:* Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened > Martin, you're right; that was overly harsh of me. Adam, I apologize. > I'll be civil in the future. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Peter Thatcher > 19 June, 2013 1:36 AM > Martin, you're right; that was overly harsh of me. Adam, I apologize. > I'll be civil in the future. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Martin Thomson > 18 June, 2013 6:25 PM > I agree with Peter, except for this bit: > > Adam is much harder to confuse than you think, or than he professes. > > Speaking of burning it all down and starting over. If you want a > house-related analogy, that's not quite correct. It's refusing to > build an extension because the old house, while legally fit for > habitation, is falling down around your ears. Since you only need > foundations, it's not that big a job (though I'll grant you that it's > bigger than many people realize, even with that smaller scope). > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Peter Thatcher > 18 June, 2013 6:16 PM > Adam, I think you're confused. As Ted pointed out, there are two > different uses of SDP: 1. as a control surface, 2. as a message format for > signalling. SDPNG was trying to replace SDP for #2. While I believe this > thread was started entirely focused on #1. So you're talking about > different things. > > So far the only time spent on trying to replace or avoid SDP for #1 has > been "comment 22", and to a lesser extent the proposal I just made for > adding 2 methods to PeerConnection (createLocalStream and > createRemoteStream). I think it's incorrect to conclude that we should > never try to improve #1 just because other in the past failed to replace > #2. They're very different. > > I also don't think we should burn down WebRTC and start over, but despite > what some seem to think, we don't have to choose between "burn it down" and > "never improve it". There are many options other than the two extremes. > > > > By the way, a gentle reminder: SDP is not the only way to do #2. I work > on a rather large system almost entirely build around Jingle, without a > hint of SDP, and it works just fine. Much better than SDP would have, I > think. Just because SDPNG didn't work out doesn't mean there will never be > any way other to do signalling than SDP. > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7bd6c6ac985ffb04df845419 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I might be wrong, but I tried reading and understanding yo= ur whole email, and it seems to come down to "I don't want to use = SDP or a different (JSON) form of SDP". =C2=A0That's a fine thing = to request, but why don't you just say that? =C2=A0It would save everyo= ne a lot of reading and confusion to be more concise. =C2=A0

    Or, if you have specific things you'd like to do but can= 't, what are they? =C2=A0I think that would help me, and others, unders= tand more easily. =C2=A0Use cases would be helpful.

    On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond <robin@hookflash.com&= gt; wrote:

    The trouble is not that we can choose to send whatever we want over the=20 wire. I know we can. If the WebRTC API is left with SDP as it stands,=20 I'll dissect the SDP from the browser, reinterpret and reconstruct on= =20 the SDP on the remote side. That is NOT the issue.

    The summary of what I want/believe:
    1) I want as close to raw access to RTP/ICE streams, media, sources,=20 outputs, codecs as viable. Obviously doing the actual transmission,=20 encoding/decoding from JS is not feasible (yet), nor is=20 secure [ICE must occur for mutual agreement to exchange data between=20 peers], but having controls for how these components are wired together=20 is extremely feasible from JS and would allow immensely powerful apps to be produced from JS.

    What would = you like to do that you can't do via SDP right now? =C2=A0You said this= isn't just about working through SDP. =C2=A0But I don't see anythi= ng concrete you can't do right now with sufficient SDP parsing/building= /munging/hackery.

    =C2=A0
    2) I don't want my primary interface to control media/RTP engines to be= =20 via obtaining or providing SDPs to the browser (or any alternative=20 serialized format); especially given that SDP requires a round trip=20 offer/answer to the remote party to affect change (e.g. it's entirely= =20 possible to do that stateless and one-sided). The SPD interface API is a monolithic do-everything serialized format to control an engine but=20 extremely badly/poorly/short sighted (regardless if it is SDP or=20 whatever instead), and it's wholly unneeded.

    Short summary: "I don't want to use SDP". =C2= =A0Right?

    3) I don't want a replacement for SDP with another more "pretty&qu= ot; format=20 like JSON.

    Short summary: "I= don't want to use SDP or a different syntax for SDP". =C2=A0Right= ?

    4) I want no specified requirement from the browser to have any=20 particular form of media negotiation API requirement what-so-ever=20 (regardless if I can opt to substitute with my own format on the wire or not)

    Short summary: "I don't wan= t to use SDP or a different syntax for SDP". =C2=A0Right?
    =C2=A0
    5) Using SDP with offer/answer bu= ild into the browser binary is a=20 horribly BAD technical choice (even for SIP folks) and must be stopped,=20 see: http://www.ietf.org/mail-archive/web/rtcweb/curre= nt/msg07873.html

    Short summary: &= quot;I don't want to use SDP". =C2=A0Right?
    =C2=A0


    I too want to understand the rational for keeping something as bad as=20 SDP with offer/answer as the primary mechanism for controlling the media components and interaction to those component and more importantly, I'= d too would like to open debate to agreeing or not to provide a lower=20 layer API rather than a media negotiation API as a complete substitute=20 alternative to SDP with offer/answer.

    If we can agree that it's far superior to have a lower level media/RTC= =20 component API rather than a media negotiation API, then we can propose=20 what that API could look like (and there are people who have already=20 have starting proposals). I'd throw my hat in the ring to propose such= =20 and API if necessary as I've written such engines from scratch before.= =20 But I don't want to waste time proposing ore reviewing such an API whic= h will be summarily dismissed because people are so stuck on requiring a=20 media negotiation API built into the browser binary, and specifically=20 SDP with offer/answer in this case.


    The WG may dislike and reject your proposal, but there's = a bit of truth to the old mathematically incorrect sports adage "you m= iss 100% of the shots you don't take".


    Anyone who argues that they need/want that simple SDP media negotiation=20 API must understand that a lower level API would allow a wrapper API to=20 produce the same WebRTC API the have today but be built entirely from=20 JavaScript

    That depends on how low-le= vel you go. =C2=A0If you go too low-level, it becomes infeasible to do thin= gs correctly and performantly in JavaScript.
    =C2=A0
    upon a lower level API. Thus the= y can have their "just=20 add-milk" baking API. But those of us who need control of the raw=20 ingredients beyond the "just add milk" can still innovate.

    -Robin


    <= div style=3D"display:table-cell;white-space:nowrap;vertical-align:middle;wi= dth:100%"> Peter Thatcher
    =20 19 June, 2013=20 2:49 AM
    =
    Correct my if=20 I'm wrong, but the API already leaves what goes over the wire completel= y up to the JS app. =C2=A0So we couldn't re-open a debate of "SDP o= r not SDP"=20 for the wire format, because there's nothing to debate. =C2=A0We alread= y=20 decided it would be left to the JS to decide. =C2=A0The only thing left to= =20 debate is the API. =C2=A0

    Or am I wrong?




    ______________________________________________= _
    rtcweb mailing=20 list
    rtcweb@ietf.or= g
    https://www.ietf.org/mailman/listinfo/rtcweb
    <= div style=3D"display:table-cell;white-space:nowrap;vertical-align:middle;wi= dth:100%"> Christer Holmberg
    =20 19 June, 2013=20 2:34 AM
    =
    Hi,
    =C2=A0
    We need to be very clear what we talk about,=20 or some people are always going to be confused :)
    =C2=A0
    So, AFAIK, the discussion is about SDP O/A=20 usage in the API, only in the API, and nowhere but the API.
    =C2=A0
    Whatever people us on the wire is outside the= =20 scope.
    =C2=A0
    Right?
    =C2=A0
    Regards,
    =C2=A0
    Christer
    =C2=A0


    Sent from Windows using TouchDown (www.nitrodesk.com<= /a>)
    -----Original Message-----
    From: Peter Thatcher [    pthatcher@google.com]
    To: Martin Thomson [martin.thomson@gmail.com]
    CC: rtcweb@ietf= .org [rtcweb@ietf.= org]
    Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate t= o be=20 re-opened
    Martin, you're right; that was overly harsh of me. =C2= =A0Adam, I apologize. =C2=A0I'll be civil in the future.



    ______________________________________________= _
    rtcweb mailing=20 list
    rtcweb@ietf.or= g
    https://www.ietf.org/mailman/listinfo/rtcweb
    <= div style=3D"display:table-cell;white-space:nowrap;vertical-align:middle;wi= dth:100%"> Peter Thatcher
    =20 19 June, 2013=20 1:36 AM
    =
    Martin, you're=20 right; that was overly harsh of me. =C2=A0Adam, I apologize. =C2=A0I'll= be civil=20 in the future.



    ______________________________________________= _
    rtcweb mailing=20 list
    rtcweb@ietf.or= g
    https://www.ietf.org/mailman/listinfo/rtcweb
    <= div style=3D"display:table-cell;white-space:nowrap;vertical-align:middle;wi= dth:100%"> Martin Thomson
    =20 18 June, 2013=20 6:25 PM
    I agree with Peter, except for this bit:

    Adam is much harde= r to confuse=20 than you think, or than he professes.

    Speaking of burning it all=20 down and starting over. If you want a
    house-related analogy, that's= =20 not quite correct. It's refusing to
    build an extension because the= =20 old house, while legally fit for
    habitation, is falling down around=20 your ears. Since you only need
    foundations, it's not that big a job= =20 (though I'll grant you that it's
    bigger than many people realize= ,=20 even with that smaller scope).
    _________________= ______________________________
    rtcweb mailing list
    rtcwe= b@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    <= div style=3D"display:table-cell;white-space:nowrap;vertical-align:middle;wi= dth:100%"> Peter Thatcher
    =20 18 June, 2013=20 6:16 PM
    Adam, I think=20 you're confused. =C2=A0As Ted pointed out, there are two different uses= of=20 SDP: 1. =C2=A0as a control surface, 2. as a message format for signalling.= =20 =C2=A0SDPNG was trying to replace SDP for #2. =C2=A0While I believe this th= read=20 was started entirely focused on #1. =C2=A0So you're talking about diffe= rent=20 things.

    So far the only time spent on trying to replace or avoid=20 SDP for #1 has been "comment 22", and to a lesser extent the prop= osal I=20 just made for adding 2 methods to PeerConnection (createLocalStream and=20 createRemoteStream). =C2=A0 I think it's incorrect to conclude that we = should never try to improve #1 just because other in the past failed to=20 replace #2. =C2=A0They're very different.

    I also don't think we should burn down WebRTC and= =20 start over, but despite what some seem to think, we don't have to choos= e between "burn it down" and "never improve it". =C2=A0T= here are many options=20 other than the two extremes.



    By the=20 way, a gentle reminder: SDP is not the only way to do #2. =C2=A0I work on a= =20 rather large system almost entirely build around Jingle, without a hint=20 of SDP, and it works just fine. =C2=A0Much better than SDP would have, I=20 think. =C2=A0Just because SDPNG didn't work out doesn't mean there = will never be any way other to do signalling than SDP.




    ______________________________________________= _
    rtcweb mailing=20 list
    rtcweb@ietf.or= g
    https://www.ietf.org/mailman/listinfo/rtcweb

    --047d7bd6c6ac985ffb04df845419-- --047d7bd6c6ac985ffd04df84541a Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: db95fc0160e2bd8b_0.1.1 /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQECAQEB AQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAARCAAZABkDAREA AhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUKBwAAAAAAAAACAQME BQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAAAAAAAAAAAAADAAEEAv/E ACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oADAMBAAIRAxEAPwDuEt+gW/UL et6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJVIl7eXLCaZIGwBl3TY8epPx2+jy2 ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJ Ew/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx+a69/JSf9alIlste0VzaNpeFrcT9KKymotyi aZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mRUfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRD nu5azS8miKqjOTVkKqS/psG37fo1Fbabeg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GA cpOwBeN+U8/IkGbsiS8b7ryogmbzhbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH 4hPOI0DkjZtaJtFxuVEbIUUiyeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJ nYn9dnAQWl722p4ot37yzqnlfp6FrqbwawG8/9k= --047d7bd6c6ac985ffd04df84541a-- From matthew@matthew.at Wed Jun 19 09:36:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA61121F9B45 for ; Wed, 19 Jun 2013 09:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.033 X-Spam-Level: X-Spam-Status: No, score=-0.033 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yACtIXO0zaK6 for ; Wed, 19 Jun 2013 09:36:23 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A0721F905F for ; Wed, 19 Jun 2013 09:36:23 -0700 (PDT) Received: from [10.10.155.233] (unknown [10.10.155.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 14D9A250041; Wed, 19 Jun 2013 09:36:23 -0700 (PDT) References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-28274A3A-7FA7-4D45-A79B-560E295AE0A4 Content-Transfer-Encoding: 7bit Message-Id: <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> X-Mailer: iPhone Mail (10B146) From: Matthew Kaufman Date: Wed, 19 Jun 2013 09:36:20 -0700 To: Peter Thatcher Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 16:36:27 -0000 --Apple-Mail-28274A3A-7FA7-4D45-A79B-560E295AE0A4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I provided a use case that, unless one wants to write a bunch of SDP-munging= JS state machine cannot be done. The problem is that such use cases are either 1) ignored or 2) dismissed bec= ause of course if one writes said JS, they are possible with the current API= Matthew Kaufman (Sent from my iPhone) On Jun 19, 2013, at 9:28 AM, Peter Thatcher wrote: > I might be wrong, but I tried reading and understanding your whole email, a= nd it seems to come down to "I don't want to use SDP or a different (JSON) f= orm of SDP". That's a fine thing to request, but why don't you just say tha= t? It would save everyone a lot of reading and confusion to be more concise= . =20 >=20 > Or, if you have specific things you'd like to do but can't, what are they?= I think that would help me, and others, understand more easily. Use cases= would be helpful. >=20 > On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond wrote= : >>=20 >> The trouble is not that we can choose to send whatever we want over the w= ire. I know we can. If the WebRTC API is left with SDP as it stands, I'll di= ssect the SDP from the browser, reinterpret and reconstruct on the SDP on th= e remote side. That is NOT the issue. >>=20 >> The summary of what I want/believe: >> 1) I want as close to raw access to RTP/ICE streams, media, sources, outp= uts, codecs as viable. Obviously doing the actual transmission, encoding/dec= oding from JS is not feasible (yet), nor is secure [ICE must occur for mutua= l agreement to exchange data between peers], but having controls for how the= se components are wired together is extremely feasible from JS and would all= ow immensely powerful apps to be produced from JS. >=20 > What would you like to do that you can't do via SDP right now? You said t= his isn't just about working through SDP. But I don't see anything concrete= you can't do right now with sufficient SDP parsing/building/munging/hackery= . >=20 > =20 >> 2) I don't want my primary interface to control media/RTP engines to be v= ia obtaining or providing SDPs to the browser (or any alternative serialized= format); especially given that SDP requires a round trip offer/answer to t= he remote party to affect change (e.g. it's entirely possible to do that sta= teless and one-sided). The SPD interface API is a monolithic do-everything s= erialized format to control an engine but extremely badly/poorly/short sight= ed (regardless if it is SDP or whatever instead), and it's wholly unneeded. >=20 > Short summary: "I don't want to use SDP". Right? >=20 >> 3) I don't want a replacement for SDP with another more "pretty" format l= ike JSON. >=20 > Short summary: "I don't want to use SDP or a different syntax for SDP". R= ight? >=20 >> 4) I want no specified requirement from the browser to have any particula= r form of media negotiation API requirement what-so-ever (regardless if I ca= n opt to substitute with my own format on the wire or not) >=20 > Short summary: "I don't want to use SDP or a different syntax for SDP". R= ight? > =20 >> 5) Using SDP with offer/answer build into the browser binary is a horribl= y BAD technical choice (even for SIP folks) and must be stopped, see: http:/= /www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html >=20 > Short summary: "I don't want to use SDP". Right? > =20 >>=20 >>=20 >> I too want to understand the rational for keeping something as bad as SDP= with offer/answer as the primary mechanism for controlling the media compon= ents and interaction to those component and more importantly, I'd too would l= ike to open debate to agreeing or not to provide a lower layer API rather th= an a media negotiation API as a complete substitute alternative to SDP with o= ffer/answer. >>=20 >> If we can agree that it's far superior to have a lower level media/RTC co= mponent API rather than a media negotiation API, then we can propose what th= at API could look like (and there are people who have already have starting= proposals). I'd throw my hat in the ring to propose such and API if necessa= ry as I've written such engines from scratch before. But I don't want to was= te time proposing ore reviewing such an API which will be summarily dismisse= d because people are so stuck on requiring a media negotiation API built int= o the browser binary, and specifically SDP with offer/answer in this case. >=20 >=20 > The WG may dislike and reject your proposal, but there's a bit of truth to= the old mathematically incorrect sports adage "you miss 100% of the shots y= ou don't take". >=20 >=20 >> Anyone who argues that they need/want that simple SDP media negotiation A= PI must understand that a lower level API would allow a wrapper API to produ= ce the same WebRTC API the have today but be built entirely from JavaScript >=20 > That depends on how low-level you go. If you go too low-level, it becomes= infeasible to do things correctly and performantly in JavaScript. > =20 >> upon a lower level API. Thus they can have their "just add-milk" baking A= PI. But those of us who need control of the raw ingredients beyond the "just= add milk" can still innovate. >>=20 >> -Robin >>=20 >>=20 >>> Peter Thatcher 19 June, 2013 2:49 A= M >>> Correct my if I'm wrong, but the API already leaves what goes over the w= ire completely up to the JS app. So we couldn't re-open a debate of "SDP or= not SDP" for the wire format, because there's nothing to debate. We alread= y decided it would be left to the JS to decide. The only thing left to deb= ate is the API. =20 >>>=20 >>> Or am I wrong? >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> Christer Holmberg 19 June, 20= 13 2:34 AM >>> Hi, >>> =20 >>> We need to be very clear what we talk about, or some people are always g= oing to be confused :) >>> =20 >>> So, AFAIK, the discussion is about SDP O/A usage in the API, only in the= API, and nowhere but the API. >>> =20 >>> Whatever people us on the wire is outside the scope. >>> =20 >>> Right? >>> =20 >>> Regards, >>> =20 >>> Christer >>> =20 >>>=20 >>>=20 >>> Sent from Windows using TouchDown (www.nitrodesk.com) >>>=20 >>> -----Original Message----- >>> From: Peter Thatcher [pthatcher@google.com] >>> To: Martin Thomson [martin.thomson@gmail.com] >>> CC: rtcweb@ietf.org [rtcweb@ietf.org] >>> Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened= >>> Martin, you're right; that was overly harsh of me. Adam, I apologize. I= 'll be civil in the future. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> Peter Thatcher 19 June, 2013 1:36 A= M >>> Martin, you're right; that was overly harsh of me. Adam, I apologize. I= 'll be civil in the future. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> Martin Thomson 18 June, 2013 6:25 P= M >>> I agree with Peter, except for this bit: >>>=20 >>> Adam is much harder to confuse than you think, or than he professes. >>>=20 >>> Speaking of burning it all down and starting over. If you want a >>> house-related analogy, that's not quite correct. It's refusing to >>> build an extension because the old house, while legally fit for >>> habitation, is falling down around your ears. Since you only need >>> foundations, it's not that big a job (though I'll grant you that it's >>> bigger than many people realize, even with that smaller scope). >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> Peter Thatcher 18 June, 2013 6:16 P= M >>> Adam, I think you're confused. As Ted pointed out, there are two differ= ent uses of SDP: 1. as a control surface, 2. as a message format for signal= ling. SDPNG was trying to replace SDP for #2. While I believe this thread w= as started entirely focused on #1. So you're talking about different things= . >>>=20 >>> So far the only time spent on trying to replace or avoid SDP for #1 has b= een "comment 22", and to a lesser extent the proposal I just made for adding= 2 methods to PeerConnection (createLocalStream and createRemoteStream). I= think it's incorrect to conclude that we should never try to improve #1 jus= t because other in the past failed to replace #2. They're very different. >>>=20 >>> I also don't think we should burn down WebRTC and start over, but despit= e what some seem to think, we don't have to choose between "burn it down" an= d "never improve it". There are many options other than the two extremes. >>>=20 >>>=20 >>>=20 >>> By the way, a gentle reminder: SDP is not the only way to do #2. I work= on a rather large system almost entirely build around Jingle, without a hin= t of SDP, and it works just fine. Much better than SDP would have, I think.= Just because SDPNG didn't work out doesn't mean there will never be any wa= y other to do signalling than SDP. >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-28274A3A-7FA7-4D45-A79B-560E295AE0A4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
    I provided a use case that, unless one wants to write a bunch of SDP-munging JS state machine cannot be done.

    The problem is that such use cases are either 1) ignored or 2) dismissed because of course if one writes said JS, they are possible with the current API

    Matthew Kaufman

    (Sent from my iPhone)

    On Jun 19, 2013, at 9:28 AM, Peter Thatcher <pthatcher@google.com> wrote:

    I might be wrong, but I tried reading and understanding your whole email, and it seems to come down to "I don't want to use SDP or a different (JSON) form of SDP".  That's a fine thing to request, but why don't you just say that?  It would save everyone a lot of reading and confusion to be more concise.  

    Or, if you have specific things you'd like to do but can't, what are they?  I think that would help me, and others, understand more easily.  Use cases would be helpful.

    On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond <robin@hookflash.com> wrote:

    The trouble is not that we can choose to send whatever we want over the wire. I know we can. If the WebRTC API is left with SDP as it stands, I'll dissect the SDP from the browser, reinterpret and reconstruct on the SDP on the remote side. That is NOT the issue.

    The summary of what I want/believe:
    1) I want as close to raw access to RTP/ICE streams, media, sources, outputs, codecs as viable. Obviously doing the actual transmission, encoding/decoding from JS is not feasible (yet), nor is secure [ICE must occur for mutual agreement to exchange data between peers], but having controls for how these components are wired together is extremely feasible from JS and would allow immensely powerful apps to be produced from JS.

    What would you like to do that you can't do via SDP right now?  You said this isn't just about working through SDP.  But I don't see anything concrete you can't do right now with sufficient SDP parsing/building/munging/hackery.

     
    2) I don't want my primary interface to control media/RTP engines to be via obtaining or providing SDPs to the browser (or any alternative serialized format); especially given that SDP requires a round trip offer/answer to the remote party to affect change (e.g. it's entirely possible to do that stateless and one-sided). The SPD interface API is a monolithic do-everything serialized format to control an engine but extremely badly/poorly/short sighted (regardless if it is SDP or whatever instead), and it's wholly unneeded.

    Short summary: "I don't want to use SDP".  Right?

    3) I don't want a replacement for SDP with another more "pretty" format like JSON.

    Short summary: "I don't want to use SDP or a different syntax for SDP".  Right?

    4) I want no specified requirement from the browser to have any particular form of media negotiation API requirement what-so-ever (regardless if I can opt to substitute with my own format on the wire or not)

    Short summary: "I don't want to use SDP or a different syntax for SDP".  Right?
     
    5) Using SDP with offer/answer build into the browser binary is a horribly BAD technical choice (even for SIP folks) and must be stopped, see: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html

    Short summary: "I don't want to use SDP".  Right?
     


    I too want to understand the rational for keeping something as bad as SDP with offer/answer as the primary mechanism for controlling the media components and interaction to those component and more importantly, I'd too would like to open debate to agreeing or not to provide a lower layer API rather than a media negotiation API as a complete substitute alternative to SDP with offer/answer.

    If we can agree that it's far superior to have a lower level media/RTC component API rather than a media negotiation API, then we can propose what that API could look like (and there are people who have already have starting proposals). I'd throw my hat in the ring to propose such and API if necessary as I've written such engines from scratch before. But I don't want to waste time proposing ore reviewing such an API which will be summarily dismissed because people are so stuck on requiring a media negotiation API built into the browser binary, and specifically SDP with offer/answer in this case.


    The WG may dislike and reject your proposal, but there's a bit of truth to the old mathematically incorrect sports adage "you miss 100% of the shots you don't take".


    Anyone who argues that they need/want that simple SDP media negotiation API must understand that a lower level API would allow a wrapper API to produce the same WebRTC API the have today but be built entirely from JavaScript

    That depends on how low-level you go.  If you go too low-level, it becomes infeasible to do things correctly and performantly in JavaScript.
     
    upon a lower level API. Thus they can have their "just add-milk" baking API. But those of us who need control of the raw ingredients beyond the "just add milk" can still innovate.

    -Robin


    <compose-unknown-contact.jpg>
    19 June, 2013 2:49 AM
    Correct my if I'm wrong, but the API already leaves what goes over the wire completely up to the JS app.  So we couldn't re-open a debate of "SDP or not SDP" for the wire format, because there's nothing to debate.  We already decided it would be left to the JS to decide.  The only thing left to debate is the API.  

    Or am I wrong?




    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    <compose-unknown-contact.jpg>
    19 June, 2013 2:34 AM
    Hi,
     
    We need to be very clear what we talk about, or some people are always going to be confused :)
     
    So, AFAIK, the discussion is about SDP O/A usage in the API, only in the API, and nowhere but the API.
     
    Whatever people us on the wire is outside the scope.
     
    Right?
     
    Regards,
     
    Christer
     


    Sent from Windows using TouchDown (www.nitrodesk.com)
    -----Original Message-----
    From: Peter Thatcher [pthatcher@google.com]
    To: Martin Thomson [martin.thomson@gmail.com]
    CC: rtcweb@ietf.org [rtcweb@ietf.org]
    Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
    Martin, you're right; that was overly harsh of me.  Adam, I apologize.  I'll be civil in the future.



    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    <compose-unknown-contact.jpg>
    19 June, 2013 1:36 AM
    Martin, you're right; that was overly harsh of me.  Adam, I apologize.  I'll be civil in the future.



    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    <compose-unknown-contact.jpg>
    18 June, 2013 6:25 PM
    I agree with Peter, except for this bit:

    Adam is much harder to confuse than you think, or than he professes.

    Speaking of burning it all down and starting over. If you want a
    house-related analogy, that's not quite correct. It's refusing to
    build an extension because the old house, while legally fit for
    habitation, is falling down around your ears. Since you only need
    foundations, it's not that big a job (though I'll grant you that it's
    bigger than many people realize, even with that smaller scope).
    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    <compose-unknown-contact.jpg>
    18 June, 2013 6:16 PM
    Adam, I think you're confused.  As Ted pointed out, there are two different uses of SDP: 1.  as a control surface, 2. as a message format for signalling.  SDPNG was trying to replace SDP for #2.  While I believe this thread was started entirely focused on #1.  So you're talking about different things.

    So far the only time spent on trying to replace or avoid SDP for #1 has been "comment 22", and to a lesser extent the proposal I just made for adding 2 methods to PeerConnection (createLocalStream and createRemoteStream).   I think it's incorrect to conclude that we should never try to improve #1 just because other in the past failed to replace #2.  They're very different.

    I also don't think we should burn down WebRTC and start over, but despite what some seem to think, we don't have to choose between "burn it down" and "never improve it".  There are many options other than the two extremes.



    By the way, a gentle reminder: SDP is not the only way to do #2.  I work on a rather large system almost entirely build around Jingle, without a hint of SDP, and it works just fine.  Much better than SDP would have, I think.  Just because SDPNG didn't work out doesn't mean there will never be any way other to do signalling than SDP.




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

    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    --Apple-Mail-28274A3A-7FA7-4D45-A79B-560E295AE0A4-- From pthatcher@google.com Wed Jun 19 09:41:43 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B16421F9CAC for ; Wed, 19 Jun 2013 09:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILyQAjDcoWak for ; Wed, 19 Jun 2013 09:41:38 -0700 (PDT) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0888D21F9C8F for ; Wed, 19 Jun 2013 09:41:37 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id t12so5224099pdi.7 for ; Wed, 19 Jun 2013 09:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=en0KuSmihrtIC1EssnlryKUgjy8dstN+BSQAATTDmiQ=; b=KdECPIbr94ZUxR+o4IeOQdBPojoUcslM8isSrQURAxYJTmrPtFyK4+QbGPnbGvZc+h leGS538xOg4Nue+ce1BqBjvh1Ek+mfh9gYZkhlVQBAxWzsTZcJQ3SQWTdlVQbTYDrsHh 6vSbihGLMBhQsxFpFnkdkGX2qsGHeS7BXmFxVOLVOf67FRNB08OZUTZi/IIpeSbpAFtQ CPJQN0o3GUQ1E76e46MgUY+lDW7DQ0iYzSAvyiry9N6dTwqjlS6lDvOfkv5rBKk049CD cJEPJizVE8YrX/pA67wOlNnmeKh55oKkkv9pSDJreM0NnlKB5XlqzRQnwjbzaR5q/bCe pN7w== 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=en0KuSmihrtIC1EssnlryKUgjy8dstN+BSQAATTDmiQ=; b=Ni75X54lrEtboSZ9wg/sW8Kxpr2g5/pyPHsZSVerw32dRB6toAIocSA1Lwc5iM2G+3 kX4HI6KGZolWmNufJcJ0hy5qFQSZE6hp1PPenfBBjJ6XelEhDkjJ5KgKrBaok0ZfxjGq zvIlGyzntVD8olsfyF2RawoXbDmk2sHq16+FY5jOO9S6O/qYq12ZIuUmoGfBxiKxioLq W3hZQpgCLu+b74bgjBQ5eWkqd+M08QZLrAIEipVCrUYvzLJPSnRw170DVc7SYBNGbfx3 lt6pkv5d0LuS0ro9w7ObPKe92LDEPepb7vAFtgH1CQw9yO8+0gaDDMgcxbLHz7mbMxeH iB3Q== X-Received: by 10.66.250.164 with SMTP id zd4mr7579324pac.141.1371660097731; Wed, 19 Jun 2013 09:41:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 09:40:57 -0700 (PDT) In-Reply-To: References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Wed, 19 Jun 2013 09:40:57 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b15fea3e0d45804df848058 X-Gm-Message-State: ALoCoQkYDkc/g5o81iPkwDftenGjhcv6J3F8oPqAt74/oCleAIKnULsh4I2m1FhB6lFjZVRPicLQ2m7oZMrGCWAiGE0W/HcKGFImsSo5ta4s3perXuFXn+fdb4n8v4fIcoynhzLJOMpwb120vmgHXPvUdjTuB1mOrjpMgbgMLx6y2v8rfEZddxUPYTlMdQN8uBDKjCemp49k Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 16:41:43 -0000 --047d7b15fea3e0d45804df848058 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 19, 2013 at 9:10 AM, I=C3=B1aki Baz Castillo wr= ote: > Hi Peter, for now just some comments (I agree that more use cases and > other considerations must be provided): > > > > > >> I don't think that the discussion is just about "SDP O/A usage in the > >> API". We don't want a replacement for SDP, nor a new representation of > >> SDP, nor to deal with blob strings between the JS layer and the WebRTC > >> layer. > > > > > > Please at least agree with Christer that this is about the API, not abo= ut > > the signalling wire format. The API already allows whatever signalling > wire > > format you want, > > > IMHO that is not entirely true. > > First of all, whichever the signaling protocol is, it must accomplish > with SDP O/A semantics (since it must carry a SDP and receive a SDP to > establish the communication). > API calls must use the SDP O/A, but what goes on the wire doesn't have to be. With enough SDP hackery, you can do whatever you want over the wire, including not use O/A semantics. > > Second: Indeed the current spec does not mandate what should be sent > in the wire. In practice that means we can use SIP over WebSocket, > XMPP/Jingle over HTTP, or whatever. But in practice it also means that > we must send a SDP in the wire. The SDP blob string can be > hex-encoded/escaped/mangled/whatever by the JS app, but the SDP blob > string generated by PeerConnection-A should arrive to > PeerConnection-B. A sufficiently smart chunk of JS could call setLocalDescription/setRemoteDescription with SDP that it completely created itself, and send whatever it wants over the wire. > And since such a SDP is generated by the WebRTC > stack and passed to the JS as an unmanageable blob string, the JS app > cannot properly deal with it. > The JS parse the SDP from createOffer/createAnswer, get the info it needs, make decisions and then serialize different SDP back down in setLocalDescription/setRemoteDescription. It's terribly ugly, but it works= . > So, currently WebRTC does not mandate the signaling protocol > in-the-wire, but it does mandate the media signaling protocol > in-the-wire (you need to pass a working SDP to the remote, sure), > something that constrains the signaling protocol itself. > It does not mandate SDP over the wire. It's possible to write a JS app that gets everything working with no SDP on the wire. It's anything but pretty, but it works. > and everything you mention from here on out is just the > API. So please just say to Christer "yes, this is all about the API". I= t > will make the rest of the discussion much more clear. > Ok, this is all about the API :) >> In short we want something like a JS wrapper of the native >> WebRTC API, > > > I work on the WebRTC implementation in Chrome, and I don't know what you > mean by "native WebRTC API". Such a thing does not really exist. The > implementation has three different layers of abstraction, each of which you > might be referring to, but none of them which will give you what you want= . > The highest level uses SDP. The lowest level gives you media bits, but n= o > ICE, SRTP, DTLS, or SCTP. The middle layer gives you all those things > without SDP, but it still uses an abstract offer/answer for transport and > RTP setup (and even has a Jingle implementation on top of that). None of > those give you what you want. The "native WebRTC API" that you want to wrap > doesn't exist. > Ok, IMHO nobody is still requesting a specific JS API but just > describing the features and capabilities such an API must provide. The > "similar to native WebRTC API" is just a comment to help understanding > what we mean, but of course each browser is free to implement its > native API(s) as it prefers so the "JS wrapper" concept does not make > sense. But you can't say "similar to native WebRTC API" because no such thing exists. You can't be similar to something that doesn't exist :). >> to directly manage media/transport parameters and media >> streams without having to pass a monolithic and unmanageable SDP blob >> between the JS and the WebRTC layer. > > > That boils down to "the same power of the current API, without going through > SDP". I think that's a clear requirement. So why don't you just say that? > Would save everyone a lot of reading and misunderstanding. > You are right. >> calls to get the required media parameters, the JS can send them to >> the remote peer in the way it prefers (which may be via a SDP created >> by the JS app, or via an AJAX request for sending codecs/media-types >> info followed by a WebSocket connection for sending ICE candidates one >> by one, or serialized in JSON via a previously open DataChannel >> session... or whatever mechanism available in the Web and browsers). >> > > You already have that. > Can I first send my codecs list, then (once the peer notifies me > codecs compatibility) send the codecs preference order, then my ICE > candidates and later (not just when ICE process terminates) signal the > peer a "OK" message so we both start the multimedia audio/video/data > communication, all of this with the current API? I think so, yes. > (I mean without parsing the SDP blob and splitting it into blob fragments). Maybe... I don't know for sure. But generally, anything beyond the most basic uses of the API requires at least some SDP hackery, and advanced uses require a lot. Best regards. -- I=C3=B1aki Baz Castillo --047d7b15fea3e0d45804df848058 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Wed, Jun 19, 2013 at 9:10 AM, I=C3=B1aki Baz Castillo <ibc@aliax.n= et> wrote:
    Hi Peter, for now just some comments (I agree that more us= e cases and
    other considerations must be provided):




    >> I don't think that the discussion is just about "SDP O/A = usage in the
    >> API". We don't want a replacement for SDP, nor a new repr= esentation of
    >> SDP, nor to deal with blob strings between the JS layer and the We= bRTC
    >> layer.
    >
    >
    > Please at least agree with Christer that this is about the API, not ab= out
    > the signalling wire format. =C2=A0The API already allows whatever sign= alling wire
    > format you want,


    IMHO that is not entirely true.

    First of all, whichever the signaling protocol is, it must accomplish
    with SDP O/A semantics (since it must carry a SDP and receive a SDP to
    establish the communication).

    API calls= must use the SDP O/A, but what goes on the wire doesn't have to be. = =C2=A0With enough SDP hackery, you can do whatever you want over the wire, = including not use O/A semantics.
    =C2=A0

    Second: Indeed the current spec does not mandate what should be sent
    in the wire. In practice that means we can use SIP over WebSocket,
    XMPP/Jingle over HTTP, or whatever. But in practice it also means that
    we must send a SDP in the wire. The SDP blob string can be
    hex-encoded/escaped/mangled/whatever by the JS app, but the SDP blob
    string generated by PeerConnection-A should arrive to
    PeerConnection-B.

    A sufficiently smart chu= nk of JS could call setLocalDescription/setRemoteDescription with SDP that = it completely created itself, and send whatever it wants over the wire. =C2= =A0
    =C2=A0
    And since such a SDP is generated by the = WebRTC
    stack and passed to the JS as an unmanageable blob string, the JS app
    cannot properly deal with it.

    The JS pa= rse the SDP from createOffer/createAnswer, get the info it needs, make deci= sions and then serialize different SDP back down in setLocalDescription/set= RemoteDescription. =C2=A0It's terribly ugly, but it works.
    =C2=A0
    So, currently WebRTC does not mandate the signaling protocol
    in-the-wire, but it does mandate the media signaling protocol
    in-the-wire (you need to pass a working SDP to the remote, sure),
    something that constrains the signaling protocol itself.

    It does not mandate SDP over the wire. =C2=A0It's pos= sible to write a JS app that gets everything working with no SDP on the wir= e. =C2=A0It's anything but pretty, but it works.




    > and everything you mention from here on out is just the
    > API. =C2=A0So please just say to Christer "yes, this is all about= the API". =C2=A0It
    > will make the rest of the discussion much more clear.

    > Ok, this is all about the API :)

    >> In short we want something like a JS wrapper of the native
    >> WebRTC API,
    >
    >
    > I work on the WebRTC implementation in Chrome, and I don't know wh= at you
    > mean by "native WebRTC API". =C2=A0Such a thing does not rea= lly exist. =C2=A0The
    > implementation has three different layers of abstraction, each of whic= h you
    > might be referring to, but none of them which will give you what you w= ant.
    > The highest level uses SDP. =C2=A0The lowest level gives you media bit= s, but no
    > ICE, SRTP, DTLS, or SCTP. =C2=A0The middle layer gives you all those t= hings
    > without SDP, but it still uses an abstract offer/answer for transport = and
    > RTP setup (and even has a Jingle implementation on top of that). =C2= =A0None of
    > those give you what you want. =C2=A0The "native WebRTC API" = that you want to wrap
    > doesn't exist.

    > Ok, IMHO nobody is still requesting a specific JS API but just> describing the features and capabilities such an API must provide. T= he
    > "similar to native WebRTC API" is just a comment to he= lp understanding
    > what we mean, but of course each browser is free to implement its
    &= gt; native API(s) as it prefers so the "JS wrapper" concept does = not make
    > sense.

    But you can't say "<= span style=3D"color:rgb(34,34,34)">similar to native WebRTC API"= ; because no such thing exists. =C2=A0You can't be similar to something= that doesn't exist :).


    >> to directly manage media/transport parameters and media
    >> streams without having to pass a monolithic and unmanageable SDP b= lob
    >> between the JS and the WebRTC layer.
    >
    >
    > That boils down to "the same power of the current API, without go= ing through
    > SDP". =C2=A0I think that's a clear requirement. =C2=A0So why = don't you just say that?
    > Would save everyone a lot of reading and misunderstanding.

    > You are right.



    >> calls to get the required media parameters, the JS can send them t= o
    >> the remote peer in the way it prefers (which may be via a SDP crea= ted
    >> by the JS app, or via an AJAX request for sending codecs/media-typ= es
    >> info followed by a WebSocket connection for sending ICE candidates= one
    >> by one, or serialized in JSON via a previously open DataChannel >> session... or whatever mechanism available in the Web and browsers= ).
    >>
    >
    > You already have that.

    > Can I first send my codecs list, then (once the peer notifies me=
    > codecs compatibility) send the codecs preference order, then my IC= E
    > candidates and later (not just when ICE process terminates) signa= l the
    > peer a "OK" message so we both start the multimedia audio/vi= deo/data
    > communication, all of this with the current API?

    I think so, yes.

    > (I mean without parsing the SDP blob and s= plitting it into blob fragments).

    Maybe... I do= n't know for sure. =C2=A0But generally, anything beyond the most basic = uses of the API requires at least some SDP hackery, and advanced uses requi= re a lot.


    Best regards.




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

    --047d7b15fea3e0d45804df848058-- From pthatcher@google.com Wed Jun 19 09:50:37 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE00621F9D47 for ; Wed, 19 Jun 2013 09:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03paLDrhiJmo for ; Wed, 19 Jun 2013 09:50:31 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 887C121F9D69 for ; Wed, 19 Jun 2013 09:50:31 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id 14so5222108pdj.40 for ; Wed, 19 Jun 2013 09:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Cfjurd0gpNwbHm8DbzItF2FlJWtzCkrk5ArFdl+0zEw=; b=pFdqg7dH1BWIfNygzovIcI4p6dK8qvMg0v583R94BkLzLLDorq76uOUPdn455+9vVC n0gVOQ5wmB1B0l7nD3sgUxPAvSrTV5h/VUgGve6nYJiMic6uBoQFyyETVYl1AY1ptjln iP9oilQw51aknAGNpaU3mwbjtLctbeeWgWO6thIlnPxzyaraO1j41o7PylX7UydgEDJl rN1usVR3kpy33pIbnBI+OicYcyVl1ztcpFopPt9fP6m5FGEfbOjv2TdZOo1OKFrEeLJ9 MVf/+pzFpLif2M2GpOna4ZDnOLROjedqWf2+N+h6PCckeAQhGL4vP26aH1Ll4JW0F1b9 QkjA== 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=Cfjurd0gpNwbHm8DbzItF2FlJWtzCkrk5ArFdl+0zEw=; b=Tb/v8FiNNyTidKB6M1nGQBk1dThrpL1hvxP2Iw5XQQBURptFRv590n/mBO8YZomseY BHX7N/SBBi8NjckzBr9WiJ5kqGeloEreNlc4Bog2JIURm9lqQYOfCCyd0Z/0osrwQl7H fRpc7GWj1yu4FzMsITEtei3B2DtuJELOg+Rxb9coIoIVs6JGnypN92tzfpI1cXeG8qai J4SHNSaySFixExSeY57/nR8WMk8PyRzJMjRxIvp0Q6JbY4uiWYEEWcVvjZEKtoSlz4EU NjSkZeD028YzQoR2nM89pbHFfeZBlcY5toEYi8k/LlFDGA0vMeKMcdHM9bB9DqWrx348 UQqg== X-Received: by 10.68.69.108 with SMTP id d12mr3612823pbu.187.1371660628367; Wed, 19 Jun 2013 09:50:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 09:49:48 -0700 (PDT) In-Reply-To: <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> References: <51C0C1A0.9010107@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <51C1B907.8060508@hookflash.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> From: Peter Thatcher Date: Wed, 19 Jun 2013 09:49:48 -0700 Message-ID: To: Matthew Kaufman Content-Type: multipart/alternative; boundary=0015174989ee81d1ce04df84a0b3 X-Gm-Message-State: ALoCoQl1UOwrbZ/d398LGS7gK9fkNiFWn+3Hb/ZNtdGtry5kXAQPF+I94xOqcRtLqZ1cQKtMaVJ3fWoh9RxznxInpabcQGnXyN21E3hW+76aUz4xY1Z3rZg99I114n1+YozUTLF0mMMUQaLWEwMl+sTQ/i+34YOa7RY5l/8qhwLjEVn7C1Dg4aFYyXx0mw70VTITO54HouSs Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jun 2013 16:50:37 -0000 --0015174989ee81d1ce04df84a0b3 Content-Type: text/plain; charset=UTF-8 I asked "is there something that can't be done without sufficient SDP munging"? You answered "I have something that can be done with sufficient SDP munging". OK. But do you have something that *can't* be done with SDP munging? If there's nothing that can't be done with SDP munging, then this whole thread boils down to "give us an API that has the same amount of control as the current one, but without requiring SDP munging to do advanced things". And if that's is what is desired, then at least it can be clear and concise. On Wed, Jun 19, 2013 at 9:36 AM, Matthew Kaufman wrote: > I provided a use case that, unless one wants to write a bunch of > SDP-munging JS state machine cannot be done. > > The problem is that such use cases are either 1) ignored or 2) dismissed > because of course if one writes said JS, they are possible with the current > API > > Matthew Kaufman > > (Sent from my iPhone) > > On Jun 19, 2013, at 9:28 AM, Peter Thatcher wrote: > > I might be wrong, but I tried reading and understanding your whole email, > and it seems to come down to "I don't want to use SDP or a different (JSON) > form of SDP". That's a fine thing to request, but why don't you just say > that? It would save everyone a lot of reading and confusion to be more > concise. > > Or, if you have specific things you'd like to do but can't, what are they? > I think that would help me, and others, understand more easily. Use cases > would be helpful. > > On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond wrote: > >> >> The trouble is not that we can choose to send whatever we want over the >> wire. I know we can. If the WebRTC API is left with SDP as it stands, I'll >> dissect the SDP from the browser, reinterpret and reconstruct on the SDP on >> the remote side. That is NOT the issue. >> >> The summary of what I want/believe: >> 1) I want as close to raw access to RTP/ICE streams, media, sources, >> outputs, codecs as viable. Obviously doing the actual transmission, >> encoding/decoding from JS is not feasible (yet), nor is secure [ICE must >> occur for mutual agreement to exchange data between peers], but having >> controls for how these components are wired together is extremely feasible >> from JS and would allow immensely powerful apps to be produced from JS. >> > > What would you like to do that you can't do via SDP right now? You said > this isn't just about working through SDP. But I don't see anything > concrete you can't do right now with sufficient SDP > parsing/building/munging/hackery. > > > >> 2) I don't want my primary interface to control media/RTP engines to be >> via obtaining or providing SDPs to the browser (or any alternative >> serialized format); especially given that SDP requires a round trip >> offer/answer to the remote party to affect change (e.g. it's entirely >> possible to do that stateless and one-sided). The SPD interface API is a >> monolithic do-everything serialized format to control an engine but >> extremely badly/poorly/short sighted (regardless if it is SDP or whatever >> instead), and it's wholly unneeded. >> > > Short summary: "I don't want to use SDP". Right? > > 3) I don't want a replacement for SDP with another more "pretty" format >> like JSON. >> > > Short summary: "I don't want to use SDP or a different syntax for SDP". > Right? > > 4) I want no specified requirement from the browser to have any >> particular form of media negotiation API requirement what-so-ever >> (regardless if I can opt to substitute with my own format on the wire or >> not) >> > > Short summary: "I don't want to use SDP or a different syntax for SDP". > Right? > > >> 5) Using SDP with offer/answer build into the browser binary is a >> horribly BAD technical choice (even for SIP folks) and must be stopped, >> see: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html >> > > Short summary: "I don't want to use SDP". Right? > > >> >> >> I too want to understand the rational for keeping something as bad as SDP >> with offer/answer as the primary mechanism for controlling the media >> components and interaction to those component and more importantly, I'd too >> would like to open debate to agreeing or not to provide a lower layer API >> rather than a media negotiation API as a complete substitute alternative to >> SDP with offer/answer. >> >> If we can agree that it's far superior to have a lower level media/RTC >> component API rather than a media negotiation API, then we can propose what >> that API could look like (and there are people who have already have >> starting proposals). I'd throw my hat in the ring to propose such and API >> if necessary as I've written such engines from scratch before. But I don't >> want to waste time proposing ore reviewing such an API which will be >> summarily dismissed because people are so stuck on requiring a media >> negotiation API built into the browser binary, and specifically SDP with >> offer/answer in this case. >> > > > The WG may dislike and reject your proposal, but there's a bit of truth to > the old mathematically incorrect sports adage "you miss 100% of the shots > you don't take". > > > Anyone who argues that they need/want that simple SDP media negotiation >> API must understand that a lower level API would allow a wrapper API to >> produce the same WebRTC API the have today but be built entirely from >> JavaScript >> > > That depends on how low-level you go. If you go too low-level, it becomes > infeasible to do things correctly and performantly in JavaScript. > > >> upon a lower level API. Thus they can have their "just add-milk" baking >> API. But those of us who need control of the raw ingredients beyond the >> "just add milk" can still innovate. >> >> -Robin >> >> >> >> Peter Thatcher >> 19 June, 2013 2:49 AM >> Correct my if I'm wrong, but the API already leaves what goes over the >> wire completely up to the JS app. So we couldn't re-open a debate of "SDP >> or not SDP" for the wire format, because there's nothing to debate. We >> already decided it would be left to the JS to decide. The only thing left >> to debate is the API. >> >> Or am I wrong? >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> Christer Holmberg >> 19 June, 2013 2:34 AM >> Hi, >> >> We need to be very clear what we talk about, or some people are always >> going to be confused :) >> >> So, AFAIK, the discussion is about SDP O/A usage in the API, only in the >> API, and nowhere but the API. >> >> Whatever people us on the wire is outside the scope. >> >> Right? >> >> Regards, >> >> Christer >> >> >> >> Sent from *Windows* using *TouchDown* (www.nitrodesk.com) >> >> -----Original Message----- >> *From:* Peter Thatcher [pthatcher@google.com] >> *To:* Martin Thomson [martin.thomson@gmail.com] >> *CC:* rtcweb@ietf.org [rtcweb@ietf.org] >> *Subject:* Re: [rtcweb] Requesting "SDP or not SDP" debate to be >> re-opened >> Martin, you're right; that was overly harsh of me. Adam, I apologize. >> I'll be civil in the future. >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> Peter Thatcher >> 19 June, 2013 1:36 AM >> Martin, you're right; that was overly harsh of me. Adam, I apologize. >> I'll be civil in the future. >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> Martin Thomson >> 18 June, 2013 6:25 PM >> I agree with Peter, except for this bit: >> >> Adam is much harder to confuse than you think, or than he professes. >> >> Speaking of burning it all down and starting over. If you want a >> house-related analogy, that's not quite correct. It's refusing to >> build an extension because the old house, while legally fit for >> habitation, is falling down around your ears. Since you only need >> foundations, it's not that big a job (though I'll grant you that it's >> bigger than many people realize, even with that smaller scope). >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> Peter Thatcher >> 18 June, 2013 6:16 PM >> Adam, I think you're confused. As Ted pointed out, there are two >> different uses of SDP: 1. as a control surface, 2. as a message format for >> signalling. SDPNG was trying to replace SDP for #2. While I believe this >> thread was started entirely focused on #1. So you're talking about >> different things. >> >> So far the only time spent on trying to replace or avoid SDP for #1 has >> been "comment 22", and to a lesser extent the proposal I just made for >> adding 2 methods to PeerConnection (createLocalStream and >> createRemoteStream). I think it's incorrect to conclude that we should >> never try to improve #1 just because other in the past failed to replace >> #2. They're very different. >> >> I also don't think we should burn down WebRTC and start over, but despite >> what some seem to think, we don't have to choose between "burn it down" and >> "never improve it". There are many options other than the two extremes. >> >> >> >> By the way, a gentle reminder: SDP is not the only way to do #2. I work >> on a rather large system almost entirely build around Jingle, without a >> hint of SDP, and it works just fine. Much better than SDP would have, I >> think. Just because SDPNG didn't work out doesn't mean there will never be >> any way other to do signalling than SDP. >> >> >> >> >> _______________________________________________ >> 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 > > --0015174989ee81d1ce04df84a0b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I asked "is there something that can't be done wi= thout sufficient SDP munging"? =C2=A0You answered "I have somethi= ng that can be done with sufficient SDP munging". =C2=A0 OK. =C2=A0But= do you have something that *can't* be done with SDP munging?

    If there's nothing that can't be done with SDP mungi= ng, then this whole thread boils down to "give us an API that has the = same amount of control as the current one, but without requiring SDP mungin= g to do advanced things". =C2=A0And if that's is what is desired, = then at least it can be clear and concise.




    On Wed, Jun 19, 2013 at 9:36 AM, Matthew Kaufman <ma= tthew@matthew.at> wrote:
    I provided a use case= that, unless one wants to write a bunch of SDP-munging JS state machine ca= nnot be done.

    The problem is that such use cases are either 1) ignore= d or 2) dismissed because of course if one writes said JS, they are possibl= e with the current API

    Matthew Kaufman

    (Sent from my iPhone)=

    On Jun 19, 2013, at 9:28 AM, Peter Thatcher <pthatcher@google.com= > wrote:

    I might be wrong, but I tried reading and understanding your whole ema= il, and it seems to come down to "I don't want to use SDP or a dif= ferent (JSON) form of SDP". =C2=A0That's a fine thing to request, = but why don't you just say that? =C2=A0It would save everyone a lot of = reading and confusion to be more concise. =C2=A0

    Or, if you have specific things you'd like to= do but can't, what are they? =C2=A0I think that would help me, and oth= ers, understand more easily. =C2=A0Use cases would be helpful.

    On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond <robin@hookflash.com&= gt; wrote:

    The trouble is not that we can choose to send whatever we want over the=20 wire. I know we can. If the WebRTC API is left with SDP as it stands,=20 I'll dissect the SDP from the browser, reinterpret and reconstruct on= =20 the SDP on the remote side. That is NOT the issue.

    The summary of what I want/believe:
    1) I want as close to raw access to RTP/ICE streams, media, sources,=20 outputs, codecs as viable. Obviously doing the actual transmission,=20 encoding/decoding from JS is not feasible (yet), nor is=20 secure [ICE must occur for mutual agreement to exchange data between=20 peers], but having controls for how these components are wired together=20 is extremely feasible from JS and would allow immensely powerful apps to be produced from JS.

    What would = you like to do that you can't do via SDP right now? =C2=A0You said this= isn't just about working through SDP. =C2=A0But I don't see anythi= ng concrete you can't do right now with sufficient SDP parsing/building= /munging/hackery.

    =C2=A0
    2) I don't want my primary interface to control media/RTP engines to be= =20 via obtaining or providing SDPs to the browser (or any alternative=20 serialized format); especially given that SDP requires a round trip=20 offer/answer to the remote party to affect change (e.g. it's entirely= =20 possible to do that stateless and one-sided). The SPD interface API is a monolithic do-everything serialized format to control an engine but=20 extremely badly/poorly/short sighted (regardless if it is SDP or=20 whatever instead), and it's wholly unneeded.

    Short summary: "I don't want to use SDP". =C2= =A0Right?

    3) I don't want a replacement for SDP with another more "pretty&qu= ot; format=20 like JSON.

    Short summary: "I= don't want to use SDP or a different syntax for SDP". =C2=A0Right= ?

    4) I want no specified requirement from the browser to have any=20 particular form of media negotiation API requirement what-so-ever=20 (regardless if I can opt to substitute with my own format on the wire or not)

    Short summary: "I don't wan= t to use SDP or a different syntax for SDP". =C2=A0Right?
    =C2=A0
    5) Using SDP with offer/answer bu= ild into the browser binary is a=20 horribly BAD technical choice (even for SIP folks) and must be stopped,=20 see: http://www.ietf.org/mail-archive/web/rtcweb/curre= nt/msg07873.html

    Short summary: &= quot;I don't want to use SDP". =C2=A0Right?
    =C2=A0


    I too want to understand the rational for keeping something as bad as=20 SDP with offer/answer as the primary mechanism for controlling the media components and interaction to those component and more importantly, I'= d too would like to open debate to agreeing or not to provide a lower=20 layer API rather than a media negotiation API as a complete substitute=20 alternative to SDP with offer/answer.

    If we can agree that it's far superior to have a lower level media/RTC= =20 component API rather than a media negotiation API, then we can propose=20 what that API could look like (and there are people who have already=20 have starting proposals). I'd throw my hat in the ring to propose such= =20 and API if necessary as I've written such engines from scratch before.= =20 But I don't want to waste time proposing ore reviewing such an API whic= h will be summarily dismissed because people are so stuck on requiring a=20 media negotiation API built into the browser binary, and specifically=20 SDP with offer/answer in this case.


    The WG may dislike and reject your proposal, but there's a bit of tr= uth to the old mathematically incorrect sports adage "you miss 100% of= the shots you don't take".


    Anyone who argues that they need/want that simple SDP media negotiation=20 API must understand that a lower level API would allow a wrapper API to=20 produce the same WebRTC API the have today but be built entirely from=20 JavaScript

    That depends on how low-le= vel you go. =C2=A0If you go too low-level, it becomes infeasible to do thin= gs correctly and performantly in JavaScript.
    =C2=A0
    upon a lower level API. Thu= s they can have their "just=20 add-milk" baking API. But those of us who need control of the raw=20 ingredients beyond the "just add milk" can still innovate.

    -Robin


    <compose-unknown-contact.jpg>
    =20 19 June, 2013=20 2:49 AM
    =
    Correct my if=20 I'm wrong, but the API already leaves what goes over the wire completel= y up to the JS app. =C2=A0So we couldn't re-open a debate of "SDP o= r not SDP"=20 for the wire format, because there's nothing to debate. =C2=A0We alread= y=20 decided it would be left to the JS to decide. =C2=A0The only thing left to= =20 debate is the API. =C2=A0

    Or am I wrong?




    _______________________________________________
    rtcweb m= ailing=20 list
    rtcweb@ietf.or= g
    https://www.ietf.org/mailman/listinfo/rtcweb
    <compose-unknown-contact.jpg>
    =20 19 June, 2013=20 2:34 AM
    =
    Hi,
    =C2=A0
    We need to be very clear what we talk about,=20 or some people are always going to be confused :)
    =C2=A0
    So, AFAIK, the discussion is about SDP O/A=20 usage in the API, only in the API, and nowhere but the API.
    =C2=A0
    Whatever people us on the wire is outside the= =20 scope.
    =C2=A0
    Right?
    =C2=A0
    Regards,
    =C2=A0
    Christer
    =C2=A0


    Sent from Windows using TouchDown (www.nitrodesk.com<= /a>)
    -----Original Message-----
    From: Peter Thatcher [    pthatcher@google.com]
    To: Martin Thomson [martin.thomson@gmail.com]
    CC: rtcweb@ietf= .org [rtcweb@ietf.= org]
    Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate t= o be=20 re-opened
    Martin, you're right; that was overly harsh of me. =C2= =A0Adam, I apologize. =C2=A0I'll be civil in the future.



    _______________________________________________
    rtcweb m= ailing=20 list
    rtcweb@ietf.or= g
    https://www.ietf.org/mailman/listinfo/rtcweb
    <compose-unknown-contact.jpg>
    =20 19 June, 2013=20 1:36 AM
    =
    Martin, you're=20 right; that was overly harsh of me. =C2=A0Adam, I apologize. =C2=A0I'll= be civil=20 in the future.



    _______________________________________________
    rtcweb m= ailing=20 list
    rtcweb@ietf.or= g
    https://www.ietf.org/mailman/listinfo/rtcweb
    <compose-unknown-contact.jpg>
    =20 18 June, 2013=20 6:25 PM
    I agree with Peter, except for this bit:

    Adam is much harder to confuse= =20 than you think, or than he professes.

    Speaking of burning it all=20 down and starting over. If you want a
    house-related analogy, that's= =20 not quite correct. It's refusing to
    build an extension because the= =20 old house, while legally fit for
    habitation, is falling down around=20 your ears. Since you only need
    foundations, it's not that big a job= =20 (though I'll grant you that it's
    bigger than many people realize= ,=20 even with that smaller scope).
    ______________________________= _________________
    rtcweb mailing list
    rtcwe= b@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    <compose-unknown-contact.jpg>
    =20 18 June, 2013=20 6:16 PM
    Adam, I think=20 you're confused. =C2=A0As Ted pointed out, there are two different uses= of=20 SDP: 1. =C2=A0as a control surface, 2. as a message format for signalling.= =20 =C2=A0SDPNG was trying to replace SDP for #2. =C2=A0While I believe this th= read=20 was started entirely focused on #1. =C2=A0So you're talking about diffe= rent=20 things.

    So far the only time spent on trying to replace or avoid=20 SDP for #1 has been "comment 22", and to a lesser extent the prop= osal I=20 just made for adding 2 methods to PeerConnection (createLocalStream and=20 createRemoteStream). =C2=A0 I think it's incorrect to conclude that we = should never try to improve #1 just because other in the past failed to=20 replace #2. =C2=A0They're very different.

    I also don't think we should burn down WebRTC and= =20 start over, but despite what some seem to think, we don't have to choos= e between "burn it down" and "never improve it". =C2=A0T= here are many options=20 other than the two extremes.



    By the=20 way, a gentle reminder: SDP is not the only way to do #2. =C2=A0I work on a= =20 rather large system almost entirely build around Jingle, without a hint=20 of SDP, and it works just fine. =C2=A0Much better than SDP would have, I=20 think. =C2=A0Just because SDPNG didn't work out doesn't mean there = will never be any way other to do signalling than SDP.




    _______________________________________________
    rtcweb m= ailing=20 list
    rtcweb@ietf.or= g
    https://www.ietf.org/mailman/listinfo/rtcweb

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