From pkyzivat@cisco.com Wed Dec 1 05:57:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3168728C61D for ; Wed, 1 Dec 2010 05:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.477 X-Spam-Level: X-Spam-Status: No, score=-110.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+O5ZOp2+xKc for ; Wed, 1 Dec 2010 05:57:25 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D4C4B28C667 for ; Wed, 1 Dec 2010 05:56:35 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPri9UxAZnwN/2dsb2JhbACjFnGocpsshUcEhF6GCIMQ X-IronPort-AV: E=Sophos;i="4.59,283,1288569600"; d="scan'208";a="187695801" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 01 Dec 2010 13:57:49 +0000 Received: from [161.44.113.132] (dhcp-161-44-113-132.cisco.com [161.44.113.132]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oB1Dvmdk018484; Wed, 1 Dec 2010 13:57:48 GMT Message-ID: <4CF6545C.3090905@cisco.com> Date: Wed, 01 Dec 2010 08:57:48 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <20101128221502.13473.41922.idtracker@localhost>, <00e401cb8f4a$e28a56e0$a79f04a0$@packetizer.com><7F2072F1E0DE894DA4B517B93C6A058502C71899@ESESSCMS0356.eemea.ericsson.se><018901cb8fc0$eb42fdc0$c1c8f940$@packetizer.com> <94A3B19F-F340-4E7D-8789-4139F8B2239C@acmepacket.com> <4CF3B4B2.80301@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 13:57:26 -0000 On 11/29/2010 3:07 PM, Hadriel Kaplan wrote: > > On Nov 29, 2010, at 9:12 AM, Paul Kyzivat wrote: > >> I find this very distressing: >> ... [snip] ... >> At Mastricht we had an informal meeting to discuss the possibility of >> doing something similar to Behave for SBCs, but it went nowhere - there >> was no consensus that anything meaningful could be done. But I think we >> will continue to have problems like this one with session-id until we >> find a way to confront this. ISTM we really need a "declaration of SIP >> rights" that spells out the things that a well defined middle box will >> not mess with. And it needs to be defined not as an enumeration of >> already defined things, but rather as an algorithm that may be applied >> to yet-to-be-defined things as well. > > The thing I find distressing is the continual belief that session-id (or any variant thereof) is tied to the SBC "problem" and crossing them. Session-id isn't just about SBCs. It's about PBX's, softswitches, app servers, feature servers, etc. All kinds of things are B2BUAs and replace the call-id/tags on their UAC side. If this were just about crossing SBC's, I wouldn't bother publishing something in the IETF. Frankly, I'd call up three other vendors in the SBC market, and between us that would cover>90% of it. Well, IIUC *you* are the one who stresses limiting the scope of applicability of session-id to "troubleshooting" *because* broadening its scope would encourage blocking propagation of the session-id. > And if there were a push for a BEHAVE of SBCs, it would have to start off with not believing SBCs somehow restrict your "SIP rights". > This isn't a NAT or Firewall you're silently crossing as a bump in the wire to reach the public Internet. > Your client sent its SIP request to the SBC, which is the UAS. Your SIP ends there. There is quite a difference between the case where you address a request to a URI that happens to be a B2BUA, and the case where you address the request to some URI and then route the request through an intermediary that turns out to act as an SBC rather than a proxy. Then there is a fuzzy middle ground where you want to send a request to a phone number, but don't know or care what domain is responsible for that number, and so end up addressing it to a URI that turns out to be serviced by an intermediary, be that SBC or gateway. ISTM the trick is to come up with a new notion of e2e that encompasses the presence of UA intermediaries, and some expectations of what can then be expected to survive e2e. And yes, that should cover intermediaries other than just SBCs. > It's like telling me a SIP PSTN Gateway restricts your "SIP rights" because it doesn't pass some new SIP header through SS7/ISUP. > Or telling me my SIP phone restricts your rights if my phone doesn't support REFER or Invite-Replaces from you. You may not get a feature you want, but you have no inalienable "right" to get all features from any/every UAS you send a message to. > > >> I'm curious if others feel this way, or am I just a lone raging lunatic? > > Is that an exclusive "or"? ;) I may be a raging lunatic, but I doubt I'm the lone one. I can think of a number of candidates, but I'll keep that list to myself. :-) Thanks, Paul From richard@shockey.us Wed Dec 1 08:43:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BACA728C0D6 for ; Wed, 1 Dec 2010 08:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.388 X-Spam-Level: X-Spam-Status: No, score=-101.388 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_DUL=0.877, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78dAvzGd-yyA for ; Wed, 1 Dec 2010 08:43:26 -0800 (PST) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 066753A6BB6 for ; Wed, 1 Dec 2010 08:43:25 -0800 (PST) Received: (qmail 3451 invoked by uid 0); 1 Dec 2010 16:44:39 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy2.bluehost.com with SMTP; 1 Dec 2010 16:44:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=f0g1nNQ7WPLGPxvOkp0G8duXpsPQ/4FKD3aOc1GVkX/4Vkb0crgQNK09opomgwZ5zs07oX0I2oLw8cnb6u87ubesyKyLJnuSatfmu88UrP8P3lHeMOJqfI9z+lAjzG4N; Received: from pool-173-79-200-247.washdc.fios.verizon.net ([173.79.200.247] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PNpnL-0004rW-7j; Wed, 01 Dec 2010 09:44:39 -0700 From: "Richard Shockey" To: "'Paul Kyzivat'" , References: <20101128221502.13473.41922.idtracker@localhost>, <00e401cb8f4a$e28a56e0$a79f04a0$@packetizer.com><7F2072F1E0DE894DA4B517B93C6A058502C71899@ESESSCMS0356.eemea.ericsson.se><018901cb8fc0$eb42fdc0$c1c8f940$@packetizer.com> <94A3B19F-F340-4E7D-8789-4139F8B2239C@acmepacket.com> <4CF3B4B2.80301@cisco.com> In-Reply-To: <4CF3B4B2.80301@cisco.com> Date: Wed, 1 Dec 2010 11:44:36 -0500 Message-ID: <008001cb9177$0a8cb380$1fa61a80$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuPz3EtQrGA17ZmTfCC7j81geR5CABp2TEA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.200.247 authed with richard@shockey.us} Subject: Re: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 16:43:27 -0000 Hummm. SIP Neutrality ..very timely. :-) At Mastricht we had an informal meeting to discuss the possibility of doing something similar to Behave for SBCs, but it went nowhere - there was no consensus that anything meaningful could be done. But I think we will continue to have problems like this one with session-id until we find a way to confront this. ISTM we really need a "declaration of SIP rights" that spells out the things that a well defined middle box will not mess with. And it needs to be defined not as an enumeration of already defined things, but rather as an algorithm that may be applied to yet-to-be-defined things as well. I'm curious if others feel this way, or am I just a lone raging lunatic? Thanks, Paul From henry.sinnreich@gmail.com Wed Dec 1 08:49:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ED0C3A6B94 for ; Wed, 1 Dec 2010 08:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSyft4UcC0pl for ; Wed, 1 Dec 2010 08:49:35 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id CC4373A6B73 for ; Wed, 1 Dec 2010 08:49:32 -0800 (PST) Received: by gxk28 with SMTP id 28so3370621gxk.31 for ; Wed, 01 Dec 2010 08:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=7jdAdRVtB/IX+9p/RfadvZS4nnuCYxg0gl73DfGUOAA=; b=Qz7aLKQqEuOOpup11MwBks1dPjM2DZA3eM+aeC5YuRoF749XzvzCY/CMOpJGzgEHYE Ic/Jf/ad1+ieZRV4qCo4Ct7csitC9vifsg+z/gZ0F9T1wP9HXxga5851V6jxAsMEn18D MCyPUIhCakj+/Ve6ByZFdsY2kl/HrlRgQ9qWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=vi67BuKRsOvkLva/hvdvyqAuEzwXPjuPKi/QjxazVhOcwoGFy4fRZH8cbZu2sEud6r NU0q8EbPG0al6NHntem9rAgZp8Wm8ma3PQ3BMDzeVzQ+XiFq4iYJxW25/tV5jAhhTrCA 8JiObHIdy6pim1gPnhRP41lPteehjtKbLH+xs= Received: by 10.151.10.14 with SMTP id n14mr5244722ybi.167.1291222245865; Wed, 01 Dec 2010 08:50:45 -0800 (PST) Received: from [10.0.1.7] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id p30sm100086ybk.20.2010.12.01.08.50.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 01 Dec 2010 08:50:44 -0800 (PST) User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Wed, 01 Dec 2010 10:50:40 -0600 From: Henry Sinnreich To: Richard Shockey , 'Paul Kyzivat' , Message-ID: Thread-Topic: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-00.txt Thread-Index: AcuPz3EtQrGA17ZmTfCC7j81geR5CABp2TEAAABDLTQ= In-Reply-To: <008001cb9177$0a8cb380$1fa61a80$@us> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 16:49:36 -0000 +1 It is actually long overdue. >but rather as an algorithm Is the key objective IMO. Thanks, Henry > At Mastricht we had an informal meeting to discuss the possibility of > doing something similar to Behave for SBCs, but it went nowhere - there > was no consensus that anything meaningful could be done. But I think we > will continue to have problems like this one with session-id until we > find a way to confront this. ISTM we really need a "declaration of SIP > rights" that spells out the things that a well defined middle box will > not mess with. And it needs to be defined not as an enumeration of > already defined things, but rather as an algorithm that may be applied > to yet-to-be-defined things as well. > > I'm curious if others feel this way, or am I just a lone raging lunatic? > > Thanks, > Paul > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From laura.liess.dt@googlemail.com Fri Dec 3 07:38:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA8C28C107 for ; Fri, 3 Dec 2010 07:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20t868ADnwBE for ; Fri, 3 Dec 2010 07:38:02 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 4A6EA28C105 for ; Fri, 3 Dec 2010 07:38:00 -0800 (PST) Received: by gwj17 with SMTP id 17so5375200gwj.31 for ; Fri, 03 Dec 2010 07:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g5XXn5hWFGWD+/9lbE91jU0GxfPyxp2EwTcaPEmFwVQ=; b=B3De8heVCAqCJSfGilK51KgR2sq8PzCN/NETQj7T411G4/2lCXQi4vGSEiQNNFMcVE 1z3UFsxL+vGXP3zq4frSu0m1uYpSiKvYgPyEmUoPOLOllJT0Y0QZIpr8xZcI1Sw8RCWl UjbVUb8BvHDUSf9SufDP53qcYxBjFC25x7AWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=P/GpkVOVfaOWiFJeNQBsiby14vRn388xHA32o1QpkT2RpAb1ZUvLcwPjyaabEA9sHz gq5hTQIwRO3+tSS38nsD2vppFNmLwc0ZBVUkGSQcSP04CZBFvy8Wa6l0jXYxMEBM9M2l HRQFJX/8APHtxwrOb5jqIzWhe9Y7b9FhUz3Rw= MIME-Version: 1.0 Received: by 10.150.135.11 with SMTP id i11mr3948231ybd.230.1291390756477; Fri, 03 Dec 2010 07:39:16 -0800 (PST) Received: by 10.151.153.16 with HTTP; Fri, 3 Dec 2010 07:39:16 -0800 (PST) In-Reply-To: <4CF52FAB.7080405@packetizer.com> References: <20101128221502.13473.41922.idtracker@localhost> <00e401cb8f4a$e28a56e0$a79f04a0$@packetizer.com> <8BD5F4C6-200F-41D8-8413-2669EE8DD24C@acmepacket.com> <4CF43ADC.7070204@packetizer.com> <4CF52FAB.7080405@packetizer.com> Date: Fri, 3 Dec 2010 16:39:16 +0100 Message-ID: From: Laura Liess To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org, chrep@cisco.com, Hadriel Kaplan Subject: Re: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 15:38:07 -0000 Paul, I definitively like your idea. However, something is needed for troubleshooting, which works also for existing end devices which do not support the session-ID. Hadriel's draft does this. It would be great if we could find something which works for both. I understand that you are flexible about how Session-UUID is transmiter (parameter in Contact or header) and about how the UUID is calculated. Another question on the draft: Why do you need to calculate the Session-UUID in both UAs? Would it be sufficient that UA A inserts its UUID_A, sends it in the INVITE to UA B, then UA B adds its UUID_B and sends the new Session-UUID, which is UUID_B +UUID_A, back to UA A in the 200 OK? Thanks a lot Laura 2010/11/30 Paul E. Jones : > =A0Laura, > > I think it's good to overcome the weaknesses of both proposals. =A0Howeve= r, > what we could not understand is how Hadriel's draft would accommodate thi= ngs > such as joining two sessions together as a B2BUA. =A0This happens with > enterprise PBXes, for example. =A0If A and B both have sessions establish= ed > with C, then C joins those together in some way so that there is now a > single session between A and B, what is the session ID? =A0The approach w= e > suggest would accommodate that. > > Our proposal does hide the user's identity if random numbers are used for > the UUIDs, which is a valid option when generating UUIDs. =A0We could als= o > hash the values. > > Carrying the UUIDs inside a new header (e.g., Session-UUID) is also possi= ble > and, as I mentioned separately, was the way the first (pre-published) dra= ft > had it. > > The approach we propose will also work with H.323, which is something I > intend to introduce there, too. > > What is not clear is how our proposal comes up short for the troubleshoot= ing > case. =A0I can see a situation where A (a device supporting Session-UUID) > might call B (without this support) and then there's no way to get the > complete Session ID for troubleshooting. =A0I don't see a solution for th= at > case with our approach. > > I am not opposed to having two values going across the wire, though I wou= ld > prefer to avoid that. =A0It gets really ugly when we have so may differen= t > kinds of identifiers flowing across the network. =A0It would be really go= od to > have one solution that meets everyone's needs. > > What we want is to have a session ID that allows for calls to be > transffered/joined/merged/etc. and to be able to still have an end-to-end= ID > all devices agree upon as call legs are moved around. =A0We'd also like t= o be > able to use that ID to relate media flows with signaling flows (e.g., all= ow > RTCP packets to contain the composed Session ID). =A0We would appreciate = the > ability to relate calls to a conference by taking note of shared UUID > values. =A0We'd also appreciate the ability to take note of changes relat= ed to > sessions (e.g., call joins) as UUID components change. > > Paul > > On 11/30/2010 10:38 AM, Laura Liess wrote: >> >> Sorry for the previous unfinished message. Here is the complete one. >> >> >> =A0It seems that Hadriel's Session-ID for troubleshooting and the new >> =A0UUID based Session-ID are almost complimentary concerning their pros >> =A0and cons. >> =A0a) Troubleshooting Session-ID: >> =A0 =A0 =A0 =A0 + Works for every kind of SIP-messages >> =A0 =A0 =A0 =A0 + External trubleshooting devices are able to correlate >> =A0different segments of a call, also when the end device initiating the >> =A0call does not support the Session ID. =A0The first B2BUA in the call >> =A0constructs the Session-ID on behalf of the end device, as a hash of >> =A0the Call-ID it receives =A0from the end device. >> =A0 =A0 =A0 =A0 + Hides the identity (and IP-address) of the end device >> =A0 =A0 =A0 =A0 - =A0Does not cover all use cases where dialog correlati= on is >> needed. >> >> =A0b) UUID based Session-ID >> =A0 =A0 =A0 =A0+ Possibly covers all or most use cases where dialog >> =A0correlation is needed. >> =A0 =A0 =A0 =A0- Does not work for every kind of SIP-messages >> =A0 =A0 =A0 =A0- External trubleshooting devices are not able to correla= te >> =A0 =A0 =A0 =A0 =A0different segments of a call when the end device init= iating the >> =A0 =A0 =A0 =A0 =A0call does not support the Session ID. >> =A0 =A0 =A0 =A0- Does not hide =A0the identity (and IP-address) of the e= nd device >> >> Hadriel's Session-ID is already up and running within many boxes. >> >> Maybe it is possible to find a solution which has the pros of both >> proposals and is compatible with the already implemented Session-ID? >> Just a thought, I am not sure it works: The first UA or B2BUA >> calculates the Session-ID as described in Hadriel's draft. If it >> supports the new mechanis, it concatenates the UUID to it and writes >> the result into the Session-ID header. =A0The next UA adds its own UUID >> to it if its supports the new mechanism ans so on. I think the >> correlation for troubleshooting would work, and the correlation for >> conferencing would work if the conference initiator supports the new >> mechanism. =A0the Session-ID may be different for different messages of >> the same call segment, but there we have the call-ID. >> >> Thanks a lot >> Laura >> >> >>> 2010/11/30 Paul E. Jones: >>>> >>>> =A0Hadriel, >>>> >>>> It's OK if the conference server does not know what UUID to send. >>>> =A0Once >>>> the user enters the conference details, the call might be transferred = to >>>> another device and/or just change state and dropped into an existing >>>> conference. =A0Either way, a new INVITE would be sent from the confere= nce >>>> server to the remote endpoint with the new UUID. =A0This new UUID woul= d >>>> then >>>> replace the previous value received. =A0At this point, the call could = be >>>> seen >>>> as being part of the same conference. =A0UUID values from either endpo= int >>>> might change at any time due to transfers or replacement of "call legs= " >>>> that >>>> are not necessarily signaled. =A0Either way, the Session ID is updated >>>> through >>>> the whole process. =A0Further, those who need to know the current Sess= ion >>>> ID >>>> would have that information, whether it is the endpoint or >>>> intermediaries. >>>> >>>> To your points: >>>> 1) Would a standalone MESSAGE be a part of a session? =A0Is this state= ment >>>> true for MESSAGE sent as a part of a session? (You've got me on that >>>> one.) >>>> =A0In any case, we can most certainly send this as a new header like y= ou >>>> did >>>> in your draft. =A0My first cut at this introduced a new header called >>>> Session-ID-UUID. =A0It's a bit long, so I'd prefer Session-UUID. =A0Bu= t, I >>>> definitely have no love for where we place the UUID or even whether it= s >>>> a >>>> UUID or not. =A0It could be an SHA-1 hash of random data for all I car= e: >>>> just >>>> want something that's "guaranteed" to be unique. >>>> 2) Interesting. =A0I'll take your word on that, though I'm not sure wh= y >>>> one >>>> place would be more challenging than another. >>>> 3) People say this, though I never understood why. =A0That said, if on= e >>>> wishes >>>> to hide the MAC, there are procedures to generate UUIDs using random >>>> numbers. =A0I forget off hand what UUID "version" that is, but there a= re >>>> ones >>>> with random digits. =A0In any case, we could create a version 0 UUID >>>> (i.e., >>>> has the MAC) and then run that through a hash function like SHA-1. >>>> >>>> I'm certainly open to most aspects of the text. =A0Most importantly, I= 'd >>>> like >>>> to see progress on defining a session ID value we can use end-to-end i= n >>>> the >>>> spirit of what I've proposed, as I think it meets your requirements an= d >>>> those I have. >>>> >>>> Paul >>>> >>>> On 11/29/2010 9:12 AM, Hadriel Kaplan wrote: >>>>> >>>>> Hi Paul, >>>>> >>>>> With regard to using the two-sided approach in order to handle >>>>> conference >>>>> call cases, this was discussed way back for the session-id draft as >>>>> well... >>>>> but the issue was that many/most conference servers don't actually kn= ow >>>>> that >>>>> multiple calls are part of the same conference until the user presses= a >>>>> conference code in DTMF, which is after the call is answered. =A0Do y= ou >>>>> expect >>>>> the conference server to issue a re-INVITE in such cases, to transmit= a >>>>> new >>>>> UUID for its side? >>>>> >>>>> With regards to specifics about the proposed mechanism: >>>>> 1) Putting it in the Contact header means it won't work for MESSAGE >>>>> requests, since they have no Contact; and it would be weird in a >>>>> REGISTER >>>>> which can have multiple Contacts. =A0At the end of the day, this ID i= sn't >>>>> really a property of the Contact. >>>>> 2) Putting it in the Contact header means it will be very difficult t= o >>>>> get >>>>> SBCs/B2BUAs to "leave it alone" without having to change their intern= al >>>>> software, arguably more so than if it were in a separate header. >>>>> 3) Using a UUID is not "safe", in the sense that it reveals a MAC >>>>> address >>>>> and therefore the vendor/manufacturer of the UA, so an SBC would be >>>>> motivated to remove/replace this. (I know it's a minor concern, but >>>>> some >>>>> people do worry about this) >>>>> >>>>> -hadriel >>>>> >>>>> >>>>> On Nov 28, 2010, at 5:23 PM, Paul E. Jones wrote: >>>>> >>>>>> Folks, >>>>>> >>>>>> I want to bring to your attention this new draft some colleagues and= I >>>>>> put >>>>>> together to try to address the need for a "session identifier" that >>>>>> allows >>>>>> for end-to-end session identification. =A0We also see utility that g= oes >>>>>> beyond >>>>>> just identifying the session end-to-end, as outlined in the document= . >>>>>> =A0We >>>>>> believe this approach will satisfy those needs and do so in a very >>>>>> simple, >>>>>> straight-forward way. =A0Equally important, this approach will work = with >>>>>> SIP, >>>>>> H.323, and other session signaling protocols. >>>>>> >>>>>> We welcome any feedback you'd like to provide. >>>>>> >>>>>> Thanks! >>>>>> Paul >>>>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> > From paulej@packetizer.com Fri Dec 3 08:21:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C45F28C12C for ; Fri, 3 Dec 2010 08:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1tofPxUSvjo for ; Fri, 3 Dec 2010 08:21:03 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id CEEAA28C11E for ; Fri, 3 Dec 2010 08:21:02 -0800 (PST) Received: from [64.102.200.85] (dhcp-64-102-200-85.cisco.com [64.102.200.85]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id oB3GLtOl003450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Dec 2010 11:22:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1291393322; bh=uIsF9rvYqggoqr16va3mF+M6R1ezUHrHcAdAASq9DLQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=HVm/kqsCiWVuSv8uxKbtHLl/Jf4iY3SH6eoy9O3PL3zEs5ob7lGQOQiHnhQJDNZqz vYvokhK7xaGmvbS1OZUcAnw+pPuedxfwouNzV9WrHCnD83mlJfVcSxncUrvB6sAF+F bCcU5wyK7c9a4O5joy/jqnStV2gm/A4cSkIThvcQ= Message-ID: <4CF9191F.3040501@packetizer.com> Date: Fri, 03 Dec 2010 11:21:51 -0500 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Laura Liess References: <20101128221502.13473.41922.idtracker@localhost> <00e401cb8f4a$e28a56e0$a79f04a0$@packetizer.com> <8BD5F4C6-200F-41D8-8413-2669EE8DD24C@acmepacket.com> <4CF43ADC.7070204@packetizer.com> <4CF52FAB.7080405@packetizer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, chrep@cisco.com, Hadriel Kaplan Subject: Re: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 16:21:05 -0000 Laura, If both end devices have no concept of a "Session-ID" or "Session-UUID" or other, then it makes no difference. If either device supports either Session-ID or Session-UUID, then that alone could be used for troubleshooting purposes on the signaling path. It would not be useful, though, to correlate signaling and media flows. The reason for calculating a Session-UUID in both endpoints is so that the Session-ID would be the concatenation of these two generated UUIDs. This Session-ID could then be used in logging, RSVP, RTCP, or elsewhere in order to identify the session end-to-end. Further, since sessions might be joined in the middle of the network by devices like B2BUAs, we cannot assume that one device or the other will generate "the" session ID. We believe it must be something composed of information from both endpoints. So, what we're proposing is that A sends Session-UUID in the INVITE. The remote end would return its Session-UUID in the reply. It would not include two Session-UUIDs, as it's not necessary. With the INVITE/200 exchange, both endpoints know what the Session-ID is (as would any intermediary that has an interest). During the course of the session, the call might be modified (silently redirected or joined to a different endpoint). In such a case, a new INVITE might be sent from a B2BUA, for example, that contains a new Session-UUID. The receiving endpoint would recognize this as a change in the Session-ID. Indeed, the end-to-end session has changed. This change would be noted by interested parties. You suggested below that A sends UUID_A and that B sends UUID_A || UUID_B. We could do this, but I'm not sure what value that offers. A already knows its UUID_A and only needs to receive the value UUID_B. Paul On 12/3/2010 10:39 AM, Laura Liess wrote: > Paul, > I definitively like your idea. > However, something is needed for troubleshooting, which works also for > existing end devices which do not support the session-ID. Hadriel's > draft does this. It would be great if we could find something which > works for both. > > I understand that you are flexible about how Session-UUID is > transmiter (parameter in Contact or header) and about how the UUID is > calculated. > > Another question on the draft: > Why do you need to calculate the Session-UUID in both UAs? > Would it be sufficient that UA A inserts its UUID_A, sends it in the > INVITE to UA > B, then UA B adds its UUID_B and sends the new Session-UUID, which is > UUID_B +UUID_A, back to UA A in the 200 OK? > > > Thanks a lot > Laura > > > > 2010/11/30 Paul E. Jones: >> Laura, >> >> I think it's good to overcome the weaknesses of both proposals. However, >> what we could not understand is how Hadriel's draft would accommodate things >> such as joining two sessions together as a B2BUA. This happens with >> enterprise PBXes, for example. If A and B both have sessions established >> with C, then C joins those together in some way so that there is now a >> single session between A and B, what is the session ID? The approach we >> suggest would accommodate that. > >> Our proposal does hide the user's identity if random numbers are used for >> the UUIDs, which is a valid option when generating UUIDs. We could also >> hash the values. >> >> Carrying the UUIDs inside a new header (e.g., Session-UUID) is also possible >> and, as I mentioned separately, was the way the first (pre-published) draft >> had it. >> >> The approach we propose will also work with H.323, which is something I >> intend to introduce there, too. >> >> What is not clear is how our proposal comes up short for the troubleshooting >> case. I can see a situation where A (a device supporting Session-UUID) >> might call B (without this support) and then there's no way to get the >> complete Session ID for troubleshooting. I don't see a solution for that >> case with our approach. >> >> I am not opposed to having two values going across the wire, though I would >> prefer to avoid that. It gets really ugly when we have so may different >> kinds of identifiers flowing across the network. It would be really good to >> have one solution that meets everyone's needs. >> >> What we want is to have a session ID that allows for calls to be >> transffered/joined/merged/etc. and to be able to still have an end-to-end ID >> all devices agree upon as call legs are moved around. We'd also like to be >> able to use that ID to relate media flows with signaling flows (e.g., allow >> RTCP packets to contain the composed Session ID). We would appreciate the >> ability to relate calls to a conference by taking note of shared UUID >> values. We'd also appreciate the ability to take note of changes related to >> sessions (e.g., call joins) as UUID components change. >> >> Paul >> >> On 11/30/2010 10:38 AM, Laura Liess wrote: >>> Sorry for the previous unfinished message. Here is the complete one. >>> >>> >>> It seems that Hadriel's Session-ID for troubleshooting and the new >>> UUID based Session-ID are almost complimentary concerning their pros >>> and cons. >>> a) Troubleshooting Session-ID: >>> + Works for every kind of SIP-messages >>> + External trubleshooting devices are able to correlate >>> different segments of a call, also when the end device initiating the >>> call does not support the Session ID. The first B2BUA in the call >>> constructs the Session-ID on behalf of the end device, as a hash of >>> the Call-ID it receives from the end device. >>> + Hides the identity (and IP-address) of the end device >>> - Does not cover all use cases where dialog correlation is >>> needed. >>> >>> b) UUID based Session-ID >>> + Possibly covers all or most use cases where dialog >>> correlation is needed. >>> - Does not work for every kind of SIP-messages >>> - External trubleshooting devices are not able to correlate >>> different segments of a call when the end device initiating the >>> call does not support the Session ID. >>> - Does not hide the identity (and IP-address) of the end device >>> >>> Hadriel's Session-ID is already up and running within many boxes. >>> >>> Maybe it is possible to find a solution which has the pros of both >>> proposals and is compatible with the already implemented Session-ID? >>> Just a thought, I am not sure it works: The first UA or B2BUA >>> calculates the Session-ID as described in Hadriel's draft. If it >>> supports the new mechanis, it concatenates the UUID to it and writes >>> the result into the Session-ID header. The next UA adds its own UUID >>> to it if its supports the new mechanism ans so on. I think the >>> correlation for troubleshooting would work, and the correlation for >>> conferencing would work if the conference initiator supports the new >>> mechanism. the Session-ID may be different for different messages of >>> the same call segment, but there we have the call-ID. >>> >>> Thanks a lot >>> Laura >>> >>> >>>> 2010/11/30 Paul E. Jones: >>>>> Hadriel, >>>>> >>>>> It's OK if the conference server does not know what UUID to send. >>>>> Once >>>>> the user enters the conference details, the call might be transferred to >>>>> another device and/or just change state and dropped into an existing >>>>> conference. Either way, a new INVITE would be sent from the conference >>>>> server to the remote endpoint with the new UUID. This new UUID would >>>>> then >>>>> replace the previous value received. At this point, the call could be >>>>> seen >>>>> as being part of the same conference. UUID values from either endpoint >>>>> might change at any time due to transfers or replacement of "call legs" >>>>> that >>>>> are not necessarily signaled. Either way, the Session ID is updated >>>>> through >>>>> the whole process. Further, those who need to know the current Session >>>>> ID >>>>> would have that information, whether it is the endpoint or >>>>> intermediaries. >>>>> >>>>> To your points: >>>>> 1) Would a standalone MESSAGE be a part of a session? Is this statement >>>>> true for MESSAGE sent as a part of a session? (You've got me on that >>>>> one.) >>>>> In any case, we can most certainly send this as a new header like you >>>>> did >>>>> in your draft. My first cut at this introduced a new header called >>>>> Session-ID-UUID. It's a bit long, so I'd prefer Session-UUID. But, I >>>>> definitely have no love for where we place the UUID or even whether its >>>>> a >>>>> UUID or not. It could be an SHA-1 hash of random data for all I care: >>>>> just >>>>> want something that's "guaranteed" to be unique. >>>>> 2) Interesting. I'll take your word on that, though I'm not sure why >>>>> one >>>>> place would be more challenging than another. >>>>> 3) People say this, though I never understood why. That said, if one >>>>> wishes >>>>> to hide the MAC, there are procedures to generate UUIDs using random >>>>> numbers. I forget off hand what UUID "version" that is, but there are >>>>> ones >>>>> with random digits. In any case, we could create a version 0 UUID >>>>> (i.e., >>>>> has the MAC) and then run that through a hash function like SHA-1. >>>>> >>>>> I'm certainly open to most aspects of the text. Most importantly, I'd >>>>> like >>>>> to see progress on defining a session ID value we can use end-to-end in >>>>> the >>>>> spirit of what I've proposed, as I think it meets your requirements and >>>>> those I have. >>>>> >>>>> Paul >>>>> >>>>> On 11/29/2010 9:12 AM, Hadriel Kaplan wrote: >>>>>> Hi Paul, >>>>>> >>>>>> With regard to using the two-sided approach in order to handle >>>>>> conference >>>>>> call cases, this was discussed way back for the session-id draft as >>>>>> well... >>>>>> but the issue was that many/most conference servers don't actually know >>>>>> that >>>>>> multiple calls are part of the same conference until the user presses a >>>>>> conference code in DTMF, which is after the call is answered. Do you >>>>>> expect >>>>>> the conference server to issue a re-INVITE in such cases, to transmit a >>>>>> new >>>>>> UUID for its side? >>>>>> >>>>>> With regards to specifics about the proposed mechanism: >>>>>> 1) Putting it in the Contact header means it won't work for MESSAGE >>>>>> requests, since they have no Contact; and it would be weird in a >>>>>> REGISTER >>>>>> which can have multiple Contacts. At the end of the day, this ID isn't >>>>>> really a property of the Contact. >>>>>> 2) Putting it in the Contact header means it will be very difficult to >>>>>> get >>>>>> SBCs/B2BUAs to "leave it alone" without having to change their internal >>>>>> software, arguably more so than if it were in a separate header. >>>>>> 3) Using a UUID is not "safe", in the sense that it reveals a MAC >>>>>> address >>>>>> and therefore the vendor/manufacturer of the UA, so an SBC would be >>>>>> motivated to remove/replace this. (I know it's a minor concern, but >>>>>> some >>>>>> people do worry about this) >>>>>> >>>>>> -hadriel >>>>>> >>>>>> >>>>>> On Nov 28, 2010, at 5:23 PM, Paul E. Jones wrote: >>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> I want to bring to your attention this new draft some colleagues and I >>>>>>> put >>>>>>> together to try to address the need for a "session identifier" that >>>>>>> allows >>>>>>> for end-to-end session identification. We also see utility that goes >>>>>>> beyond >>>>>>> just identifying the session end-to-end, as outlined in the document. >>>>>>> We >>>>>>> believe this approach will satisfy those needs and do so in a very >>>>>>> simple, >>>>>>> straight-forward way. Equally important, this approach will work with >>>>>>> SIP, >>>>>>> H.323, and other session signaling protocols. >>>>>>> >>>>>>> We welcome any feedback you'd like to provide. >>>>>>> >>>>>>> Thanks! >>>>>>> Paul >>>>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> From Peter.Dawes@vodafone.com Mon Dec 6 02:07:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF843A69AC for ; Mon, 6 Dec 2010 02:07:32 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jzzvT2HPyYs for ; Mon, 6 Dec 2010 02:07:31 -0800 (PST) Received: from mailout04.vodafone.com (mailout04.vodafone.com [195.232.224.73]) by core3.amsl.com (Postfix) with ESMTP id 2810A3A6A41 for ; Mon, 6 Dec 2010 02:07:30 -0800 (PST) Received: from mailint04 (localhost [127.0.0.1]) by mailout04 (Postfix) with ESMTP id 9EE3E132727 for ; Mon, 6 Dec 2010 11:08:52 +0100 (CET) Received: from avoexs04.internal.vodafone.com (avoexs04.dc-ratingen.de [145.230.4.198]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint04 (Postfix) with ESMTPS id 9074D13271E for ; Mon, 6 Dec 2010 11:08:52 +0100 (CET) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs04.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Dec 2010 11:08:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB952D.9681C2DA" Date: Mon, 6 Dec 2010 11:10:42 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New I-D: draft-dawes-dispatch-mediasec-parameter-03 Thread-Index: AcuVLddDiI20ewN1Qv+NHkOntMpx+Q== From: "Dawes, Peter, VF-Group" To: X-OriginalArrivalTime: 06 Dec 2010 10:08:54.0168 (UTC) FILETIME=[9686E180:01CB952D] Subject: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 10:07:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB952D.9681C2DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, http://datatracker.ietf.org/doc/draft-dawes-dispatch-mediasec-parameter/ has a new version (-03) with some extra text in the "Motivations" clause following previous e-mail discussions. Apologies for the delay in updating, FYI previous posts on this draft were in May: From: "Dawes, Peter, VF-Group" =20 To: =20 Cc: dispatch at ietf.org=20 Date: Thu, 27 May 2010 15:45:39 +0200=20 From: "DRAGE, Keith (Keith)" =20 To: "Elwell, John" , "Dawes, Peter, VF-Group" , "dispatch at ietf.org" =20 Date: Wed, 26 May 2010 19:35:59 +0200=20 Media security is a requirement for 3GPP networks and this draft is the currently referenced solution. Previous postings were mainly related to the need for the mechanism, which I think was described in some detail, and I would very much welcome further analysis to progress a solution. =20 Regards, Peter ------_=_NextPart_001_01CB952D.9681C2DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New I-D: draft-dawes-dispatch-mediasec-parameter-03

Hello = All,
http://datatracker.ietf.org/doc/draft-dawes-dispatch-mediasec-para= meter/ has a = new version (-03) with some extra text in the "Motivations" = clause following previous e-mail discussions. Apologies for the delay in = updating, FYI previous posts on this draft were in May:

From: "Dawes, Peter, = VF-Group" <Peter.Dawes at vodafone.com>
To: <jmpolk at cisco.com> =
Cc: dispatch at ietf.org
Date: Thu, 27 May 2010 15:45:39 = +0200

From: "DRAGE, Keith = (Keith)" <keith.drage at alcatel-lucent.com>
To: "Elwell, John" = <john.elwell at siemens-enterprise.com>, "Dawes, Peter, = VF-Group" <Peter.Dawes at vodafone.com>, "dispatch at = ietf.org" <dispatch at ietf.org>

Date: Wed, 26 May 2010 19:35:59 = +0200=20

Media security is a = requirement for 3GPP networks and this draft is the currently referenced = solution. Previous postings were mainly related to the need for the = mechanism, which I think was described in some detail, and I would very = much welcome further analysis to progress a solution. 

Regards,
Peter


------_=_NextPart_001_01CB952D.9681C2DA-- From dworley@avaya.com Tue Dec 7 11:08:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17023A6852 for ; Tue, 7 Dec 2010 11:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7U6w0-rIxY5 for ; Tue, 7 Dec 2010 11:08:53 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id A45A03A684B for ; Tue, 7 Dec 2010 11:08:52 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABsV/kzGmAcF/2dsb2JhbACjRXGoagKZQoVJBIRiiTw X-IronPort-AV: E=Sophos;i="4.59,311,1288584000"; d="scan'208";a="222074744" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Dec 2010 14:10:17 -0500 X-IronPort-AV: E=Sophos;i="4.59,311,1288584000"; d="scan'208";a="551794867" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Dec 2010 14:10:16 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 7 Dec 2010 14:10:15 -0500 From: "Worley, Dale R (Dale)" To: "dispatch@ietf.org" Date: Tue, 7 Dec 2010 14:10:15 -0500 Thread-Topic: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-00.txt Thread-Index: AQGceIxBMRvDIaVI6ICKVhI0Ts3JTpPlox9ggA3ub1o= Message-ID: References: <20101128221502.13473.41922.idtracker@localhost>, <00e401cb8f4a$e28a56e0$a79f04a0$@packetizer.com> In-Reply-To: <00e401cb8f4a$e28a56e0$a79f04a0$@packetizer.com> 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 Subject: Re: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 19:08:53 -0000 This draft is intriguing... In concept, it identifies something that we un= derstand but have not named, the "end of a session", what is usually consid= ered a call instance on a phone. E.g., when phone B transfers caller A to = talk to C, the "end of the session" at A does not change, despite that the = A-B dialog has been replaced by the A-C dialog. Indeed, the fact that we s= ay one dialog "replaces" another at A means that the "end of the session" a= t A has not changed. The draft proposes that UAs coin UUIDs to label each = end of a session that they create. Conference servers are a special case, = in that each conference focus uses one end of a session UUID for all of the= legs of the conference. The draft proposes that each UA, in any INVITE, sends the end-of-the-sessio= n UUID at its end. The draft proposes that each UA, when it learns the end-of-the-session UUID= of the other end of a dialog, should combine that with its own end-of-the-= session UUID to generate a "Session Identifier". But there seem to be no places where the Session Identifier becomes manifes= t in the protocol. So I'm not sure what its purpose is. But getting back to the end-of-the-session UUID, that seems like it could b= e useful for troubleshooting, etc. It's a close kin to the "References" he= ader proposal, in that it gives a way to show within the signaling that two= dialogs are associated. It seems to have the same difficulties as Hadriel's session-id when it come= s to having B2BUAs pass it through. Dale From fluffy@cisco.com Tue Dec 7 13:02:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6057628C0F6 for ; Tue, 7 Dec 2010 13:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Xtzsi57Nt6J for ; Tue, 7 Dec 2010 13:02:05 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 980A828C10C for ; Tue, 7 Dec 2010 13:02:03 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA8w/kxAZnwN/2dsb2JhbACjR3GmTptJhUkEhGKGDw X-IronPort-AV: E=Sophos;i="4.59,312,1288569600"; d="scan'208";a="190326113" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 07 Dec 2010 21:03:30 +0000 Received: from bxb-vpn3-339.cisco.com (bxb-vpn3-339.cisco.com [10.86.249.83]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oB7L26oI004558 for ; Tue, 7 Dec 2010 21:02:14 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Dec 2010 16:02:03 -0500 Message-Id: <5223063B-E865-476C-9B52-7BA375F44BDF@cisco.com> To: "dispatch@ietf.org list" Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [dispatch] RELOAD and UDP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 21:02:06 -0000 I just wanted to point out that the RELOAD protocol in P2PSIP WG is = getting close to being sent to IESG and I wanted to point out that it = uses UDP in a way that relates to some of the recent discussions in this = WG, in particular provision of reliable message transport over UDP. WHY UDP? Like many other protocols, RELOAD has the issue where two devices that = are both behind different NATs need to talk to each other. It's = impossible to ensure that direct is always possible so relays are used = in some cases but it's optimal to have it be direct as often as = possible. While most of the data about NAT penetration success is confidential there is still enough = public information available out of CMU and MIT to make the following = points clear: 1) UDP works a fairly high percentage of the time with = ICE-like mechanisms. Most claims for this seem to be in the 80% to low = 90's for success rate, with some variation based on geography. 2) = Success rates for TCP simultaneous open without port prediction are far = lower. It is also very fragile if lots of simultaneous sessions are = happening. 3) Port prediction drastically raises the success rate of = both UDP and TCP in ideal conditions but fails if the conditions are = far from ideal. 4) Opinions vary widely on how much value port = prediction ultimately ours but it's worth noting that most of the widely = deployed software that has good nat traversal does not bother to even = try port prediction. All of this leads to one conclusion, with todays = NATs, UDP has significantly higher success rate than direct TCP or = pinhole management protocols. HOW TO USE UDP? When you want to do a reliable congestion safe protocol between two = clients behind NATs you have three major choice: I will broadly put them in the following classes=20 1) use UDP with a simple congestion / reliability protocol=20 2) tunnel kernel TCP over application controlled UDP tunnel=20 3) do a user land TCP stack in the application and tunnel over UDP=20 I'll get back to #1 in a minute but let me start with #2. This seems = attractive initially but from a software perspective it's a non-starter. = The problem is that in order to get access to the IP datagrams or TCP = segments on most operating systems you need to be in the kernel (either = directly or as a kernel module). RELOAD is an application expected to be = installed and run by users possibly without super user privileges. = Historically, enterprise IT folks have quite bit wary about allowing = users to install VPN clients, which have similar issues but are much = easier to explain. [And don't get me started on the potential interaction between RELOAD and a VPN client.] IMO, asking = people to install kernel-level software to run a softphone is a = nonstarter. This leaves us with the second natural alternative, userland TCP. It's = true that you can readily find ports of kernel TCP stacks, but all the = ones I know of seem to be experimental or research projects.=20 I'm not aware of anyone that has a rock solid version of such a stack, = let alone one that's widely used. I'm also very hesitant on the long = term implications of doing this. It very obvious that one could change a = TCP stack in trivial ways to give the user far more than their "fair" = share of the network, and right now that's mostly prevented by the major = OS developers (Microsoft, Apple, the Linux Kernel folks, = Google^H^H^H^H^H doing the right thing.) Once we get into an = environment where we're encouraging everyone to develop their own TCP = stack the threat of misbehavior (including misbehavior due to misguided = "optimizations") becomes much greater. So, while a user land TCP stack = might be fine in theory, we have been discussing this since something = like 2002 and we still don't have an example in practice that work well = and is widely usable. Having worked with phones that had bugs in the TCP = stack that had been fixed in all mainstream TCP stacks 15 years = previously, I'm really not a fan of yet more poorly supported, tested, = and written ports of of the BSD TCP stack. I can certainly imagine that = someone could do a great job of this and prove me wrong - and I'd change = my opinion at that point - but I've been waiting many years for this and = no sign of solution yet.=20 This gets us back to number #1 - writing something that is congestion = safe and reliable is actually very easy and we do all the time in a wide = range of IETF protocols. The catch is that is has no where near the = performance of TCP. If you need TCP grade performance as well as safe = and reliable, well that is hard. Luckily RELOAD did not need high = throughput efficiency in the slightest so this was not a big deal. The decision we made for RELOAD simplest thing that looked like it would = work and leave extensibility points to put in something better. So there = is a minimal algorithm required to run over UDP with negotiation that = would allow insertion of much more complex algorithm, such as full blown = user land TCP, in the future. To facilitate only one side needing to = upgrade to get a better algorithm, the receiver reports back packet loss = to the sender that would allow the sender to implement very advanced = protocols. This may have been a bit more than needed but it was easy to = implement and left a lot of flexibility for future. The design has been = cleared with TSV, so we can at least have confidence it's safe. Obviously, this isn't ideal and if the software environment were = different, I suspect we would have made different choices, but IMO this = is the best that can be done at this time. Sorry for the long post of this but I wanted people here to be aware of = what RELOAD does and why it got to that design.=20 Cullen From kpfleming@digium.com Tue Dec 7 13:53:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0283A69B1 for ; Tue, 7 Dec 2010 13:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKWm7vhIxI00 for ; Tue, 7 Dec 2010 13:53:36 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 3762A3A6893 for ; Tue, 7 Dec 2010 13:53:36 -0800 (PST) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1PQ5V0-00070R-66 for dispatch@ietf.org; Tue, 07 Dec 2010 15:55:02 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 2A1F2D8193 for ; Tue, 7 Dec 2010 15:55:02 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9j1LgN1Q+abF for ; Tue, 7 Dec 2010 15:55:01 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id D021FD8192 for ; Tue, 7 Dec 2010 15:55:01 -0600 (CST) Message-ID: <4CFEAD35.6070603@digium.com> Date: Tue, 07 Dec 2010 15:55:01 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: dispatch@ietf.org References: <5223063B-E865-476C-9B52-7BA375F44BDF@cisco.com> In-Reply-To: <5223063B-E865-476C-9B52-7BA375F44BDF@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] RELOAD and UDP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 21:53:37 -0000 On 12/07/2010 03:02 PM, Cullen Jennings wrote: > Obviously, this isn't ideal and if the software environment were different, I suspect we would have made different choices, but IMO this is the best that can be done at this time. > > Sorry for the long post of this but I wanted people here to be aware of what RELOAD does and why it got to that design. > > Cullen (wearing my rose colored glasses) If the 'environment being different' includes reasonably wide deployment of IPv6, and reduced need for NAT devices in the path in order to provide adequate addressing space, would that mean that RELOAD could have an option to operate over existing TCP-on-IPv6 stacks? Are the issues with being able to open end-to-end connections caused by the NAT devices doing address mapping, or by their firewall-like functionality, or both? I would think that the problems are primarily caused by the address mapping... and a network that had reduced need for address translation, along with pinhole management, could quite easily support end-to-end TCP connection establishment. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From eckelcu@cisco.com Fri Dec 10 09:34:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3137B28C0EE for ; Fri, 10 Dec 2010 09:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.13 X-Spam-Level: X-Spam-Status: No, score=-10.13 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mab6QifNonSj for ; Fri, 10 Dec 2010 09:34:35 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C36FB28C0D6 for ; Fri, 10 Dec 2010 09:34:34 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAv0AU2rR7Hu/2dsb2JhbACkBHikOpsthUoEhGSJLw X-IronPort-AV: E=Sophos;i="4.59,325,1288569600"; d="scan'208";a="634025776" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 10 Dec 2010 17:36:06 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oBAHa6bS024046; Fri, 10 Dec 2010 17:36:06 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Dec 2010 09:36:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Dec 2010 09:36:06 -0800 Message-ID: In-Reply-To: <4CFEAD35.6070603@digium.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] RELOAD and UDP Thread-Index: AcuWWWn5shdi2LXJQNqZD+lZ1LdRdQCNS2MQ References: <5223063B-E865-476C-9B52-7BA375F44BDF@cisco.com> <4CFEAD35.6070603@digium.com> From: "Charles Eckel (eckelcu)" To: "Kevin P. Fleming" , X-OriginalArrivalTime: 10 Dec 2010 17:36:06.0635 (UTC) FILETIME=[B9936BB0:01CB9890] Subject: Re: [dispatch] RELOAD and UDP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 17:34:37 -0000 This discussion of support for end-to-end TCP connection establishment through firewalls/SBCs came up in the DISPATCH meeting at IETF 79. While at least one vendor supports this, most do not, so it does not appear to be trivial for implementations in general. As another data point, support for a new application media line in SDP for far end camera control (RFC 4573) is an example of the type of change that appeared to be quite straightforward for support through firewalls/SBCs. Cheers, Charles > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Kevin P. Fleming > Sent: Tuesday, December 07, 2010 1:55 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] RELOAD and UDP >=20 > On 12/07/2010 03:02 PM, Cullen Jennings wrote: >=20 > > Obviously, this isn't ideal and if the software environment were different, I suspect we would have > made different choices, but IMO this is the best that can be done at this time. > > > > Sorry for the long post of this but I wanted people here to be aware of what RELOAD does and why it > got to that design. > > > > Cullen >=20 > (wearing my rose colored glasses) >=20 > If the 'environment being different' includes reasonably wide deployment > of IPv6, and reduced need for NAT devices in the path in order to > provide adequate addressing space, would that mean that RELOAD could > have an option to operate over existing TCP-on-IPv6 stacks? Are the > issues with being able to open end-to-end connections caused by the NAT > devices doing address mapping, or by their firewall-like functionality, > or both? I would think that the problems are primarily caused by the > address mapping... and a network that had reduced need for address > translation, along with pinhole management, could quite easily support > end-to-end TCP connection establishment. >=20 > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kfleming@digium.com > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From peter.musgrave@magorcorp.com Sat Dec 11 13:34:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B57D93A6D46 for ; Sat, 11 Dec 2010 13:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.326 X-Spam-Level: X-Spam-Status: No, score=-103.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6W59E3Sb1MZ for ; Sat, 11 Dec 2010 13:34:45 -0800 (PST) Received: from mail-iw0-f170.google.com (mail-iw0-f170.google.com [209.85.214.170]) by core3.amsl.com (Postfix) with ESMTP id D1EFA3A6D3E for ; Sat, 11 Dec 2010 13:34:42 -0800 (PST) Received: by iwn6 with SMTP id 6so7268378iwn.15 for ; Sat, 11 Dec 2010 13:36:16 -0800 (PST) Received: by 10.42.229.133 with SMTP id ji5mr1564793icb.477.1292103376576; Sat, 11 Dec 2010 13:36:16 -0800 (PST) Received: from [192.168.1.106] ([204.237.32.134]) by mx.google.com with ESMTPS id gy41sm4193585ibb.5.2010.12.11.13.36.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 11 Dec 2010 13:36:15 -0800 (PST) From: Peter Musgrave Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 11 Dec 2010 16:36:12 -0500 Message-Id: To: "dispatch@ietf.org list" , "Allyn Romanow (allyn)" Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: Re: [dispatch] draft-romanow-dispatch-telepresence-use-cases-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 21:34:46 -0000 Hi Allyn,=20 I was re-reading this and thought of a couple of additions I think might = be useful.=20 In section 4.2 - asymmetric, the discussion focuses on 3d3c (three = display, 3 camera) to 1d1c.=20 I think that it would be useful to consider 3p3c to 2p2c - since this = brings up some interesting decisions which do not occur otherwise.=20 e.g If room 1 had cameras A, B, C (l to r) and room 2 has displays D and = E (l to r) there are now issues about maintaining gaze angle in the = views from room A when rendering on D and E which do not occur in the = 3d3c-1d1c example...=20 Also, in the section 4.3 about multipoint, there are alternatives to a = classic, central MCU: 1) An endpoint may elect to act as an MCU and allow a 2-party call to = grow to include a third party. In this case the mixing point has it's = own content it wishes to inject/select. (We may decide this is best = though of as an independent MCU - although it may have impact on the = signalling if a call which started as a point-to-point suddenly becomes = point-to-MCU).=20 2) Three endpoints may elect to make a mesh of calls (each calls the = other) - so each endpoint maintains two active calls and no MCU is = present.=20 Regards,=20 Peter Musgrave From fluffy@cisco.com Sun Dec 12 09:14:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B36C3A6CBC for ; Sun, 12 Dec 2010 09:14:07 -0800 (PST) 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.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijOya2GQgnBq for ; Sun, 12 Dec 2010 09:14:06 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B0B793A6CB2 for ; Sun, 12 Dec 2010 09:14:06 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJiSBE2rR7Ht/2dsb2JhbACkD3ikbZoVhUoEhGSGFYMU X-IronPort-AV: E=Sophos;i="4.59,333,1288569600"; d="scan'208";a="634908871" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 12 Dec 2010 17:15:42 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oBCHFf4n029176; Sun, 12 Dec 2010 17:15:41 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Sun, 12 Dec 2010 10:16:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2BF27697-6828-4721-BC21-199B438820D5@cisco.com> References: <20101025214502.6B3243A68D3@core3.amsl.com> <4CD265E4.3080902@ericsson.com> <47588734-1CDE-42BC-95C2-7E05688577BC@acmepacket.com> <4CD409EE.5010104@tandberg.com> <4CD418BB.7070803@tandberg.com> <4CD52362.8000504@nostrum.com> <4CD6B9DB.2030105@tandberg.com> <0F3DC6F1-D108-4F45-A32B-C95DDEEBD14E@acmepacket.com> To: "Elwell, John" X-Mailer: Apple Mail (2.1082) Cc: DISPATCH list , Tom Kristensen , Hadriel Kaplan , Tom Kristensen Subject: Re: [dispatch] I-D Action:draft-sandbakken-dispatch-bfcp-udp-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 17:14:07 -0000 On Nov 7, 2010, at 9:55 PM, Elwell, John wrote: > That solution needs to be compatible with as many existing middleboxes = as possible. I would like to add that B2BUA based SBC are our one type of middlebox = that this needs to traverse but classic enterprise firewalls with SIP = ALGs are another type of middlebox this needs to work with. Many call = flows for this may end of traversing both.=20 From fluffy@cisco.com Sun Dec 12 09:28:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5960F3A6CBC for ; Sun, 12 Dec 2010 09:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.266 X-Spam-Level: X-Spam-Status: No, score=-110.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUSPnOSQq1wA for ; Sun, 12 Dec 2010 09:28:40 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id AD5783A6B55 for ; Sun, 12 Dec 2010 09:28:40 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN+VBE2rR7Hu/2dsb2JhbACkD3ikZ5oVhUoEhGSGFYMU X-IronPort-AV: E=Sophos;i="4.59,333,1288569600"; d="scan'208";a="301130769" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 12 Dec 2010 17:30:16 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oBCHUEgE019653; Sun, 12 Dec 2010 17:30:15 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4CFEAD35.6070603@digium.com> Date: Sun, 12 Dec 2010 10:31:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6DF23173-800E-4F3E-BD97-56C3F00A7C18@cisco.com> References: <5223063B-E865-476C-9B52-7BA375F44BDF@cisco.com> <4CFEAD35.6070603@digium.com> To: "Kevin P. Fleming" X-Mailer: Apple Mail (2.1082) Cc: dispatch@ietf.org Subject: Re: [dispatch] RELOAD and UDP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 17:28:42 -0000 On Dec 7, 2010, at 2:55 PM, Kevin P. Fleming wrote: > On 12/07/2010 03:02 PM, Cullen Jennings wrote: >=20 >> Obviously, this isn't ideal and if the software environment were = different, I suspect we would have made different choices, but IMO this = is the best that can be done at this time. >>=20 >> Sorry for the long post of this but I wanted people here to be aware = of what RELOAD does and why it got to that design. >>=20 >> Cullen >=20 > (wearing my rose colored glasses) >=20 > If the 'environment being different' includes reasonably wide = deployment of IPv6, and reduced need for NAT devices in the path in = order to provide adequate addressing space, would that mean that RELOAD = could have an option to operate over existing TCP-on-IPv6 stacks? Sure - if there were less NATs and firewalls. I will note that every = major NAT vendors seems to be working on multiple variants of NAT for v6 = and several IETF WG are working on v6 transition strategies that have = many of the properties of a NAT.=20 > Are the issues with being able to open end-to-end connections caused = by the NAT devices doing address mapping, or by their firewall-like = functionality, or both? Both - even with no NATS, you need to be able to tell the FW to open a = pinhole. And the mapping issues makes it much harder to know the = address/port to make the pinhole go to. > I would think that the problems are primarily caused by the address = mapping... and a network that had reduced need for address translation, = along with pinhole management, could quite easily support end-to-end TCP = connection establishment. I somewhat agree with you - I wish the the network was moving towards = what you describe but I doubt that will happen any time real soon. One = of the key points you said was a pinhole management. Many good solutions = to this class of problem would involved the client behind a firewall = being able to tell the firewall to open a specific pinhole. However this = is extremely unlikely to fly in many cases because of the complexity of = creating a trust relationship between the client and the firewall that = makes the firewall administrator willing to allow the client to install = new firewall rules. Note that an unauthenticated outgoing packet being = used to create a pinhole may be good enough for many NAT scenarios but = many firewall scenarios don't consider this strong enough. Furthermore, = even discovering the many firewalls that a given flow goes through is a = challenging problem.=20 Now if only I had a PBX where NAT/FW traversal was a key part of the = signaling protocol design :-) >=20 > --=20 > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kfleming@digium.com > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From jose_javier.garcia_aranda@alcatel-lucent.com Mon Dec 13 07:42:40 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6050528C11A for ; Mon, 13 Dec 2010 07:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.639 X-Spam-Level: X-Spam-Status: No, score=-5.639 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjfV4lUmXV6q for ; Mon, 13 Dec 2010 07:42:39 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 10F1028C118 for ; Mon, 13 Dec 2010 07:42:37 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oBDFTdTx021574 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Dec 2010 16:40:07 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 13 Dec 2010 16:39:17 +0100 From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: "'dispatch@ietf.org'" Date: Mon, 13 Dec 2010 16:39:16 +0100 Thread-Topic: Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 Thread-Index: Acua2+Zh7MnSXkrBTDCCLW4Qulzv6Q== Message-ID: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3349FECF788C984BB34176D70A51782F18374A47FRMRSSXCHMBSB3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 X-Mailman-Approved-At: Mon, 13 Dec 2010 07:53:57 -0800 Cc: "pedrochas@dit.upm.es" , "CUBILLO PASTOR, CLARA \(CLARA\)" , "ORTIGA HERRERA, GUADALUPE \(GUADALUPE\)" , "jquemada@dit.upm.es" , "HERRANZ PABLO, SONIA \(SONIA\)" , "gabriel@dit.upm.es" , "barcenilla@dit.upm.es" , "jsr@dit.upm.es" , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" Subject: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 15:42:40 -0000 --_000_3349FECF788C984BB34176D70A51782F18374A47FRMRSSXCHMBSB3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everybody, Here is the charter proposal for Q4S ( Quality for service) WG. This WG wil= l include the achieved works with "Q-HTTP" Thanks for your comments Description of Working group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Problem Statement: The QoS over Internet is a hot issue today. Current QoS handling mechanisms used in modern network transport layers (MPLS, RSVP, Diffserv,Traffic Engineering) do not provide themselves a QoS-on-demand end-to-end solution and existing adaptative solutions based on In-band Control protocols (such as RTCP) are very difficult to combine with any other protocols for which they have not been designed for. Four Network Parameters comprises the QoS at application level: Bandwidth, packet-loss, latency and Jitter. Interactive-video applications define flows in both directions. Different applications require different constraints (in terms of latency, jitter, packet loss) in one or both directions and different responsiveness. The proposed solution must be an effective out-of-band application level protocol capable of reacting when any of these constraints are violated. Such protocol must trigger adaptive solutions and/or QoS network profile changes. Currently content providers are only able to provide services based on adaptative methods or last-mille deployments which prefer dedicated network resources (vs. Internet), and therefore, restricts the subscriber population and increases the costs. Objetives: The goal of this working group is to define a QoS application-level standard protocol optimized for its use over the internet that may be widely implemented and easily managed by application developers and service providers. The core technical considerations for such protocol include, but are not necessarily limited to, the following: 1. Protocol design to be used in interactive applications (including virtualized videogames,and interative-video applications) 2. Ensuring interoperability with all existing transport protocols 3. Optimizing for low bit rates (typlically below 2.4 kbps) 4. To ensure a feasible practical implementation based on policy servers and interoperability between service providers Deliverables: 1. Specification of protocol that meets the requirements in the form of an Internet-Draft that defines the negotiation of QoS parameters, the measurement process and alert mechanisms. 2. Dimensioning rules and performance analysis 3. A set of technical requirements for a practical implementation which may include adaptative solutions and/or QoS profile modification. Goals and Milestiones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nov 2010 Submit Internet-Draft as a proposed standard for QoS application-level protocol Proposed charter for Q4S WG Informational document with rules for dimensioning and performance analysis Specification of architecture document for implementation - Jose Javier --_000_3349FECF788C984BB34176D70A51782F18374A47FRMRSSXCHMBSB3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi everybody,
 
Here is the charter proposal for Q4S ( Quality for se= rvice) WG. This WG will include the achieved works with  "Q-HTTP&= quot;
 
Thanks for your comments
 
 
Description of Workin= g group
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
   Problem = Statement:
 
   The QoS = over Internet is a hot issue today. Current QoS handling
   mechanis= ms used in  modern network transport layers (MPLS, RSVP,
   Diffserv= ,Traffic Engineering) do not provide  themselves a
   QoS-on-d= emand end-to-end solution and existing adaptative
   solution= s based on In-band Control protocols (such as RTCP)
   are very= difficult to combine with any other protocols for which
   they hav= e not been designed for.
 
   Four Net= work Parameters comprises the QoS at application level:
   Bandwidt= h, packet-loss, latency and Jitter.
 
   Interact= ive-video applications define flows in both directions.
   Differen= t applications require different constraints (in terms of
   latency,= jitter, packet loss) in one or both directions and
   differen= t responsiveness. The proposed solution must be an
   effectiv= e out-of-band application level protocol capable of
   reacting= when any of these constraints are violated. Such protocol
   must tri= gger adaptive solutions and/or QoS network profile changes.
 
   Currentl= y content providers are only able to provide services based
   on adapt= ative methods or last-mille deployments which prefer
   dedicate= d network resources (vs. Internet), and therefore, restricts
   the subs= criber population and increases the costs.
 
   Objetive= s:
 
   The goal= of this working group is to define a
   QoS appl= ication-level  standard protocol optimized for its use over
   the inte= rnet that may be widely implemented and easily managed
   by appli= cation developers and service providers.
 
   The core= technical considerations for such protocol include, but
   are not = necessarily limited to, the following:
 
   1. Proto= col design to be used in interactive applications (including
   &nb= sp;  virtualized videogames,and interative-video applications)<= /div>
 
   2. Ensur= ing interoperability with all existing transport protocols
 
   3. Optim= izing for low bit rates (typlically below 2.4 kbps)
 
   4. To en= sure a feasible practical implementation based on
   &nb= sp;  policy servers and interoperability between service providers
 
 
   Delivera= bles:
 
   1. Speci= fication of protocol that meets the requirements in the
   &nb= sp;  form of an Internet-Draft that defines the negotiation of QoS
   &nb= sp;  parameters, the measurement process and alert mechanisms.<= /div>
 
   2. Dimen= sioning rules and performance analysis
 
   3. A set= of technical requirements for a practical
   &nb= sp;  implementation which may include adaptative solutions and/or
   &nb= sp;  QoS profile modification.
 
 
Goals and Milestiones=
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Nov 2010  =   Submit Internet-Draft as a proposed standard for QoS
   &nb= sp;         application-level proto= col
 
   &nb= sp;         Proposed charter for Q4= S WG
 
   &nb= sp;         Informational document = with rules for dimensioning
   &nb= sp;         and performance analysi= s
 
   &nb= sp;         Specification of archit= ecture document for implementation
 
 
 
 
 
 
- Jose Javier
 
 
 
 
 --_000_3349FECF788C984BB34176D70A51782F18374A47FRMRSSXCHMBSB3d_-- From dworley@avaya.com Mon Dec 13 14:09:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35AF43A6D3F; Mon, 13 Dec 2010 14:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.881 X-Spam-Level: X-Spam-Status: No, score=-101.881 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vn3x2RyrlMY; Mon, 13 Dec 2010 14:09:22 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 046563A6D38; Mon, 13 Dec 2010 14:09:21 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOIoBk3GmAcF/2dsb2JhbACkDHipZQKZN4VKBIRkiUM X-IronPort-AV: E=Sophos;i="4.59,338,1288584000"; d="scan'208";a="254762552" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 Dec 2010 17:11:00 -0500 X-IronPort-AV: E=Sophos;i="4.59,338,1288584000"; d="scan'208";a="555117965" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Dec 2010 17:11:00 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 13 Dec 2010 17:10:59 -0500 From: "Worley, Dale R (Dale)" To: "dispatch@ietf.org" , "sip@ietf.org" , Robert Sparks Date: Mon, 13 Dec 2010 17:09:48 -0500 Thread-Topic: Errata report on errata 2602 and 2120 on RFC 5479, "Requirements and Analysis of Media Security Management Protocols" Thread-Index: AQHLmxKfjFhWVeNeIUaIF8W9qFbgyA== Message-ID: 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 Subject: [dispatch] Errata report on errata 2602 and 2120 on RFC 5479, "Requirements and Analysis of Media Security Management Protocols" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 22:09:23 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC5479, "Requirements and Analysis of Media Security Management Protocols" Source of RFC: sip (rai) Errata ID: 2602 Status: Reported Type: Technical Reported By: Fabio Pietrosanti Date Reported: 2010-11-04 Section A.5.2 says: SDP Security Descriptions with SIPS Not applicable; SDP Security Descriptions does not have a long- term secret. It should say: SDP Security Descriptions with SIPS The PFS feature of SDP Security Description with SIPS rely on TLS and the availability or not of PFS for SRTP calls depends on the negotiated TLS key negotiation algorithm. If the selected TLS key negotiation algorithm of SIPS provide PFS feature, then the underlying SRTP encryption will support PFS. For example TLS_DHE_RSA_WITH_AES_256_CBC_SHA provde PFS feature as described in RFC5246. If the selected TLS key negotiation algorithm of SIPS does not provide PFS feature, then the underlying SRTP encryption will not support PFS. For example TLS_RSA_WITH_AES_256_CBC_SHA does not provide PFS feature as described in RFC5246. Notes: It's not true that SDP Security Descriptions with SIPS have PFS "Not applicable" because the SDES rely on TLS that is part of the security scheme. Practically if the long terms keys (the x509v3 RSA key of SIPS server) is compromised, the TLS sessions can be decrypted, the SDES key extracted and SRTP calls deciphered. TLS support key exchange methods that provide PFS trough the use of Ephemeral Diffie Hellman keys. When SIPS use TLS with DHE key negotiation, then SDES acquire PFS feature because even in case of long-term key compromise (the server x509v3 RSA key), the short term keys (the SDES keys exchanged) will be safe. ---------------------------------------------------------------------- Recommended status: (correct) Verified (publish) Should be reviewed by a security expert. It seems that the entry for "SDP Security Descriptions with S/MIME" is also incorrect, as revelation of the private keys of the participants will render the SDES readable. I think better phrasing of the revised wording is: SDP Security Descriptions with SIPS PFS if the selected TLS cipher suites for the SIPS hops provide PF= S. SDP Security Descriptions with S/MIME No PFS. This needs to be reviewed by a security expert. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC5479, "Requirements and Analysis of Media Security Management Protocols" Source of RFC: sip (rai) Errata ID: 2120 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2010-04-05 Section 4.4,3rd para says: | A typical case of using media security where two entities are having a Voice over IP (VoIP) conversation over IP-capable networks. [...] It should say: | A typical case of using media security is where two entities are having a Voice over IP (VoIP) conversation over IP-capable networks. [...] Notes: Rationale: missing verb. ---------------------------------------------------------------------- Recommended status: (correct) Hold for document update =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dale From allyn@cisco.com Mon Dec 13 15:31:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A48C23A6E17 for ; Mon, 13 Dec 2010 15:31:36 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkcW0I9KU31P for ; Mon, 13 Dec 2010 15:31:36 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 07C593A6E13 for ; Mon, 13 Dec 2010 15:31:36 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIM7Bk2rR7Ht/2dsb2JhbACkC3inGJtchUoEhGSJLw X-IronPort-AV: E=Sophos;i="4.59,338,1288569600"; d="scan'208";a="232027079" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 13 Dec 2010 23:33:12 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oBDNX7mv019186; Mon, 13 Dec 2010 23:33:12 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Dec 2010 15:33:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: A9jY BS3o B/6j Flpp GeuL G/Po KLJw KoHZ KzaU L9jD NDHj RGvR UMzm UqZe VcZm WGOJ; 2; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnADsAcABlAHQAZQByAC4AbQB1AHMAZwByAGEAdgBlAEAAbQBhAGcAbwByAGMAbwByAHAALgBjAG8AbQA=; Sosha1_v1; 7; {CEE2E779-4FFE-4E98-9990-D0A4FF089CF4}; YQBsAGwAeQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 13 Dec 2010 23:33:02 GMT; UgBFADoAIABkAHIAYQBmAHQALQByAG8AbQBhAG4AbwB3AC0AZABpAHMAcABhAHQAYwBoAC0AdABlAGwAZQBwAHIAZQBzAGUAbgBjAGUALQB1AHMAZQAtAGMAYQBzAGUAcwAtADAAMQA= x-cr-puzzleid: {CEE2E779-4FFE-4E98-9990-D0A4FF089CF4} Content-class: urn:content-classes:message Date: Mon, 13 Dec 2010 15:33:02 -0800 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0324093D@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-romanow-dispatch-telepresence-use-cases-01 Thread-Index: AcuZe3GFvktP0qlNQI6H5n0ypmR8YQBoXgcw References: From: "Allyn Romanow (allyn)" To: "Peter Musgrave" , X-OriginalArrivalTime: 13 Dec 2010 23:33:09.0811 (UTC) FILETIME=[1A05E830:01CB9B1E] Subject: Re: [dispatch] draft-romanow-dispatch-telepresence-use-cases-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 23:31:36 -0000 Hi Peter, I think this should be on the maitai list, as it's not about charter and I think we decided only charter discussion would go to dispatch.=20 I'll respond on the maitai list, hoping to avoid confusion. Thanks, Allyn From alan.b.johnston@gmail.com Wed Dec 15 09:07:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EADB28C1CB for ; Wed, 15 Dec 2010 09:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.308 X-Spam-Level: X-Spam-Status: No, score=-104.308 tagged_above=-999 required=5 tests=[AWL=1.291, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02HjU0EYuueU for ; Wed, 15 Dec 2010 09:07:35 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id D649428C1D1 for ; Wed, 15 Dec 2010 09:07:34 -0800 (PST) Received: by bwz8 with SMTP id 8so2527652bwz.38 for ; Wed, 15 Dec 2010 09:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=J7gc0ENKb8+wXcvYmKU/F5ld4j1FykLPgtnNuNFPcCM=; b=IhN7z1utdAU3cBr8TSEzZzTmdfCHCgDsGJuP/D+hAVCiyNS3LiN15yUpvw7PlGx1YD GbZPHCszJpkq8GLLqceSxm9aeuuVp5n8TZtjteNMQkDo0N0IF2OYVFkyHkKpMc5P2Z+J VSPOdurY9f8zrgt0IB+OZs/zNsZ/eep5tt6bM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Iw60puRfyMSS9szmJZssXYuMZmVKqTvndZ+eVYiZJtkG2rR67jU5986Nl70wmGADR9 WoPaT3J5QCr1xzDszRZM30iLiUnOkyUa2gkHNzMq96cQD7MaQopZRlb1ia+2VPPpc2Pm c5zGqpkc43KqjVuHSaIMn9a+vn9BNgu7UKVnY= MIME-Version: 1.0 Received: by 10.204.81.7 with SMTP id v7mr3780428bkk.129.1292432956883; Wed, 15 Dec 2010 09:09:16 -0800 (PST) Received: by 10.204.232.15 with HTTP; Wed, 15 Dec 2010 09:09:16 -0800 (PST) In-Reply-To: <4CDA833D.8080203@alvestrand.no> References: <4CDA833D.8080203@alvestrand.no> Date: Wed, 15 Dec 2010 11:09:16 -0600 Message-ID: From: Alan Johnston To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 17:07:36 -0000 Harald, Thanks for kicking off this work with your drafts. =A0I know a lot of us are greatly looking forward to starting this work after thinking and talking about it for a long time. My thinking is basically aligned with your draft. =A0However, I think we need a little more clarity on exactly what we are trying to do: exactly how do all the components talk to you each other using standard protocols or APIs? =A0I found your datagram session URI proposal in the other draft a little hard to understand - I think we will need good requirements before we can decide if this is the right mechanism. I also understand your arguments on connection management, which is really signaling. =A0I agree that it is possible for this to be a local matter between a web browser and a web server, and that establishing voice sessions from within a web domain can be handled without standards, and voice sessions between web domains could be signaled using existing standards such as SIP. However, I do think there is value in standardizing some kind of lightweight API for signaling between the browser and server. =A0 Some of us have been thinking about this for a while now: =A0=A0 =A0=A0http://tools.ietf.org/html//draft-sinnreich-sip-web-apis =A0=A0 =A0=A0http://tools.ietf.org/html/draft-peterson-sipcore-advprop The good news is that this work is completely orthogonal to the mainly media work you propose in your draft. But it does tie in nicely and helps provide a fully interoperable set of protocols/APIs, which ultimately is what the IETF is all about. =A0 I don't see any need for one effort to delay the other - in fact, both could potentially be done in separate working groups. Finally, a comment on the name for the overall effort - I know, really important stuff... =A0The acronym RTC has baggage in our industry, and it might be nice avoid yet another three letter acronym ;-). =A0I was thinking about Web RTCom, short for Web Real Time Communications. - Alan - On Wed, Nov 10, 2010 at 5:34 AM, Harald Alvestrand w= rote: > > This is the overview document for the IETF-related RTC-WEB work. > > -------- Original Message -------- > Subject: New Version Notification for draft-alvestrand-dispatch-rtcweb-pr= otocols-00 > Date: Wed, 10 Nov 2010 03:31:05 -0800 (PST) > From: IETF I-D Submission Tool > To: harald@alvestrand.no > > A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt h= as been successfully submitted by Harald Alvestrand and posted to the IETF = repository. > > Filename: draft-alvestrand-dispatch-rtcweb-protocols > Revision: 00 > Title: Overview: Real Time Protocols for Brower-based Applications > Creation_date: 2010-11-11 > WG ID: Independent Submission > Number_of_pages: 9 > > Abstract: > This document gives an overview of a protocol suite intended for use > with real-time applications that can be deployed in browsers - "real > time communication on the Web". > > It intends to serve as a starting and coordination point to make sure > all the parts that are needed to achieve this goal are findable, and > that the parts that belong in the Internet protocol suite are fully > specified and on the right publication track. > > This work is an attempt to synthesize the input of many people, but > makes no claims to fully represent the views of any of them. All > parts of the document should be regarded as open for discussion. > > > > The IETF Secretariat. > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From paulej@packetizer.com Wed Dec 15 13:55:08 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9BB628C106 for ; Wed, 15 Dec 2010 13:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTYR4KpXwmB7 for ; Wed, 15 Dec 2010 13:55:03 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 2C24C28C116 for ; Wed, 15 Dec 2010 13:55:03 -0800 (PST) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id oBFLudET013130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Dec 2010 16:56:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1292450205; bh=lS6IAfdOD80iW0f2R5pzFsLOLGfJzANDCTU9H7dnIVs=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=hwn3ZPc4z+klpCSDM5639zNt8obS2F5cmKMtz+JrTf2n7fhYlDM9cCaEuaFdbYjIS aY03F6e2pqCDC4jXxEuBmmDPpNH5PU+V7iHQNXQHK1wXhBBgQ+NVQOTIn4erQaEYUP d8yhxCTa3bUwq35M/RRj7EhOd5UW1N1tFOWwOPwo= From: "Paul E. Jones" To: "'Worley, Dale R \(Dale\)'" , References: <20101128221502.13473.41922.idtracker@localhost>, <00e401cb8f4a$e28a56e0$a79f04a0$@packetizer.com> In-Reply-To: Date: Wed, 15 Dec 2010 16:56:32 -0500 Message-ID: <04a901cb9ca2$f337b360$d9a71a20$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGceIxBMRvDIaVI6ICKVhI0Ts3JTgH4gdrvAiQU2VGT323qQA== Content-Language: en-us Subject: Re: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 21:55:09 -0000 Dale, I apologize for not seeing your message sooner. All of the points you mention are correct. The important aspect of this approach is, indeed, the fact that we can identify and end-to-end session as the session is manipulated in the network. The question you had was "what do we want to do with it?" There are a variety of things we would like to do with this, including associating SIP signaling with media flows, billing logs, troubleshooting, etc. It's true that the final end-to-end session ID is not signaled as a single signaling element, but each half is in the signaling going in each direction. We might have challenges getting B2BUAs to pass it through, but I'm not sure what to suggest, except that we work that out as a group. It could be signaled as we have it written in the draft now, or via its own header. Paul > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Worley, Dale R (Dale) > Sent: Tuesday, December 07, 2010 2:10 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id- > 00.txt > > This draft is intriguing... In concept, it identifies something that we > understand but have not named, the "end of a session", what is usually > considered a call instance on a phone. E.g., when phone B transfers > caller A to talk to C, the "end of the session" at A does not change, > despite that the A-B dialog has been replaced by the A-C dialog. > Indeed, the fact that we say one dialog "replaces" another at A means > that the "end of the session" at A has not changed. The draft proposes > that UAs coin UUIDs to label each end of a session that they create. > Conference servers are a special case, in that each conference focus > uses one end of a session UUID for all of the legs of the conference. > > The draft proposes that each UA, in any INVITE, sends the end-of-the- > session UUID at its end. > > The draft proposes that each UA, when it learns the end-of-the-session > UUID of the other end of a dialog, should combine that with its own end- > of-the-session UUID to generate a "Session Identifier". > > But there seem to be no places where the Session Identifier becomes > manifest in the protocol. So I'm not sure what its purpose is. > > But getting back to the end-of-the-session UUID, that seems like it > could be useful for troubleshooting, etc. It's a close kin to the > "References" header proposal, in that it gives a way to show within the > signaling that two dialogs are associated. > > It seems to have the same difficulties as Hadriel's session-id when it > comes to having B2BUAs pass it through. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From henry.sinnreich@gmail.com Thu Dec 16 12:45:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5722C3A69C7 for ; Thu, 16 Dec 2010 12:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=-0.731, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOiotKk-o0Vi for ; Thu, 16 Dec 2010 12:45:26 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 1A11D3A6953 for ; Thu, 16 Dec 2010 12:45:26 -0800 (PST) Received: by gyd12 with SMTP id 12so1987702gyd.31 for ; Thu, 16 Dec 2010 12:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:mime-version :content-type; bh=Lz1HM0UZdj8OY2lH4Q7XNzEIHi1c721zqqt2+L1yPQs=; b=st3KJDQ05In/U9eHMug2iU/luG4R7ylotj+YKEeAmtBx2w/FB58OPIoTcsy+KWtqfM TEu6FlEiuUZU8HTEu5jtMGr3lDm/jww5tQheTGShtgaN34vTA6xXy0Fku1fJwg2RtizC Ynlo/xk/UZEdmGGlb19tWWLKGei9ZSEOAc6dI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:mime-version:content-type; b=tDUixmkkU2IPNEqoobUxNJ6761QxTJTvp3CFkvXDs0Gz3nDw0UjjgHnM0adsZvI9Ep 8qJkEhbj1b0mmcCUff2qf3ZRPHdsyWVVqDbpG2pxFprsiZG9OAW8Y3KnECYTzESvt2jB FvARzWfO8aWhiVC2TOAdGiMeqiN/KXVY7vVlk= Received: by 10.146.83.8 with SMTP id g8mr416260yab.11.1292532430956; Thu, 16 Dec 2010 12:47:10 -0800 (PST) Received: from [10.0.1.7] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id b26sm3265532anb.13.2010.12.16.12.47.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Dec 2010 12:47:09 -0800 (PST) User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Thu, 16 Dec 2010 14:47:07 -0600 From: Henry Sinnreich To: Message-ID: Thread-Topic: A Datagram Transport for the RTC-Web profile Thread-Index: AcudYmb2aZv2wi8pwUKnVnp5w7jemQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3375355629_1185183" Cc: Lars Eggert Subject: [dispatch] A Datagram Transport for the RTC-Web profile X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 20:45:38 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3375355629_1185183 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Harald, =20 I would like to add my thanks to Alan Johnston=B9s note, this time to your other I-D, [I-D: draft-alvestrand-dispatch-rtcweb-datagram-00] since is a timely and welcome contribution to what may well turn out to become the mos= t exciting development in VoIP: Opening such as SIP VoIP up from its separate applications environment, Internet or telecom, into the mainstream world of applications, into the browser. =20 Given the transformative potential we believe this has, maybe a contrarian view to the solutions presented here is timely right now. The Internet industry will produce solutions one way or another and the challenge in our IETF work here is to develop a standard that is most attractive to implementers. This is the focus in the message. =20 There is an obvious need to present, discuss and research various options before developing any standard document. So here are some comments when adopting a contrarian view. This is certainly not a complete list nor does everything tie yet neatly together =AD the reason why we propose this work to be an IRTF (http://www.irtf.org/) work item. =20 Last but not least, as per your model, we discuss here only media transport between browsers or between a browser and a possible RTC server, such as a conference server. All issues of control, such as rendezvous, session setup= , etc. are out of scope. These topics are addressed elsewhere. =20 Missing items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 In sections 1.Introduction and 2.Terminology, the key distinction must be added between streaming audio/video (a/v) media and interactive real-time (RT) media for communications and other, such as games, to which the title RTC is pointing. =20 =B3When transporting audio / video data between participants on the current Internet, there are a number of obstacles to be faced.=B2 Well, there is also really good news to be added: Content Distribution Networks (CDN) support highest quality HDTV streaming to many millions of users. CDN share something with the Internet: CDN are a general purpose global platform that while keeping to basic HTTP protocol support enables a= n endless stream of innovations that require no network upgrades for new Web applications. CDN are also scalable Internet style. See below how CDN could also serve as relays for RT media. =20 Another missing item seems to be any emphasis on the handling of media for P2P RTC in the browser, arguably the ultimate communication solution for many reasons, such as lowest cost of ownership, instant scalability for pea= k traffic events. Would not P2P media run inside a VPN-like network over HIP, as discussed below make a most attractive option? =20 Last but not least, actually the most important for tens of millions of Web app developers is the complete integration with all and any web application= s and integration into web development tools, such as graphic Integrated Development Environments (IDE). How can the required protocol expertise on media, as required here be best hidden from app developers, so they are not discouraged from using it? =20 Unnecessary Complexity: Are there better options? Which? =20 The Datagram Model that is presented in section 3.Service model. Being an assembly of very complex constructs to be found in recent IETF documents, arguably weighs down the Service model. This contradicts the golden design rule that engineering is finished only when it can be made no simpler and n= o more.=20 We also miss here a discussion of design options and the criteria for picking any particular choice. Discussing such options in detail are key to choosing and defending an approach for RT Web communications. =20 =20 Alternate options for RT Web media =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Missing the option of using just UDP and application level scheduling without any other protocols. My understanding is that Skype for example has proven such an approach for interactive a/v. Skype does not use RTP. Neithe= r do Apple TV, Flash video and others for streaming media. =20 Another approach, also well proven for CDN is streaming HTTP. Bidirectional HTTP and Streaming HTTP is the object of present IETF work and it would mak= e sense to benefit from it. =20 Sample scenarios for using HTTP for media transport in RTC: =20 =B7 Users are inside a single ISP, within a small geographical area and the nearest CDN HTTP proxy serves as the media relay. A suitable a/v codec packetization and sequencing from the end point browser based apps can easily meet the required delay, such as less than 150 ms end-to-end. The CD= N HTTP proxy has to be instructed not to cache this stream and is used =8Cas is=B9. =20 =B7 Some users are geographically remote and in different ISPs. In this case, the CDN owned fiber backbones might prove to be an alternative to the congestion experienced from peering and backhaul. Here too the huge CDN infrastructure is used =8Cas is=B9. =20 Alternate Options for NAT traversal =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Instead of using ICE as in RFC 5245 that is described specifically for SIP, why not using ICE as specified 5750 for HIP since it has the following benefits: =20 =B7 ICE for HIP works for all application layer protocols and has all th= e benefit of a generic solution =B7 HIP supports also IPv6 transition, mobility and multi-homing =B7 HIP provides VPN-like security for both media and control, thus meeting the criteria for simplicity in our contrarian approach. =20 Things to disagree with =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 The URI schema for datagram channels contradicts both the Internet and Web architectural principles: =20 1. Registration of URIs contradict the loose coupling and scalability of the Web architecture (reference) 2. The URI registration template uses IP addresses. This contradicts the IAB UNSAF RFC 3424 and is also one of the main weaknesses of SDP in SIP, since the IP addresses are not information, but rather disinformation; many intermediaries along the path will change them unfortunately. By contrast, HIP works end-to-end like the User Space VPN and is better positioned to handle this. The are no intermediaries inside the VPN-like network established over HIP. 3. Why not enjoy also the flexibility not to use only DNS names for the media description, but rather P2P names, such as in Skype? Caution, we may open here a can of worms, but this is important as well. It must be IMO als= o part of discussing the design options. =20 Missing sections: Discussion and Conclusions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 The key item to discuss is if the approach in this draft meets the basic engineering criteria: The design is the simplest possible and nothing remains to be taken away to make it simpler and no more. =20 My conclusion is the I-D is a welcome start of work on RT interactive communications on the web, but the approach presented, though formally compliant with the most recent IETF application area standards work may not be the most simple. Therefore it may not be the most successful in the market. =20 Recommendations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 The discussions of other options, such as the examples recommended here require detailed discussions, prototyping and testing before adopting anything resembling a standard proposal. For this reason we suggest the RTC Web work should continue within the Internet Research Task Force (IRTF) and I have taken the liberty to copy the IRTF Chair Lars Eggert for this purpose. Possible work items include: =20 =B7 What is the complexity, for example measured in the number of messages and protocol support required in the present RTC Web I-D as is? =B7 List and comparison of alternatives? (Such as using CDN, HIP and P2P= ) =B7 Would a SIP API standard and RTC Web constitute a complete solution? If not, what is missing? =B7 Scenarios and business models. Who pays the CDN for RTC? Business innovation is impossible to predict, but must be enabled by providing the tools and flexibility inherent in the Darwinian Web to the genius of application developers. =B7 Prototypes and test reports. =20 It can be argued that sending this work to the IRTF will introduce a delay, but as mentioned, the Internet industry will produce solutions one way or another and the challenge in the IETF work here is to develop a standard that is most attractive to app developers and to implementers. See also =B3What Makes for a Successful Protocol=B2, RFC 5218. =20 Thanks, Henry =20 =20 =20 =20 =20 --B_3375355629_1185183 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable A Datagram Transport for the RTC-Web profile Hi Harald,
 
I would like to add my thanks to Alan Johnston’s note, this time to y= our other I-D, [I-D: draft-alvestrand-dispatch-rtcweb-datagram-00] since is = a timely and welcome contribution to what may well turn out to become the mo= st exciting development in VoIP: Opening such as SIP VoIP up from its separa= te applications environment, Internet or telecom, into the mainstream world = of applications, into the browser.
 
Given the transformative potential we believe this has, maybe a contrarian = view to the solutions presented here is timely right now. The Internet indus= try will produce solutions one way or another and the challenge in our IETF = work here is to develop a standard that is most attractive to implementers. = This is the focus in the message.
 
There is an obvious need to present, discuss and research various options b= efore developing any standard document. So here are some comments when adopt= ing a contrarian view. This is certainly not a complete list nor does everyt= hing tie yet neatly together – the reason why we propose this work to = be an IRTF (http://www.irtf.org/) work it= em.
 
Last but not least, as per your model, we discuss here only media transport= between browsers or between a browser and a possible RTC server, such as a = conference server. All issues of control, such as rendezvous, session setup,= etc. are out of scope. These topics are addressed elsewhere.
 
Missing items
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
In sections 1.Introduction and 2.Terminology, the key distinction must be a= dded between streaming audio/video (a/v) media and interactive real-time (RT= ) media for communications and other, such as games, to which the title RTC = is pointing.
 
“When transporting audio / video data between participants on the cur= rent Internet, there are a number of obstacles to be faced.”
Well, there is also really good news to be added: Content Distribution Netw= orks (CDN) support highest quality HDTV streaming to many millions of users.= CDN share something with the Internet: CDN are a general purpose global pla= tform that while keeping to basic HTTP protocol support enables an endless s= tream of innovations that require no network upgrades for new Web applicatio= ns. CDN are also scalable Internet style. See below how CDN could also serve= as relays for RT media.
 
Another missing item seems to be any emphasis on the handling of media for = P2P RTC in the browser, arguably the ultimate communication solution for man= y reasons, such as lowest cost of ownership, instant scalability for peak tr= affic events. Would not P2P media run inside a VPN-like network over HIP, as= discussed below make a most attractive option?
 
Last but not least, actually the most important for tens of millions of Web= app developers is the complete integration with all and any web application= s and integration into web development tools, such as graphic Integrated Dev= elopment Environments (IDE).
How can the required protocol expertise on media, as required here be best = hidden from app developers, so they are not discouraged from using it?
 
Unnecessary Complexity: Are there better options? Which?
 
The Datagram Model that is presented in section 3.Service model. Being an a= ssembly of very complex constructs to be found in recent IETF documents, arg= uably weighs down the Service model. This contradicts the golden design rule= that engineering is finished only when it can be made no simpler and no mor= e.
We also miss here a discussion of design options and the criteria for picki= ng any particular choice. Discussing such options in detail are key to choos= ing and defending an approach for RT Web communications.
 
 
Alternate options for RT Web media
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Missing the option of using just UDP and application level scheduling witho= ut any other protocols. My understanding is that Skype for example has prove= n such an approach for interactive a/v. Skype does not use RTP. Neither do A= pple TV, Flash video and others for streaming media.
 
Another approach, also well proven for CDN is streaming HTTP. Bidirectional= HTTP and Streaming HTTP is the object of present IETF work and it would mak= e sense to benefit from it.
 
Sample scenarios for using HTTP for media transport in RTC:
 
·      Users are inside a single ISP, withi= n a small geographical area and the nearest CDN HTTP proxy serves as the med= ia relay. A suitable a/v codec packetization and sequencing from the end poi= nt browser based apps can easily meet the required delay, such as less than = 150 ms end-to-end. The CDN HTTP proxy has to be instructed not to cache this= stream and is used ‘as is’.
 
·      Some users are geographically remote= and in different ISPs. In this case, the CDN owned fiber backbones might pr= ove to be an alternative to the congestion experienced from peering and back= haul. Here too the huge CDN infrastructure is used ‘as is’.
 
Alternate Options for NAT traversal
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Instead of using ICE as in RFC 5245 that is described specifically for SIP,= why not using ICE as specified 5750 for HIP since it has the following bene= fits:
 
·      ICE for HIP works for all applicatio= n layer protocols and has all the benefit of a generic solution
·      HIP supports also IPv6 transition, m= obility and multi-homing
·      HIP provides VPN-like security for b= oth media and control, thus meeting the criteria for simplicity in our contr= arian approach.
 
Things to disagree with
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
The URI schema for datagram channels contradicts both the Internet and Web = architectural principles:
 
1.  Registration of URIs contradict the loose coupling and scalability= of the Web architecture (reference)
2.  The URI registration template uses IP addresses. This contradicts = the IAB UNSAF RFC 3424 and is also one of the main weaknesses of SDP in SIP,= since the IP addresses are not information, but rather disinformation; many= intermediaries along the path will change them unfortunately. By contrast, = HIP works end-to-end like the User Space VPN and is better positioned to han= dle this. The are no intermediaries inside the VPN-like network established = over HIP.
3.  Why not enjoy also the flexibility not to use only DNS names for t= he media description, but rather P2P names, such as in Skype? Caution, we ma= y open here a can of worms, but this is important as well. It must be IMO al= so part of discussing the design options.
 
Missing sections: Discussion and Conclusions
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
The key item to discuss is if the approach in this draft meets the basic en= gineering criteria: The design is the simplest possible and nothing remains = to be taken away to make it simpler and no more.
 
My conclusion is the I-D is a welcome start of work on RT interactive commu= nications on the web, but the approach presented, though formally compliant = with the most recent IETF application area standards work may not be the mos= t simple. Therefore it may not be the most successful in the market.
 
Recommendations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
The discussions of other options, such as the examples recommended here req= uire detailed discussions, prototyping and testing before adopting anything = resembling a standard proposal. For this reason we suggest the RTC Web work = should continue within the Internet Research Task Force (IRTF) and I have ta= ken the liberty to copy the IRTF Chair Lars Eggert for this purpose. Possibl= e work items include:
 
·      What is the complexity, for example = measured in the number of messages and protocol support required in the pres= ent RTC Web I-D as is?
·      List and comparison of alternatives?= (Such as using CDN, HIP and P2P)
·      Would a SIP API standard and RTC Web= constitute a complete solution? If not, what is missing?
·      Scenarios and business models. Who p= ays the CDN for RTC? Business innovation is impossible to predict, but must = be enabled by providing the tools and flexibility inherent in the Darwinian = Web to the genius of application developers.
·      Prototypes and test reports.
 
It can be argued that sending this work to the IRTF will introduce a delay,= but as mentioned, the Internet industry will produce solutions one way or a= nother and the challenge in the IETF work here is to develop a standard that= is most attractive to app developers and to implementers.
See also “What Makes for a Successful Protocol”, RFC 5218.
 
Thanks, Henry
 
 
 
 
 
 --B_3375355629_1185183-- From jgunn6@csc.com Thu Dec 16 14:24:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1283A6979; Thu, 16 Dec 2010 14:24:07 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoBXVP3rRt3z; Thu, 16 Dec 2010 14:24:05 -0800 (PST) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by core3.amsl.com (Postfix) with ESMTP id 73B943A6915; Thu, 16 Dec 2010 14:24:05 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-3.tower-171.messagelabs.com!1292538349!35709035!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 24649 invoked from network); 16 Dec 2010 22:25:50 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-3.tower-171.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Dec 2010 22:25:50 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id oBGMPmjO009531; Thu, 16 Dec 2010 17:25:48 -0500 In-Reply-To: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> To: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" MIME-Version: 1.0 X-KeepSent: B818205E:091BC16F-852577FB:007ADF83; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Thu, 16 Dec 2010 17:25:51 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.1FP1 HF440|June 18, 2010) at 12/16/2010 05:25:25 PM, Serialize complete at 12/16/2010 05:25:25 PM Content-Type: multipart/alternative; boundary="=_alternative 007B37B3852577FB_=" X-Mailman-Approved-At: Thu, 16 Dec 2010 14:54:50 -0800 Cc: "pedrochas@dit.upm.es" , "'dispatch@ietf.org'" , dispatch-bounces@ietf.org, "ORTIGA HERRERA, GUADALUPE \(GUADALUPE\)" , "jquemada@dit.upm.es" , "CUBILLO PASTOR, CLARA \(CLARA\)" , "gabriel@dit.upm.es" , "barcenilla@dit.upm.es" , "jsr@dit.upm.es" , "HERRANZ PABLO, SONIA \(SONIA\)" , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" Subject: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 22:24:07 -0000 This is a multipart message in MIME format. --=_alternative 007B37B3852577FB_= Content-Type: text/plain; charset="US-ASCII" I am a little bit confused by the combination of 1. Protocol design to be used in interactive applications (including virtualized videogames,and interative-video applications) and 3. Optimizing for low bit rates (typlically below 2.4 kbps) I do not know many video games that work effectively at 2.4 kbps. Am I missing something? Janet From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: "'dispatch@ietf.org'" Cc: "pedrochas@dit.upm.es" , "CUBILLO PASTOR, CLARA \(CLARA\)" , "ORTIGA HERRERA, GUADALUPE \(GUADALUPE\)" , "jquemada@dit.upm.es" , "HERRANZ PABLO, SONIA \(SONIA\)" , "gabriel@dit.upm.es" , "barcenilla@dit.upm.es" , "jsr@dit.upm.es" , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" Date: 12/13/2010 10:56 AM Subject: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 Hi everybody, Here is the charter proposal for Q4S ( Quality for service) WG. This WG will include the achieved works with "Q-HTTP" Thanks for your comments Description of Working group ============================ Problem Statement: The QoS over Internet is a hot issue today. Current QoS handling mechanisms used in modern network transport layers (MPLS, RSVP, Diffserv,Traffic Engineering) do not provide themselves a QoS-on-demand end-to-end solution and existing adaptative solutions based on In-band Control protocols (such as RTCP) are very difficult to combine with any other protocols for which they have not been designed for. Four Network Parameters comprises the QoS at application level: Bandwidth, packet-loss, latency and Jitter. Interactive-video applications define flows in both directions. Different applications require different constraints (in terms of latency, jitter, packet loss) in one or both directions and different responsiveness. The proposed solution must be an effective out-of-band application level protocol capable of reacting when any of these constraints are violated. Such protocol must trigger adaptive solutions and/or QoS network profile changes. Currently content providers are only able to provide services based on adaptative methods or last-mille deployments which prefer dedicated network resources (vs. Internet), and therefore, restricts the subscriber population and increases the costs. Objetives: The goal of this working group is to define a QoS application-level standard protocol optimized for its use over the internet that may be widely implemented and easily managed by application developers and service providers. The core technical considerations for such protocol include, but are not necessarily limited to, the following: 1. Protocol design to be used in interactive applications (including virtualized videogames,and interative-video applications) 2. Ensuring interoperability with all existing transport protocols 3. Optimizing for low bit rates (typlically below 2.4 kbps) 4. To ensure a feasible practical implementation based on policy servers and interoperability between service providers Deliverables: 1. Specification of protocol that meets the requirements in the form of an Internet-Draft that defines the negotiation of QoS parameters, the measurement process and alert mechanisms. 2. Dimensioning rules and performance analysis 3. A set of technical requirements for a practical implementation which may include adaptative solutions and/or QoS profile modification. Goals and Milestiones ===================== Nov 2010 Submit Internet-Draft as a proposed standard for QoS application-level protocol Proposed charter for Q4S WG Informational document with rules for dimensioning and performance analysis Specification of architecture document for implementation - Jose Javier _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --=_alternative 007B37B3852577FB_= Content-Type: text/html; charset="US-ASCII"
I am a little bit confused by the combination  of
        1. Protocol design to be used in interactive applications (including
      virtualized videogames,and interative-video applications)
  and
    3. Optimizing for low bit rates (typlically below 2.4 kbps)

I do not know many video games that work effectively at 2.4 kbps.

Am I missing something?

Janet


From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com>
To: "'dispatch@ietf.org'" <dispatch@ietf.org>
Cc: "pedrochas@dit.upm.es" <pedrochas@dit.upm.es>, "CUBILLO PASTOR,        CLARA \(CLARA\)" <clara.cubillo_pastor@alcatel-lucent.com>, "ORTIGA        HERRERA,        GUADALUPE \(GUADALUPE\)" <guadalupe.ortiga_herrera@alcatel-lucent.com>, "jquemada@dit.upm.es" <jquemada@dit.upm.es>, "HERRANZ PABLO,        SONIA \(SONIA\)" <sonia.herranz@alcatel-lucent.com>, "gabriel@dit.upm.es" <gabriel@dit.upm.es>, "barcenilla@dit.upm.es" <barcenilla@dit.upm.es>, "jsr@dit.upm.es" <jsr@dit.upm.es>, "DIAZ        VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" <luismi.diaz@alcatel-lucent.com>
Date: 12/13/2010 10:56 AM
Subject: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1




 
Hi everybody,
 
Here is the charter proposal for Q4S ( Quality for service) WG. This WG will include the achieved works with  "Q-HTTP"
 
Thanks for your comments
 
 
Description of Working group
============================
 
   Problem Statement:
 
   The QoS over Internet is a hot issue today. Current QoS handling
   mechanisms used in  modern network transport layers (MPLS, RSVP,
   Diffserv,Traffic Engineering) do not provide  themselves a
   QoS-on-demand end-to-end solution and existing adaptative
   solutions based on In-band Control protocols (such as RTCP)
   are very difficult to combine with any other protocols for which
   they have not been designed for.
 
   Four Network Parameters comprises the QoS at application level:
   Bandwidth, packet-loss, latency and Jitter.
 
   Interactive-video applications define flows in both directions.
   Different applications require different constraints (in terms of
   latency, jitter, packet loss) in one or both directions and
   different responsiveness. The proposed solution must be an
   effective out-of-band application level protocol capable of
   reacting when any of these constraints are violated. Such protocol
   must trigger adaptive solutions and/or QoS network profile changes.
 
   Currently content providers are only able to provide services based
   on adaptative methods or last-mille deployments which prefer
   dedicated network resources (vs. Internet), and therefore, restricts
   the subscriber population and increases the costs.
 
   Objetives:
 
   The goal of this working group is to define a
   QoS application-level  standard protocol optimized for its use over
   the internet that may be widely implemented and easily managed
   by application developers and service providers.
 
   The core technical considerations for such protocol include, but
   are not necessarily limited to, the following:
 
   1. Protocol design to be used in interactive applications (including
      virtualized videogames,and interative-video applications)
 
   2. Ensuring interoperability with all existing transport protocols
 
   3. Optimizing for low bit rates (typlically below 2.4 kbps)
 
   4. To ensure a feasible practical implementation based on
      policy servers and interoperability between service providers
 
 
   Deliverables:
 
   1. Specification of protocol that meets the requirements in the
      form of an Internet-Draft that defines the negotiation of QoS
      parameters, the measurement process and alert mechanisms.
 
   2. Dimensioning rules and performance analysis
 
   3. A set of technical requirements for a practical
      implementation which may include adaptative solutions and/or
      QoS profile modification.
 
 
Goals and Milestiones
=====================
 
Nov 2010    Submit Internet-Draft as a proposed standard for QoS
             application-level protocol
 
             Proposed charter for Q4S WG
 
             Informational document with rules for dimensioning
             and performance analysis
 
             Specification of architecture document for implementation
 
 
 
 
 
 
- Jose Javier
 
 
 
 _______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--=_alternative 007B37B3852577FB_=-- From peter.musgrave@magorcorp.com Fri Dec 17 03:46:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 698463A6B00 for ; Fri, 17 Dec 2010 03:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.357 X-Spam-Level: X-Spam-Status: No, score=-103.357 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e17T8eqEJM54 for ; Fri, 17 Dec 2010 03:46:58 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 5550D3A6AFC for ; Fri, 17 Dec 2010 03:46:58 -0800 (PST) Received: by iwn40 with SMTP id 40so692473iwn.31 for ; Fri, 17 Dec 2010 03:48:44 -0800 (PST) Received: by 10.42.218.195 with SMTP id hr3mr720056icb.529.1292586512188; Fri, 17 Dec 2010 03:48:32 -0800 (PST) Received: from [192.168.1.104] ([204.237.32.134]) by mx.google.com with ESMTPS id k38sm913306ick.21.2010.12.17.03.48.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 17 Dec 2010 03:48:31 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-15-746695792 From: Peter Musgrave In-Reply-To: <4CDA833D.8080203@alvestrand.no> Date: Fri, 17 Dec 2010 06:48:28 -0500 Message-Id: References: <4CDA833D.8080203@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1082) Cc: rtc-web@alvestrand.no, "dispatch@ietf.org" , Ted Hardie Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 11:46:59 -0000 --Apple-Mail-15-746695792 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'd also like to echo Alan's thanks for these drafts.=20 The protocol doc is very clear. [If you read only one dispatch draft = this Christmas, make it this one. ;-) ] One observation to the group. The mandatory to implement video CODEC is = VP8 (presumably since it does not have IPR issues - which some other = choices would have).=20 Regards,=20 Peter Musgrave Nits Introduction s/veichle/vehicle/ Section 2 Para "Within each.." s/implementaiton/implementation/ Section 4 Para1 "such as" (something missing here?) Section 5 Para2 "There is no third mandatory to implement"=20 ? Was there a mention of a third before. Not sure why this statement is = there. On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: > This is the overview document for the IETF-related RTC-WEB work. >=20 > -------- Original Message -------- > Subject: New Version Notification for = draft-alvestrand-dispatch-rtcweb-protocols-00 > Date: Wed, 10 Nov 2010 03:31:05 -0800 (PST) > From: IETF I-D Submission Tool > To: harald@alvestrand.no >=20 > A new version of I-D, = draft-alvestrand-dispatch-rtcweb-protocols-00.txt has been successfully = submitted by Harald Alvestrand and posted to the IETF repository. >=20 > Filename: draft-alvestrand-dispatch-rtcweb-protocols > Revision: 00 > Title: Overview: Real Time Protocols for Brower-based = Applications > Creation_date: 2010-11-11 > WG ID: Independent Submission > Number_of_pages: 9 >=20 > Abstract: > This document gives an overview of a protocol suite intended for use > with real-time applications that can be deployed in browsers - "real > time communication on the Web". >=20 > It intends to serve as a starting and coordination point to make sure > all the parts that are needed to achieve this goal are findable, and > that the parts that belong in the Internet protocol suite are fully > specified and on the right publication track. >=20 > This work is an attempt to synthesize the input of many people, but > makes no claims to fully represent the views of any of them. All > parts of the document should be regarded as open for discussion. > = =20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail-15-746695792 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Introduction
s/veichle/vehicle/


"such as" (something missing here?)

Section 5 Para2
? = Was there a mention of a third before. Not sure why this statement is = there.


On 2010-11-10, at 6:34 = AM, Harald Alvestrand wrote:

This is the overview document for the IETF-related RTC-WEB work.

-------- Original Message --------
Subject: = New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00
Date: = Wed, 10 Nov 2010 03:31:05 -0800 (PST)
From: = IETF I-D Submission Tool <idsubmission@ietf.org>
To: = harald@alvestrand.no 


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

Filename:	 draft-alvestrand-dispatch-rtcweb-protocols
Revision:	 00
Title:		 Overview: Real Time Protocols for Brower-based =
Applications
Creation_date:	 2010-11-11
WG ID:		 Independent Submission
Number_of_pages: 9

Abstract:
This document gives an overview of a protocol suite intended for use
with real-time applications that can be deployed in browsers - "real
time communication on the Web".

It intends to serve as a starting and coordination point to make sure
all the parts that are needed to achieve this goal are findable, and
that the parts that belong in the Internet protocol suite are fully
specified and on the right publication track.

This work is an attempt to synthesize the input of many people, but
makes no claims to fully represent the views of any of them.  All
parts of the document should be regarded as open for discussion.
                                                                         =
        =20


The IETF Secretariat.
_______________________________________________
dispatch mailing = list
dispatch@ietf.org
https://www.iet= f.org/mailman/listinfo/dispatch

= --Apple-Mail-15-746695792-- From jose_javier.garcia_aranda@alcatel-lucent.com Thu Dec 16 23:36:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 764793A68FD; Thu, 16 Dec 2010 23:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.68 X-Spam-Level: X-Spam-Status: No, score=-5.68 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2c+U-Ckw3+n; Thu, 16 Dec 2010 23:36:36 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 33D6F3A692E; Thu, 16 Dec 2010 23:36:34 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oBH7Y9be005078 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Dec 2010 08:34:10 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 17 Dec 2010 08:34:10 +0100 From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: Janet P Gunn Date: Fri, 17 Dec 2010 08:34:08 +0100 Thread-Topic: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 Thread-Index: AcudcDbjga71ljA7TKGze/bTAYH+XgASrP7Q Message-ID: <3349FECF788C984BB34176D70A51782F183F6946@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3349FECF788C984BB34176D70A51782F183F6946FRMRSSXCHMBSB3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 X-Mailman-Approved-At: Fri, 17 Dec 2010 06:05:20 -0800 Cc: "pedrochas@dit.upm.es" , "'dispatch@ietf.org'" , "dispatch-bounces@ietf.org" , "ORTIGA HERRERA, GUADALUPE \(GUADALUPE\)" , "jquemada@dit.upm.es" , "CUBILLO PASTOR, CLARA \(CLARA\)" , "gabriel@dit.upm.es" , "barcenilla@dit.upm.es" , "jsr@dit.upm.es" , "HERRANZ PABLO, SONIA \(SONIA\)" , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" Subject: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 07:36:38 -0000 --_000_3349FECF788C984BB34176D70A51782F183F6946FRMRSSXCHMBSB3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Janet, This new protocol nature for doing it is out-of-band. It means that it will= run in parallel with the protocol in charge of transport application data . For example this new protocol could be used in parallel with FTP, HTTP , RT= C or whatever. The new protocol measures the quality ( latency, jitter, packetloss, bandwi= dth) at the beggining and if the minimum quality is reached, the application can start = asuring a good experience. During the application timelife, the new protocol measur= es continuously the latency, jitter an packetloss and alerts if one or some of= these parameters are below certain threshold ( which depends on the application n= ature). Therefore, we propose a protocol compatible with all existing transport one= s, to provide a reliable mechanism for adaptative and QoS profile optimization. The new protocol uses low resources. Depending on the resources being used,= the responsiveness is different. For example, it can be useful to have a better= responsiveness in downlink than uplink, depends on each application. However, in any case= is a good point to consume a low bit rate for this purpose, though there is a trade-off bet= ween responsiveness and used bit-rate - jose javier ________________________________ De: Janet P Gunn [mailto:jgunn6@csc.com] Enviado el: jueves, 16 de diciembre de 2010 23:26 Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) CC: barcenilla@dit.upm.es; CUBILLO PASTOR, CLARA (CLARA); 'dispatch@ietf.or= g'; dispatch-bounces@ietf.org; gabriel@dit.upm.es; ORTIGA HERRERA, GUADALUP= E (GUADALUPE); jquemada@dit.upm.es; jsr@dit.upm.es; DIAZ VIZCAINO, LUIS MIG= UEL (LUIS MIGUEL); pedrochas@dit.upm.es; HERRANZ PABLO, SONIA (SONIA) Asunto: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Versi= on 1 I am a little bit confused by the combination of 1. Protocol design to be used in interactive applications (includin= g virtualized videogames,and interative-video applications) and 3. Optimizing for low bit rates (typlically below 2.4 kbps) I do not know many video games that work effectively at 2.4 kbps. Am I missing something? Janet From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: "'dispatch@ietf.org'" Cc: "pedrochas@dit.upm.es" , "CUBILLO PASTOR, = CLARA \(CLARA\)" , "ORTIGA = HERRERA, GUADALUPE \(GUADALUPE\)" , "jquemada@dit.upm.es" , "HERRANZ PABL= O, SONIA \(SONIA\)" , "gabriel@dit= .upm.es" , "barcenilla@dit.upm.es" , "jsr@dit.upm.es" , "DIAZ VIZCAINO, LUIS MIGUEL = \(LUIS MIGUEL\)" Date: 12/13/2010 10:56 AM Subject: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) V= ersion 1 ________________________________ Hi everybody, Here is the charter proposal for Q4S ( Quality for service) WG. This WG wil= l include the achieved works with "Q-HTTP" Thanks for your comments Description of Working group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Problem Statement: The QoS over Internet is a hot issue today. Current QoS handling mechanisms used in modern network transport layers (MPLS, RSVP, Diffserv,Traffic Engineering) do not provide themselves a QoS-on-demand end-to-end solution and existing adaptative solutions based on In-band Control protocols (such as RTCP) are very difficult to combine with any other protocols for which they have not been designed for. Four Network Parameters comprises the QoS at application level: Bandwidth, packet-loss, latency and Jitter. Interactive-video applications define flows in both directions. Different applications require different constraints (in terms of latency, jitter, packet loss) in one or both directions and different responsiveness. The proposed solution must be an effective out-of-band application level protocol capable of reacting when any of these constraints are violated. Such protocol must trigger adaptive solutions and/or QoS network profile changes. Currently content providers are only able to provide services based on adaptative methods or last-mille deployments which prefer dedicated network resources (vs. Internet), and therefore, restricts the subscriber population and increases the costs. Objetives: The goal of this working group is to define a QoS application-level standard protocol optimized for its use over the internet that may be widely implemented and easily managed by application developers and service providers. The core technical considerations for such protocol include, but are not necessarily limited to, the following: 1. Protocol design to be used in interactive applications (including virtualized videogames,and interative-video applications) 2. Ensuring interoperability with all existing transport protocols 3. Optimizing for low bit rates (typlically below 2.4 kbps) 4. To ensure a feasible practical implementation based on policy servers and interoperability between service providers Deliverables: 1. Specification of protocol that meets the requirements in the form of an Internet-Draft that defines the negotiation of QoS parameters, the measurement process and alert mechanisms. 2. Dimensioning rules and performance analysis 3. A set of technical requirements for a practical implementation which may include adaptative solutions and/or QoS profile modification. Goals and Milestiones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nov 2010 Submit Internet-Draft as a proposed standard for QoS application-level protocol Proposed charter for Q4S WG Informational document with rules for dimensioning and performance analysis Specification of architecture document for implementation - Jose Javier _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_3349FECF788C984BB34176D70A51782F183F6946FRMRSSXCHMBSB3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Janet,
 
This new protocol nature for doing it is out-of-ba= nd. It=20 means that it will run
in parallel with the protocol in charge of transpo= rt=20 application data .
For example this new protocol could be used in par= allel=20 with FTP, HTTP , RTC or whatever.
 
The new protocol measures the quality ( latency, j= itter,=20 packetloss, bandwidth) at the
beggining and if the minimum quality is reached, t= he=20 application can start asuring
a good experience. During the application timelife= , the new=20 protocol measures
continuously the latency, jitter an packetloss and= alerts=20 if one or some of these
parameters are below certain threshold ( which dep= ends on=20 the application nature).
 
Therefore, we propose a protocol compatible with a= ll=20 existing transport ones, to provide a
reliable mechanism for adaptative and QoS profile= =20 optimization.
 
The new protocol uses low resources. Depending on = the=20 resources being used, the
responsiveness is different. For example, it can b= e useful=20 to have a better  responsiveness
 in downlink than uplink, depends on each app= lication.=20 However, in any case is a good point
to consume a low bit rate for this=20 purpose, though there is a trade-off between responsiveness and=20
used bit-rate
 
- jose javier

De: Janet P Gunn [mailto:jgunn6@csc.com= ]=20
Enviado el: jueves, 16 de diciembre de 2010 23:26
Para:=20 GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
CC: barcenilla@dit.upm.e= s;=20 CUBILLO PASTOR, CLARA (CLARA); 'dispatch@ietf.org'; dispatch-bounces@ietf.o= rg;=20 gabriel@dit.upm.es; ORTIGA HERRERA, GUADALUPE (GUADALUPE); jquemada@dit.upm= .es;=20 jsr@dit.upm.es; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL); pedrochas@dit.upm= .es;=20 HERRANZ PABLO, SONIA (SONIA)
Asunto: Re: [dispatch] Charter propo= sal=20 for Q4S WG ( formerly Q-HTTP) Version 1


I am a little bit confused = by the=20 combination  of
  =  =20     1. Protocol design to be used in interactive applications=20 (including
    &nb= sp;=20 virtualized videogames,and interative-video applications)
  and
    3. Optimizing for low bit rates (typlically below 2.= 4=20 kbps)

I do not know many vi= deo games=20 that work effectively at 2.4 kbps.

Am I missing something?

Janet




From:=20 "GARCIA ARANDA, JOSE JAVIER (JOSE= =20 JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com>= =20
To:=20 "'dispatch@ietf.org'"=20 <dispatch@ietf.org>=20
Cc:=20 "pedrochas@dit.upm.es"=20 <pedrochas@dit.upm.es>, "CUBILLO PASTOR,      =20  CLARA \(CLARA\)" <clara.cubillo_pastor@alcatel-lucent.com>= ;,=20 "ORTIGA        HERRERA,      =20  GUADALUPE \(GUADALUPE\)"=20 <guadalupe.ortiga_herrera@alcatel-lucent.com>, "jquemada@dit.up= m.es"=20 <jquemada@dit.upm.es>, "HERRANZ PABLO,      =20  SONIA \(SONIA\)" <sonia.herranz@alcatel-lucent.com>,=20 "gabriel@dit.upm.es" <gabriel@dit.upm.es>, "barcenilla@dit.upm.= es"=20 <barcenilla@dit.upm.es>, "jsr@dit.upm.es" <jsr@dit.upm.es>= ;,=20 "DIAZ        VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\= )"=20 <luismi.diaz@alcatel-lucent.com>=20
Date:=20 12/13/2010 10:56 AM=20
Subject:=20 [dispatch] Charter proposal for Q4= S WG (=20 formerly Q-HTTP) Version 1




 
Hi=20 everybody,
 
Here is the charter proposal for Q4S ( Quality for service) WG. Th= is WG=20 will include the achieved works with  "Q-HTTP"
 
Thanks for your comm= ents=20
 
 
Description = of Working=20 group
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
 
   = ;Problem=20 Statement:
     The QoS over Internet is a hot i= ssue=20 today. Current QoS handling
=  =20  mechanisms used in  modern network transport layers (MPLS, RSVP,= =20
   Diffserv,Traffi= c=20 Engineering) do not provide  themselves a
   QoS-on-demand end-to-end solutio= n and=20 existing adaptative
 =20  solutions based on In-band Control protocols (such as RTCP)=20
   are very diffic= ult to=20 combine with any other protocols for which
   they have not been designed for.
 
   Four Network Parameters comprises the QoS at applicat= ion=20 level:
   Bandwidt= h,=20 packet-loss, latency and Jitter.
 
 =20  Interactive-video applications define flows in both directions.=20
   Different appli= cations=20 require different constraints (in terms of
   latency, jitter, packet loss) in one or both directio= ns and=20
   different=20 responsiveness. The proposed solution must be an
   effective out-of-band applicatio= n level=20 protocol capable of
 =20  reacting when any of these constraints are violated. Such protocol=20
   must trigger ad= aptive=20 solutions and/or QoS network profile changes.
 
   Currently content providers are only able to provide= =20 services based
   = on=20 adaptative methods or last-mille deployments which prefer
   dedicated network resources (vs.= =20 Internet), and therefore, restricts
   the subscriber population and increases the costs.=20
 
   Objetives:
 
   = ;The goal=20 of this working group is to define a
   QoS application-level  standard protocol optimiz= ed for=20 its use over
   th= e=20 internet that may be widely implemented and easily managed
   by application developers and se= rvice=20 providers.
     The core technical consideration= s for=20 such protocol include, but
&= nbsp;=20  are not necessarily limited to, the following:
 
   1. Protocol design to be used in interactive applicat= ions=20 (including
    &nb= sp;=20 virtualized videogames,and interative-video applications)
 
   2. Ensuring interoperability with all existing transp= ort=20 protocols
 
=    3. Optimizing for low bit rates= =20 (typlically below 2.4 kbps)
 
   = ;4. To=20 ensure a feasible practical implementation based on
      policy servers and=20 interoperability between service providers
 
 
   Deliverables:
 
   1. Specification of protocol that meets the requireme= nts in=20 the
      for= m of an=20 Internet-Draft that defines the negotiation of QoS
      parameters, the measurem= ent=20 process and alert mechanisms.
 
   = ;2.=20 Dimensioning rules and performance analysis
 
   = ;3. A set=20 of technical requirements for a practical
      implementation which may include adaptative=20 solutions and/or
  &nbs= p;  =20 QoS profile modification.
 
 
Goals and Milestiones
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
 
Nov=20 2010    Submit Internet-Draft as a proposed standard for QoS=20
        =  =20    application-level protocol
 
   = ;  =20        Proposed charter for Q4S WG
 
             Informational docu= ment=20 with rules for dimensioning
=  =20            and performance analysis=20
 
             Specification of=20 architecture document for implementation
 
 
 
 
 
 
- Jose=20 Javier
 
 
 
 _______________________________________________
dispatch mailin= g=20 list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch=


--_000_3349FECF788C984BB34176D70A51782F183F6946FRMRSSXCHMBSB3d_-- From luismi.diaz@alcatel-lucent.com Fri Dec 17 00:12:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F68B3A6962; Fri, 17 Dec 2010 00:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.894 X-Spam-Level: X-Spam-Status: No, score=-5.894 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0CPYeCumk9K; Fri, 17 Dec 2010 00:12:48 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id E78833A694D; Fri, 17 Dec 2010 00:12:47 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oBH8DtCY018785 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Dec 2010 09:14:01 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 17 Dec 2010 09:14:00 +0100 From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" To: Janet P Gunn , "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" Date: Fri, 17 Dec 2010 09:13:57 +0100 Thread-Topic: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 Thread-Index: AcudcDbjga71ljA7TKGze/bTAYH+XgAUgDtA Message-ID: <3349FECF788C984BB34176D70A51782F183F696E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: es-ES, en-US Content-Type: multipart/alternative; boundary="_000_3349FECF788C984BB34176D70A51782F183F696EFRMRSSXCHMBSB3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 X-Mailman-Approved-At: Fri, 17 Dec 2010 06:05:20 -0800 Cc: "pedrochas@dit.upm.es" , "'dispatch@ietf.org'" , "dispatch-bounces@ietf.org" , "ORTIGA HERRERA, GUADALUPE \(GUADALUPE\)" , "jquemada@dit.upm.es" , "CUBILLO PASTOR, CLARA \(CLARA\)" , "gabriel@dit.upm.es" , "barcenilla@dit.upm.es" , "jsr@dit.upm.es" , "HERRANZ PABLO, SONIA \(SONIA\)" Subject: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 08:12:50 -0000 --_000_3349FECF788C984BB34176D70A51782F183F696EFRMRSSXCHMBSB3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Maybe we should re-pharse that again :). We refer to Q4S protocol itself co= nsuming low bit-rate, not the applications themselves :D Saludos, Luismi ________________________________ De: Janet P Gunn [mailto:jgunn6@csc.com] Enviado el: jueves, 16 de diciembre de 2010 23:26 Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) CC: barcenilla@dit.upm.es; CUBILLO PASTOR, CLARA (CLARA); 'dispatch@ietf.or= g'; dispatch-bounces@ietf.org; gabriel@dit.upm.es; ORTIGA HERRERA, GUADALUP= E (GUADALUPE); jquemada@dit.upm.es; jsr@dit.upm.es; DIAZ VIZCAINO, LUIS MIG= UEL (LUIS MIGUEL); pedrochas@dit.upm.es; HERRANZ PABLO, SONIA (SONIA) Asunto: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Versi= on 1 I am a little bit confused by the combination of 1. Protocol design to be used in interactive applications (includin= g virtualized videogames,and interative-video applications) and 3. Optimizing for low bit rates (typlically below 2.4 kbps) I do not know many video games that work effectively at 2.4 kbps. Am I missing something? Janet From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: "'dispatch@ietf.org'" Cc: "pedrochas@dit.upm.es" , "CUBILLO PASTOR, = CLARA \(CLARA\)" , "ORTIGA = HERRERA, GUADALUPE \(GUADALUPE\)" , "jquemada@dit.upm.es" , "HERRANZ PABL= O, SONIA \(SONIA\)" , "gabriel@dit= .upm.es" , "barcenilla@dit.upm.es" , "jsr@dit.upm.es" , "DIAZ VIZCAINO, LUIS MIGUEL = \(LUIS MIGUEL\)" Date: 12/13/2010 10:56 AM Subject: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) V= ersion 1 ________________________________ Hi everybody, Here is the charter proposal for Q4S ( Quality for service) WG. This WG wil= l include the achieved works with "Q-HTTP" Thanks for your comments Description of Working group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Problem Statement: The QoS over Internet is a hot issue today. Current QoS handling mechanisms used in modern network transport layers (MPLS, RSVP, Diffserv,Traffic Engineering) do not provide themselves a QoS-on-demand end-to-end solution and existing adaptative solutions based on In-band Control protocols (such as RTCP) are very difficult to combine with any other protocols for which they have not been designed for. Four Network Parameters comprises the QoS at application level: Bandwidth, packet-loss, latency and Jitter. Interactive-video applications define flows in both directions. Different applications require different constraints (in terms of latency, jitter, packet loss) in one or both directions and different responsiveness. The proposed solution must be an effective out-of-band application level protocol capable of reacting when any of these constraints are violated. Such protocol must trigger adaptive solutions and/or QoS network profile changes. Currently content providers are only able to provide services based on adaptative methods or last-mille deployments which prefer dedicated network resources (vs. Internet), and therefore, restricts the subscriber population and increases the costs. Objetives: The goal of this working group is to define a QoS application-level standard protocol optimized for its use over the internet that may be widely implemented and easily managed by application developers and service providers. The core technical considerations for such protocol include, but are not necessarily limited to, the following: 1. Protocol design to be used in interactive applications (including virtualized videogames,and interative-video applications) 2. Ensuring interoperability with all existing transport protocols 3. Optimizing for low bit rates (typlically below 2.4 kbps) 4. To ensure a feasible practical implementation based on policy servers and interoperability between service providers Deliverables: 1. Specification of protocol that meets the requirements in the form of an Internet-Draft that defines the negotiation of QoS parameters, the measurement process and alert mechanisms. 2. Dimensioning rules and performance analysis 3. A set of technical requirements for a practical implementation which may include adaptative solutions and/or QoS profile modification. Goals and Milestiones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nov 2010 Submit Internet-Draft as a proposed standard for QoS application-level protocol Proposed charter for Q4S WG Informational document with rules for dimensioning and performance analysis Specification of architecture document for implementation - Jose Javier _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_3349FECF788C984BB34176D70A51782F183F696EFRMRSSXCHMBSB3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Maybe we should re-pharse that again :). We refer = to Q4S=20 protocol itself consuming low bit-rate, not the applications themselves=20 :D
 
    Saludos,
         Luismi
 

De: Janet P Gunn [mailto:jgunn6@csc.com= ]=20
Enviado el: jueves, 16 de diciembre de 2010 23:26
Para:=20 GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
CC: barcenilla@dit.upm.e= s;=20 CUBILLO PASTOR, CLARA (CLARA); 'dispatch@ietf.org'; dispatch-bounces@ietf.o= rg;=20 gabriel@dit.upm.es; ORTIGA HERRERA, GUADALUPE (GUADALUPE); jquemada@dit.upm= .es;=20 jsr@dit.upm.es; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL); pedrochas@dit.upm= .es;=20 HERRANZ PABLO, SONIA (SONIA)
Asunto: Re: [dispatch] Charter propo= sal=20 for Q4S WG ( formerly Q-HTTP) Version 1


I am a little bit confused = by the=20 combination  of
  =  =20     1. Protocol design to be used in interactive applications=20 (including
    &nb= sp;=20 virtualized videogames,and interative-video applications)
  and
    3. Optimizing for low bit rates (typlically below 2.= 4=20 kbps)

I do not know many vi= deo games=20 that work effectively at 2.4 kbps.

Am I missing something?

Janet




From:=20 "GARCIA ARANDA, JOSE JAVIER (JOSE= =20 JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com>= =20
To:=20 "'dispatch@ietf.org'"=20 <dispatch@ietf.org>=20
Cc:=20 "pedrochas@dit.upm.es"=20 <pedrochas@dit.upm.es>, "CUBILLO PASTOR,      =20  CLARA \(CLARA\)" <clara.cubillo_pastor@alcatel-lucent.com>= ;,=20 "ORTIGA        HERRERA,      =20  GUADALUPE \(GUADALUPE\)"=20 <guadalupe.ortiga_herrera@alcatel-lucent.com>, "jquemada@dit.up= m.es"=20 <jquemada@dit.upm.es>, "HERRANZ PABLO,      =20  SONIA \(SONIA\)" <sonia.herranz@alcatel-lucent.com>,=20 "gabriel@dit.upm.es" <gabriel@dit.upm.es>, "barcenilla@dit.upm.= es"=20 <barcenilla@dit.upm.es>, "jsr@dit.upm.es" <jsr@dit.upm.es>= ;,=20 "DIAZ        VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\= )"=20 <luismi.diaz@alcatel-lucent.com>=20
Date:=20 12/13/2010 10:56 AM=20
Subject:=20 [dispatch] Charter proposal for Q4= S WG (=20 formerly Q-HTTP) Version 1




 
Hi=20 everybody,
 
Here is the charter proposal for Q4S ( Quality for service) WG. Th= is WG=20 will include the achieved works with  "Q-HTTP"
 
Thanks for your comm= ents=20
 
 
Description = of Working=20 group
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
 
   = ;Problem=20 Statement:
     The QoS over Internet is a hot i= ssue=20 today. Current QoS handling
=  =20  mechanisms used in  modern network transport layers (MPLS, RSVP,= =20
   Diffserv,Traffi= c=20 Engineering) do not provide  themselves a
   QoS-on-demand end-to-end solutio= n and=20 existing adaptative
 =20  solutions based on In-band Control protocols (such as RTCP)=20
   are very diffic= ult to=20 combine with any other protocols for which
   they have not been designed for.
 
   Four Network Parameters comprises the QoS at applicat= ion=20 level:
   Bandwidt= h,=20 packet-loss, latency and Jitter.
 
 =20  Interactive-video applications define flows in both directions.=20
   Different appli= cations=20 require different constraints (in terms of
   latency, jitter, packet loss) in one or both directio= ns and=20
   different=20 responsiveness. The proposed solution must be an
   effective out-of-band applicatio= n level=20 protocol capable of
 =20  reacting when any of these constraints are violated. Such protocol=20
   must trigger ad= aptive=20 solutions and/or QoS network profile changes.
 
   Currently content providers are only able to provide= =20 services based
   = on=20 adaptative methods or last-mille deployments which prefer
   dedicated network resources (vs.= =20 Internet), and therefore, restricts
   the subscriber population and increases the costs.=20
 
   Objetives:
 
   = ;The goal=20 of this working group is to define a
   QoS application-level  standard protocol optimiz= ed for=20 its use over
   th= e=20 internet that may be widely implemented and easily managed
   by application developers and se= rvice=20 providers.
     The core technical consideration= s for=20 such protocol include, but
&= nbsp;=20  are not necessarily limited to, the following:
 
   1. Protocol design to be used in interactive applicat= ions=20 (including
    &nb= sp;=20 virtualized videogames,and interative-video applications)
 
   2. Ensuring interoperability with all existing transp= ort=20 protocols
 
=    3. Optimizing for low bit rates= =20 (typlically below 2.4 kbps)
 
   = ;4. To=20 ensure a feasible practical implementation based on
      policy servers and=20 interoperability between service providers
 
 
   Deliverables:
 
   1. Specification of protocol that meets the requireme= nts in=20 the
      for= m of an=20 Internet-Draft that defines the negotiation of QoS
      parameters, the measurem= ent=20 process and alert mechanisms.
 
   = ;2.=20 Dimensioning rules and performance analysis
 
   = ;3. A set=20 of technical requirements for a practical
      implementation which may include adaptative=20 solutions and/or
  &nbs= p;  =20 QoS profile modification.
 
 
Goals and Milestiones
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
 
Nov=20 2010    Submit Internet-Draft as a proposed standard for QoS=20
        =  =20    application-level protocol
 
   = ;  =20        Proposed charter for Q4S WG
 
             Informational docu= ment=20 with rules for dimensioning
=  =20            and performance analysis=20
 
             Specification of=20 architecture document for implementation
 
 
 
 
 
 
- Jose=20 Javier
 
 
 
 _______________________________________________
dispatch mailin= g=20 list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch=


--_000_3349FECF788C984BB34176D70A51782F183F696EFRMRSSXCHMBSB3d_-- From peter.musgrave@magorcorp.com Fri Dec 17 03:55:30 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27553A6B04 for ; Fri, 17 Dec 2010 03:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSy3+YmCQjVF for ; Fri, 17 Dec 2010 03:55:29 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 61C493A6AFC for ; Fri, 17 Dec 2010 03:55:29 -0800 (PST) Received: by iwn40 with SMTP id 40so699888iwn.31 for ; Fri, 17 Dec 2010 03:57:16 -0800 (PST) Received: by 10.42.177.74 with SMTP id bh10mr782249icb.51.1292587035970; Fri, 17 Dec 2010 03:57:15 -0800 (PST) Received: from [192.168.1.104] ([204.237.32.134]) by mx.google.com with ESMTPS id u5sm925469ics.6.2010.12.17.03.57.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 17 Dec 2010 03:57:14 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-16-747219055 From: Peter Musgrave In-Reply-To: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Fri, 17 Dec 2010 06:57:11 -0500 Message-Id: <016A7A36-CCC2-455F-9A31-9202C8117487@magorcorp.com> References: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> To: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Fri, 17 Dec 2010 06:05:20 -0800 Cc: "pedrochas@dit.upm.es" , "CUBILLO PASTOR, CLARA \(CLARA\)" , "ORTIGA HERRERA, GUADALUPE \(GUADALUPE\)" , "jquemada@dit.upm.es" , "'dispatch@ietf.org'" , "gabriel@dit.upm.es" , "barcenilla@dit.upm.es" , "jsr@dit.upm.es" , "HERRANZ PABLO, SONIA \(SONIA\)" , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" Subject: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 11:55:30 -0000 --Apple-Mail-16-747219055 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Jose,=20 Can you comment on the relationship of this work to the rtcweb drafts = currently in dispatch? Those seems to me a method to use existing = protocols to solve very similar issues.=20 I am also unsure of what defining an application level standard protocol = really means. Is this changes to http? Something that runs beside http? = Instead of? Over? Thanks,=20 Peter Musgrave On 2010-12-13, at 10:39 AM, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) = wrote: > =20 > Hi everybody, > =20 > Here is the charter proposal for Q4S ( Quality for service) WG. This = WG will include the achieved works with "Q-HTTP" > =20 > Thanks for your comments > =20 > =20 > Description of Working group > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > =20 > Problem Statement: > =20 > The QoS over Internet is a hot issue today. Current QoS handling > mechanisms used in modern network transport layers (MPLS, RSVP, > Diffserv,Traffic Engineering) do not provide themselves a > QoS-on-demand end-to-end solution and existing adaptative > solutions based on In-band Control protocols (such as RTCP) > are very difficult to combine with any other protocols for which > they have not been designed for. > =20 > Four Network Parameters comprises the QoS at application level: > Bandwidth, packet-loss, latency and Jitter. > =20 > Interactive-video applications define flows in both directions. > Different applications require different constraints (in terms of > latency, jitter, packet loss) in one or both directions and > different responsiveness. The proposed solution must be an > effective out-of-band application level protocol capable of > reacting when any of these constraints are violated. Such protocol > must trigger adaptive solutions and/or QoS network profile changes. > =20 > Currently content providers are only able to provide services based > on adaptative methods or last-mille deployments which prefer > dedicated network resources (vs. Internet), and therefore, = restricts > the subscriber population and increases the costs. > =20 > Objetives: > =20 > The goal of this working group is to define a > QoS application-level standard protocol optimized for its use over > the internet that may be widely implemented and easily managed > by application developers and service providers. > =20 > The core technical considerations for such protocol include, but > are not necessarily limited to, the following: > =20 > 1. Protocol design to be used in interactive applications = (including > virtualized videogames,and interative-video applications) > =20 > 2. Ensuring interoperability with all existing transport protocols > =20 > 3. Optimizing for low bit rates (typlically below 2.4 kbps) > =20 > 4. To ensure a feasible practical implementation based on > policy servers and interoperability between service providers > =20 > =20 > Deliverables: > =20 > 1. Specification of protocol that meets the requirements in the > form of an Internet-Draft that defines the negotiation of QoS > parameters, the measurement process and alert mechanisms. > =20 > 2. Dimensioning rules and performance analysis > =20 > 3. A set of technical requirements for a practical > implementation which may include adaptative solutions and/or > QoS profile modification. > =20 > =20 > Goals and Milestiones > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > Nov 2010 Submit Internet-Draft as a proposed standard for QoS > application-level protocol > =20 > Proposed charter for Q4S WG > =20 > Informational document with rules for dimensioning > and performance analysis > =20 > Specification of architecture document for implementation > =20 > =20 > =20 > =20 > =20 > =20 > - Jose Javier > =20 > =20 > =20 > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail-16-747219055 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Jose, 

Can you comment = on the relationship of this work to the rtcweb drafts currently in = dispatch? Those seems to me a method to use existing protocols to solve = very similar issues. 

I am also unsure of = what defining an application level standard protocol really means. Is = this changes to http? Something that runs beside http? Instead of? = Over?

Thanks, 

Pete= r Musgrave


On = 2010-12-13, at 10:39 AM, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) = wrote:

 
Hi everybody,
 
Here is the charter = proposal for Q4S ( Quality for service) WG. This WG will include the = achieved works with  "Q-HTTP"
 
Thanks for your = comments
 
 
Description of Working group
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
 
   Problem = Statement:
 
   The QoS over Internet is a hot issue today. = Current QoS handling
   mechanisms used in  modern = network transport layers (MPLS, RSVP,
   Diffserv,Traffic = Engineering) do not provide  themselves a
   QoS-on-demand = end-to-end solution and existing adaptative
   solutions based = on In-band Control protocols (such as RTCP)
   are very = difficult to combine with any other protocols for = which
   they have not been designed = for.
 
   Four Network Parameters comprises the QoS at = application level:
   Bandwidth, packet-loss, latency and = Jitter.
 
   Interactive-video applications define flows in = both directions.
   Different applications require different = constraints (in terms of
   latency, jitter, packet loss) in one = or both directions and
   different responsiveness. The = proposed solution must be an
   effective out-of-band application = level protocol capable of
   reacting when any of these = constraints are violated. Such protocol
   must trigger = adaptive solutions and/or QoS network profile = changes.
 
   Currently content providers are only able to = provide services based
   on adaptative methods or last-mille = deployments which prefer
   dedicated network resources (vs. = Internet), and therefore, restricts
   the subscriber population and = increases the costs.
 
   Objetives:
 
   The goal of this = working group is to define a
   QoS application-level  standard = protocol optimized for its use over
   the internet that may be widely = implemented and easily managed
   by application developers and = service providers.
 
   The core technical considerations for = such protocol include, but
   are not necessarily limited to, the = following:
 
   1. Protocol design to be used in interactive = applications (including
      virtualized = videogames,and interative-video applications)
 
   2. Ensuring = interoperability with all existing transport = protocols
 
   3. Optimizing for low bit rates (typlically = below 2.4 kbps)
 
   4. To ensure a feasible practical implementation = based on
      policy servers and = interoperability between service providers
 
 
   = Deliverables:
 
   1. Specification of protocol that meets the = requirements in the
      form of an = Internet-Draft that defines the negotiation of = QoS
      parameters, the measurement = process and alert mechanisms.
 
   2. Dimensioning rules and = performance analysis
 
   3. A set of technical requirements = for a practical
      implementation which may = include adaptative solutions and/or
      QoS profile = modification.
 
 
Goals and Milestiones
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
 
Nov 2010    Submit Internet-Draft as a = proposed standard for QoS
          &nb= sp;  application-level protocol
 
          &nb= sp;  Proposed charter for Q4S WG
 
          &nb= sp;  Informational document with rules for = dimensioning
          &nb= sp;  and performance analysis
 
          &nb= sp;  Specification of architecture document for = implementation
 
 
 
 
 
 
- Jose = Javier
 
 
 
 
_____________________________________= __________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dispatch

= --Apple-Mail-16-747219055-- From jgunn6@csc.com Fri Dec 17 11:14:57 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBFAC3A6977; Fri, 17 Dec 2010 11:14:57 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyvZwK9E6dr3; Fri, 17 Dec 2010 11:14:56 -0800 (PST) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by core3.amsl.com (Postfix) with ESMTP id BC1813A6BB2; Fri, 17 Dec 2010 11:14:55 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-2.tower-171.messagelabs.com!1292613401!23389101!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 5850 invoked from network); 17 Dec 2010 19:16:41 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-2.tower-171.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2010 19:16:41 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id oBHJGeSp025917; Fri, 17 Dec 2010 14:16:40 -0500 In-Reply-To: References: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F183F6946@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> To: Janet P Gunn MIME-Version: 1.0 X-KeepSent: 1C91DBDF:119F3296-852577FC:0069CEC8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Fri, 17 Dec 2010 14:16:39 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.1FP1 HF440|June 18, 2010) at 12/17/2010 02:16:17 PM, Serialize complete at 12/17/2010 02:16:17 PM Content-Type: multipart/alternative; boundary="=_alternative 0069E263852577FC_=" Cc: "dispatch-bounces@ietf.org" , "'dispatch@ietf.org'" Subject: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 19:14:58 -0000 This is a multipart message in MIME format. --=_alternative 0069E263852577FC_= Content-Type: text/plain; charset="US-ASCII" OK, so that was what I was missing. Maybe rephrasing it would help. Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: Janet P Gunn/USA/CSC@CSC Cc: "barcenilla@dit.upm.es" , "CUBILLO PASTOR, CLARA (CLARA)" , "'dispatch@ietf.org'" , "dispatch-bounces@ietf.org" , "gabriel@dit.upm.es" , "ORTIGA HERRERA, GUADALUPE (GUADALUPE)" , "jquemada@dit.upm.es" , "jsr@dit.upm.es" , "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" , "pedrochas@dit.upm.es" , "HERRANZ PABLO, SONIA (SONIA)" Date: 12/17/2010 02:34 AM Subject: RE: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 Hi Janet, This new protocol nature for doing it is out-of-band. It means that it will run in parallel with the protocol in charge of transport application data . For example this new protocol could be used in parallel with FTP, HTTP , RTC or whatever. The new protocol measures the quality ( latency, jitter, packetloss, bandwidth) at the beggining and if the minimum quality is reached, the application can start asuring a good experience. During the application timelife, the new protocol measures continuously the latency, jitter an packetloss and alerts if one or some of these parameters are below certain threshold ( which depends on the application nature). Therefore, we propose a protocol compatible with all existing transport ones, to provide a reliable mechanism for adaptative and QoS profile optimization. The new protocol uses low resources. Depending on the resources being used, the responsiveness is different. For example, it can be useful to have a better responsiveness in downlink than uplink, depends on each application. However, in any case is a good point to consume a low bit rate for this purpose, though there is a trade-off between responsiveness and used bit-rate - jose javier De: Janet P Gunn [mailto:jgunn6@csc.com] Enviado el: jueves, 16 de diciembre de 2010 23:26 Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) CC: barcenilla@dit.upm.es; CUBILLO PASTOR, CLARA (CLARA); 'dispatch@ietf.org'; dispatch-bounces@ietf.org; gabriel@dit.upm.es; ORTIGA HERRERA, GUADALUPE (GUADALUPE); jquemada@dit.upm.es; jsr@dit.upm.es; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL); pedrochas@dit.upm.es; HERRANZ PABLO, SONIA (SONIA) Asunto: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 I am a little bit confused by the combination of 1. Protocol design to be used in interactive applications (including virtualized videogames,and interative-video applications) and 3. Optimizing for low bit rates (typlically below 2.4 kbps) I do not know many video games that work effectively at 2.4 kbps. Am I missing something? Janet From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: "'dispatch@ietf.org'" Cc: "pedrochas@dit.upm.es" , "CUBILLO PASTOR, CLARA \(CLARA\)" , "ORTIGA HERRERA, GUADALUPE \(GUADALUPE\)" , "jquemada@dit.upm.es" , "HERRANZ PABLO, SONIA \(SONIA\)" , "gabriel@dit.upm.es" , "barcenilla@dit.upm.es" , "jsr@dit.upm.es" , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" Date: 12/13/2010 10:56 AM Subject: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 Hi everybody, Here is the charter proposal for Q4S ( Quality for service) WG. This WG will include the achieved works with "Q-HTTP" Thanks for your comments Description of Working group ============================ Problem Statement: The QoS over Internet is a hot issue today. Current QoS handling mechanisms used in modern network transport layers (MPLS, RSVP, Diffserv,Traffic Engineering) do not provide themselves a QoS-on-demand end-to-end solution and existing adaptative solutions based on In-band Control protocols (such as RTCP) are very difficult to combine with any other protocols for which they have not been designed for. Four Network Parameters comprises the QoS at application level: Bandwidth, packet-loss, latency and Jitter. Interactive-video applications define flows in both directions. Different applications require different constraints (in terms of latency, jitter, packet loss) in one or both directions and different responsiveness. The proposed solution must be an effective out-of-band application level protocol capable of reacting when any of these constraints are violated. Such protocol must trigger adaptive solutions and/or QoS network profile changes. Currently content providers are only able to provide services based on adaptative methods or last-mille deployments which prefer dedicated network resources (vs. Internet), and therefore, restricts the subscriber population and increases the costs. Objetives: The goal of this working group is to define a QoS application-level standard protocol optimized for its use over the internet that may be widely implemented and easily managed by application developers and service providers. The core technical considerations for such protocol include, but are not necessarily limited to, the following: 1. Protocol design to be used in interactive applications (including virtualized videogames,and interative-video applications) 2. Ensuring interoperability with all existing transport protocols 3. Optimizing for low bit rates (typlically below 2.4 kbps) 4. To ensure a feasible practical implementation based on policy servers and interoperability between service providers Deliverables: 1. Specification of protocol that meets the requirements in the form of an Internet-Draft that defines the negotiation of QoS parameters, the measurement process and alert mechanisms. 2. Dimensioning rules and performance analysis 3. A set of technical requirements for a practical implementation which may include adaptative solutions and/or QoS profile modification. Goals and Milestiones ===================== Nov 2010 Submit Internet-Draft as a proposed standard for QoS application-level protocol Proposed charter for Q4S WG Informational document with rules for dimensioning and performance analysis Specification of architecture document for implementation - Jose Javier _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --=_alternative 0069E263852577FC_= Content-Type: text/html; charset="US-ASCII"







OK, so that was what I was missing.

Maybe rephrasing it would help.

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.



From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com>
To: Janet P Gunn/USA/CSC@CSC
Cc: "barcenilla@dit.upm.es" <barcenilla@dit.upm.es>, "CUBILLO PASTOR, CLARA (CLARA)" <clara.cubillo_pastor@alcatel-lucent.com>, "'dispatch@ietf.org'" <dispatch@ietf.org>, "dispatch-bounces@ietf.org" <dispatch-bounces@ietf.org>, "gabriel@dit.upm.es" <gabriel@dit.upm.es>, "ORTIGA HERRERA, GUADALUPE (GUADALUPE)" <guadalupe.ortiga_herrera@alcatel-lucent.com>, "jquemada@dit.upm.es" <jquemada@dit.upm.es>, "jsr@dit.upm.es" <jsr@dit.upm.es>, "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <luismi.diaz@alcatel-lucent.com>, "pedrochas@dit.upm.es" <pedrochas@dit.upm.es>, "HERRANZ PABLO, SONIA (SONIA)" <sonia.herranz@alcatel-lucent.com>
Date: 12/17/2010 02:34 AM
Subject: RE: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1




Hi Janet,
 
This new protocol nature for doing it is out-of-band. It means that it will run
in parallel with the protocol in charge of transport application data .
For example this new protocol could be used in parallel with FTP, HTTP , RTC or whatever.
 
The new protocol measures the quality ( latency, jitter, packetloss, bandwidth) at the
beggining and if the minimum quality is reached, the application can start asuring
a good experience. During the application timelife, the new protocol measures
continuously the latency, jitter an packetloss and alerts if one or some of these
parameters are below certain threshold ( which depends on the application nature).
 
Therefore, we propose a protocol compatible with all existing transport ones, to provide a
reliable mechanism for adaptative and QoS profile optimization.
 
The new protocol uses low resources. Depending on the resources being used, the
responsiveness is different. For example, it can be useful to have a better  responsiveness
 in downlink than uplink, depends on each application. However, in any case is a good point
to consume a low bit rate for this purpose, though there is a trade-off between responsiveness and
used bit-rate
 
- jose javier

De: Janet P Gunn [mailto:jgunn6@csc.com]
Enviado el: jueves, 16 de diciembre de 2010 23:26
Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
CC: barcenilla@dit.upm.es; CUBILLO PASTOR, CLARA (CLARA); 'dispatch@ietf.org'; dispatch-bounces@ietf.org; gabriel@dit.upm.es; ORTIGA HERRERA, GUADALUPE (GUADALUPE); jquemada@dit.upm.es; jsr@dit.upm.es; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL); pedrochas@dit.upm.es; HERRANZ PABLO, SONIA (SONIA)
Asunto: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1

I am a little bit confused by the combination  of
       1. Protocol design to be used in interactive applications (including
     virtualized videogames,and interative-video applications)
 and
   3. Optimizing for low bit rates (typlically below 2.4 kbps)

I do not know many video games that work effectively at 2.4 kbps.

Am I missing something?

Janet
From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com>
To: "'dispatch@ietf.org'" <dispatch@ietf.org>
Cc: "pedrochas@dit.upm.es" <pedrochas@dit.upm.es>, "CUBILLO PASTOR,        CLARA \(CLARA\)" <clara.cubillo_pastor@alcatel-lucent.com>, "ORTIGA        HERRERA,        GUADALUPE \(GUADALUPE\)" <guadalupe.ortiga_herrera@alcatel-lucent.com>, "jquemada@dit.upm.es" <jquemada@dit.upm.es>, "HERRANZ PABLO,        SONIA \(SONIA\)" <sonia.herranz@alcatel-lucent.com>, "gabriel@dit.upm.es" <gabriel@dit.upm.es>, "barcenilla@dit.upm.es" <barcenilla@dit.upm.es>, "jsr@dit.upm.es" <jsr@dit.upm.es>, "DIAZ        VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" <luismi.diaz@alcatel-lucent.com>
Date: 12/13/2010 10:56 AM
Subject: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1



 
Hi everybody,
 
Here is the charter proposal for Q4S ( Quality for service) WG. This WG will include the achieved works with  "Q-HTTP"
 
Thanks for your comments
 
 
Description of Working group
============================
 
  Problem Statement:
 
  The QoS over Internet is a hot issue today. Current QoS handling
  mechanisms used in  modern network transport layers (MPLS, RSVP,
  Diffserv,Traffic Engineering) do not provide  themselves a
  QoS-on-demand end-to-end solution and existing adaptative
  solutions based on In-band Control protocols (such as RTCP)
  are very difficult to combine with any other protocols for which
  they have not been designed for.
 
  Four Network Parameters comprises the QoS at application level:
  Bandwidth, packet-loss, latency and Jitter.
 
  Interactive-video applications define flows in both directions.
  Different applications require different constraints (in terms of
  latency, jitter, packet loss) in one or both directions and
  different responsiveness. The proposed solution must be an
  effective out-of-band application level protocol capable of
  reacting when any of these constraints are violated. Such protocol
  must trigger adaptive solutions and/or QoS network profile changes.
 
  Currently content providers are only able to provide services based
  on adaptative methods or last-mille deployments which prefer
  dedicated network resources (vs. Internet), and therefore, restricts
  the subscriber population and increases the costs.
 
  Objetives:
 
  The goal of this working group is to define a
  QoS application-level  standard protocol optimized for its use over
  the internet that may be widely implemented and easily managed
  by application developers and service providers.
 
  The core technical considerations for such protocol include, but
  are not necessarily limited to, the following:
 
  1. Protocol design to be used in interactive applications (including
     virtualized videogames,and interative-video applications)
 
  2. Ensuring interoperability with all existing transport protocols
 
  3. Optimizing for low bit rates (typlically below 2.4 kbps)
 
  4. To ensure a feasible practical implementation based on
     policy servers and interoperability between service providers
 
 
  Deliverables:
 
  1. Specification of protocol that meets the requirements in the
     form of an Internet-Draft that defines the negotiation of QoS
     parameters, the measurement process and alert mechanisms.
 
  2. Dimensioning rules and performance analysis
 
  3. A set of technical requirements for a practical
     implementation which may include adaptative solutions and/or
     QoS profile modification.
 
 
Goals and Milestiones
=====================
 
Nov 2010    Submit Internet-Draft as a proposed standard for QoS
            application-level protocol
 
            Proposed charter for Q4S WG
 
            Informational document with rules for dimensioning
            and performance analysis
 
            Specification of architecture document for implementation
 
 
 
 
 
 
- Jose Javier
 
 
 
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--=_alternative 0069E263852577FC_=-- From jose_javier.garcia_aranda@alcatel-lucent.com Sat Dec 18 03:43:15 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A713A697C for ; Sat, 18 Dec 2010 03:43:15 -0800 (PST) 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.619, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lG1tJtdF+pI for ; Sat, 18 Dec 2010 03:43:14 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id BE98E3A699D for ; Sat, 18 Dec 2010 03:43:12 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oBIBixKU007489 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 18 Dec 2010 12:44:59 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sat, 18 Dec 2010 12:44:59 +0100 From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: Peter Musgrave , "'dispatch@ietf.org'" Date: Sat, 18 Dec 2010 12:44:52 +0100 Thread-Topic: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 Thread-Index: Acud4ZDKYcBP+9RPS22nHYz70UqcxwAIc+8AAChczBA= Message-ID: <3349FECF788C984BB34176D70A51782F18464DB5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <016A7A36-CCC2-455F-9A31-9202C8117487@magorcorp.com> Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3349FECF788C984BB34176D70A51782F18464DB5FRMRSSXCHMBSB3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" Subject: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2010 11:43:16 -0000 --_000_3349FECF788C984BB34176D70A51782F18464DB5FRMRSSXCHMBSB3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter , all relation with rtcweb =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D rtcweb try to identify and find a consensus on a set of components to comm= unicate universally for real-time communications. Inside this approach, Q4S= protocol could be part of this set of agreed protocols. The intention of r= tcweb is to standarize as much as possible, without leaving these set of pr= otocols or functionalities in the scope of web applications or plug-ins for= browsers. We believe that a standarized protocol for Quality measurements = and alerts would be interesting for all internet community because if we co= mpare a Q4S standard protocol with propietary solutions, we found that the= range of benefited applications and the number of possible implementations= are higher with a standardized solution. In addition a multi-ISP solution could be reached using a standard protocol= , in which each peer of communication belongs to a different ISP and possib= ilities based on Q4S protocol are available for QoS profile managemen. relation with http =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The measurement and/or alert in realtime functions would be covered by the= Q4S wg, in particular the Q - HTTP protocol ( which may be renamed to Q4S = or other name). This protocol (formerly named Q-HTTP) uses HTTP syntax, and uses specific U= RI for easy integration in www. However can be used out of www context. In= fact, the protocol is not an http extension. It is an out-of-band protoc= ol to measure and alert participants of a communication based in any protoc= ol ( http could be the protocol to transmit application data and Q-HTTP the= protocol to monitor the quality end2end). The protocol can be used in con= juntion with any other protocol used for application data transport (HTTP, = FTP, RTP, whatever) . In fact, Q-HTTP is not used to transpor t data, bu= t for measurement the latency, jitter, packetloss end2end and alert if some= thresholds are being violated for trigger adaptative solutions or changes = in QoS profile. The concrete adatative solution or how the QoS profile is changed is out of= scope of the protocol. The protocol only monitor and send an alert, that i= s useful to know when these types of actions should be taken - jose javier ________________________________ De: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] Enviado el: viernes, 17 de diciembre de 2010 12:57 Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) CC: 'dispatch@ietf.org'; pedrochas@dit.upm.es; CUBILLO PASTOR, CLARA (CLARA= ); ORTIGA HERRERA, GUADALUPE (GUADALUPE); jquemada@dit.upm.es; HERRANZ PABL= O, SONIA (SONIA); gabriel@dit.upm.es; barcenilla@dit.upm.es; jsr@dit.upm.es= ; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) Asunto: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Versi= on 1 Hi Jose, Can you comment on the relationship of this work to the rtcweb drafts curre= ntly in dispatch? Those seems to me a method to use existing protocols to s= olve very similar issues. I am also unsure of what defining an application level standard protocol re= ally means. Is this changes to http? Something that runs beside http? Inste= ad of? Over? Thanks, Peter Musgrave On 2010-12-13, at 10:39 AM, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote: Hi everybody, Here is the charter proposal for Q4S ( Quality for service) WG. This WG wil= l include the achieved works with "Q-HTTP" Thanks for your comments Description of Working group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Problem Statement: The QoS over Internet is a hot issue today. Current QoS handling mechanisms used in modern network transport layers (MPLS, RSVP, Diffserv,Traffic Engineering) do not provide themselves a QoS-on-demand end-to-end solution and existing adaptative solutions based on In-band Control protocols (such as RTCP) are very difficult to combine with any other protocols for which they have not been designed for. Four Network Parameters comprises the QoS at application level: Bandwidth, packet-loss, latency and Jitter. Interactive-video applications define flows in both directions. Different applications require different constraints (in terms of latency, jitter, packet loss) in one or both directions and different responsiveness. The proposed solution must be an effective out-of-band application level protocol capable of reacting when any of these constraints are violated. Such protocol must trigger adaptive solutions and/or QoS network profile changes. Currently content providers are only able to provide services based on adaptative methods or last-mille deployments which prefer dedicated network resources (vs. Internet), and therefore, restricts the subscriber population and increases the costs. Objetives: The goal of this working group is to define a QoS application-level standard protocol optimized for its use over the internet that may be widely implemented and easily managed by application developers and service providers. The core technical considerations for such protocol include, but are not necessarily limited to, the following: 1. Protocol design to be used in interactive applications (including virtualized videogames,and interative-video applications) 2. Ensuring interoperability with all existing transport protocols 3. Optimizing for low bit rates (typlically below 2.4 kbps) 4. To ensure a feasible practical implementation based on policy servers and interoperability between service providers Deliverables: 1. Specification of protocol that meets the requirements in the form of an Internet-Draft that defines the negotiation of QoS parameters, the measurement process and alert mechanisms. 2. Dimensioning rules and performance analysis 3. A set of technical requirements for a practical implementation which may include adaptative solutions and/or QoS profile modification. Goals and Milestiones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nov 2010 Submit Internet-Draft as a proposed standard for QoS application-level protocol Proposed charter for Q4S WG Informational document with rules for dimensioning and performance analysis Specification of architecture document for implementation - Jose Javier _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_3349FECF788C984BB34176D70A51782F18464DB5FRMRSSXCHMBSB3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= BASE=20 href=3Dx-msg://155/>
 
Hi Peter&nb= sp;,=20 all 
 
relation with rtcweb
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
rtcweb try to identify and find a consensus on a= =20  set of components to communicate universally for real-time communicat= ions.=20 Inside this approach, Q4S protocol could be part of this set of agreed=20 protocols. The intention of rtcweb is to standarize as much as possible, wi= thout=20 leaving these set of protocols or functionalities in the scope of web=20 applications or plug-ins for browsers. We believe that a standari= zed=20 protocol for Quality measurements and alerts would be interesting for all=20 internet community because if we compare a Q4S standard protocol  with= =20 propietary solutions, we found that the range of benefited applications and= the=20 number of possible implementations are higher with a standardized=20 solution.
In addition a multi-ISP solution could be reache= d using=20 a standard protocol, in which each peer of communication belongs to a diffe= rent=20 ISP and possibilities based on Q4S protocol are available for QoS profile=20 managemen.
 
 
relation with http
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
The=20 measurement and/or alert in realtime functions would be  covered = by=20 the Q4S wg, in particular the Q - HTTP protocol ( which may be= =20 renamed to Q4S or other name).
This=20 protocol (formerly named Q-HTTP) uses HTTP syntax, and uses specific=20 URI for easy integration in www. However can be used out of www=20 context.  In=20 fact,  the protocol is not an http extension.  It is an out-of-band protocol to me= asure=20 and alert participants of a communication based in any protocol ( http coul= d be=20 the protocol to transmit application data and Q-HTTP the protocol to monito= r the=20 quality end2end).  The protocol can be used in conjuntion with any oth= er=20 protocol used for application data transport (HTTP, FTP, RTP, whatever) . I= n=20 fact, Q-HTTP is not used  to=20  transpor t  = data,=20 but for measurement the latency, jitter, packetloss end2end and alert if so= me=20 thresholds are being violated for trigger adaptative solutions or changes i= n QoS=20 profile.
 
 
The=20 concrete adatative solution or how the QoS profile is changed is out of sco= pe of=20 the protocol. The protocol only monitor and send an alert, that is useful t= o=20 know when these types of actions should be taken
 
 
- jose javier=

 
De: Peter Musgrave=20 [mailto:peter.musgrave@magorcorp.com]
Enviado el: viernes, 17 de= =20 diciembre de 2010 12:57
Para: GARCIA ARANDA, JOSE JAVIER (JOSE=20 JAVIER)
CC: 'dispatch@ietf.org'; pedrochas@dit.upm.es; CUBILLO PA= STOR,=20 CLARA (CLARA); ORTIGA HERRERA, GUADALUPE (GUADALUPE); jquemada@dit.upm.es;= =20 HERRANZ PABLO, SONIA (SONIA); gabriel@dit.upm.es; barcenilla@dit.upm.es;=20 jsr@dit.upm.es; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
Asunto: = Re:=20 [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version=20 1

Hi Jose, =20

Can you comment on the relationship of this work to the rtcweb drafts= =20 currently in dispatch? Those seems to me a method to use existing protocols= to=20 solve very similar issues. 

I am also unsure of what defining an application level standard protoc= ol=20 really means. Is this changes to http? Something that runs beside http? Ins= tead=20 of? Over?

Thanks, 

Peter Musgrave


On 2010-12-13, at 10:39 AM, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)=20 wrote:

 
Hi everybody,
 
Here is the charter proposal for Q4S ( Quality for se= rvice)=20 WG. This WG will include the achieved works with  "Q-HTTP"
 
Thanks for your comments
 
 
Description of Workin= g=20 group
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
 
   Problem= =20 Statement:
 
   The QoS = over=20 Internet is a hot issue today. Current QoS handling
   mechanis= ms used=20 in  modern network transport layers (MPLS, RSVP,
   Diffserv= ,Traffic=20 Engineering) do not provide  themselves a
   QoS-on-d= emand=20 end-to-end solution and existing adaptative
   solution= s based=20 on In-band Control protocols (such as RTCP)
   are very= =20 difficult to combine with any other protocols for which
   they hav= e not=20 been designed for.
 
   Four Net= work=20 Parameters comprises the QoS at application level:
   Bandwidt= h,=20 packet-loss, latency and Jitter.
 
   Interact= ive-video=20 applications define flows in both directions.
   Differen= t=20 applications require different constraints (in terms of
   latency,= jitter,=20 packet loss) in one or both directions and
   differen= t=20 responsiveness. The proposed solution must be an
   effectiv= e=20 out-of-band application level protocol capable of
   reacting= when any=20 of these constraints are violated. Such protocol
   must tri= gger=20 adaptive solutions and/or QoS network profile changes.
 
   Currentl= y content=20 providers are only able to provide services based
   on adapt= ative=20 methods or last-mille deployments which prefer
   dedicate= d network=20 resources (vs. Internet), and therefore, restricts
   the subs= criber=20 population and increases the costs.
 
  =20 Objetives:
 
   The goal= of this=20 working group is to define a
   QoS=20 application-level  standard protocol optimized for its use=20 over
   the inte= rnet that=20 may be widely implemented and easily managed
   by appli= cation=20 developers and service providers.
 
   The core= =20 technical considerations for such protocol include, but
   are not= =20 necessarily limited to, the following:
 
   1. Proto= col=20 design to be used in interactive applications (including
   &nb= sp; =20 virtualized videogames,and interative-video applications)
 
   2. Ensur= ing=20 interoperability with all existing transport protocols
 
   3. Optim= izing for=20 low bit rates (typlically below 2.4 kbps)
 
   4. To en= sure a=20 feasible practical implementation based on
   &nb= sp; =20 policy servers and interoperability between service providers
 
 
  =20 Deliverables:
 
   1. Speci= fication=20 of protocol that meets the requirements in the
   &nb= sp; =20 form of an Internet-Draft that defines the negotiation of QoS
   &nb= sp; =20 parameters, the measurement process and alert mechanisms.
 
   2. Dimen= sioning=20 rules and performance analysis
 
   3. A set= of=20 technical requirements for a practical
   &nb= sp; =20 implementation which may include adaptative solutions and/or
   &nb= sp; =20 QoS profile modification.
 
 
Goals and=20 Milestiones
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /FONT>
 
Nov 2010  &= nbsp;=20 Submit Internet-Draft as a proposed standard for QoS
          &nbs= p; =20 application-level protocol
 
          &nbs= p; =20 Proposed charter for Q4S WG
 
          &nbs= p; =20 Informational document with rules for dimensioning
          &nbs= p; =20 and performance analysis
 
          &nbs= p; =20 Specification of architecture document for implementation
 
 
 
 
 
 
- Jose Javier
 
 
 
 
______________________________________= _________
dispatch=20 mailing list
dispatch@ietf.org
https://www.ietf.= org/mailman/listinfo/dispatch

--_000_3349FECF788C984BB34176D70A51782F18464DB5FRMRSSXCHMBSB3d_-- From harald@alvestrand.no Mon Dec 20 01:59:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EFC93A69C0 for ; Mon, 20 Dec 2010 01:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.283 X-Spam-Level: X-Spam-Status: No, score=-102.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25mWxR6kclXD for ; Mon, 20 Dec 2010 01:58:54 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id B89343A6A22 for ; Mon, 20 Dec 2010 01:58:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 659F139E12B; Mon, 20 Dec 2010 11:00:24 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItL2VSAnCw1h; Mon, 20 Dec 2010 11:00:14 +0100 (CET) Received: from [172.16.41.87] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C32EC39E0BC; Mon, 20 Dec 2010 11:00:04 +0100 (CET) Message-ID: <4D0F2932.7080600@alvestrand.no> Date: Mon, 20 Dec 2010 11:00:18 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Henry Sinnreich References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010502050703080504010309" Cc: dispatch@ietf.org, Lars Eggert Subject: Re: [dispatch] A Datagram Transport for the RTC-Web profile X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 09:59:13 -0000 This is a multi-part message in MIME format. --------------010502050703080504010309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Henry, thanks for your note! Shortform reply: - I think this is IETF ready at the present time. - I would enjoy seeing a CDN-based alternative written up, but don't believe in it. - I don't see a business case for adding HIP. - I'll reform the URI section. It was done in a rush, and not well. Details below. On 12/16/10 21:47, Henry Sinnreich wrote: > Hi Harald, > > I would like to add my thanks to Alan Johnston's note, this time to > your other I-D, [I-D: draft-alvestrand-dispatch-rtcweb-datagram-00] > since is a timely and welcome contribution to what may well turn out > to become the most exciting development in VoIP: Opening such as SIP > VoIP up from its separate applications environment, Internet or > telecom, into the mainstream world of applications, into the browser. > > Given the transformative potential we believe this has, maybe a > contrarian view to the solutions presented here is timely right now. > The Internet industry will produce solutions one way or another and > the challenge in our IETF work here is to develop a standard that is > most attractive to implementers. This is the focus in the message. Contrarian is good... it allows us to make our basic thinking clear. > > There is an obvious need to present, discuss and research various > options before developing any standard document. So here are some > comments when adopting a contrarian view. This is certainly not a > complete list nor does everything tie yet neatly together -- the > reason why we propose this work to be an IRTF (http://www.irtf.org/) > work item. Allow me to disagree.... my perception is that there is such a huge amount of existing practice (Skype, Google Talk Video, MSN Video, Adobe Connect, even ChatRoulette) that the field's experimentation phase is already well established, and may indeed be mostly behind us - the time is ripe (I think) to get some agreement on how to use the standard building blocks we have in an interoperable manner. This is not what the IRTF has been traditionally best at; it is rather a typical standards activity. > > Last but not least, as per your model, we discuss here only media > transport between browsers or between a browser and a possible RTC > server, such as a conference server. All issues of control, such as > rendezvous, session setup, etc. are out of scope. These topics are > addressed elsewhere. > > Missing items > ============= > > In sections 1.Introduction and 2.Terminology, the key distinction must > be added between streaming audio/video (a/v) media and interactive > real-time (RT) media for communications and other, such as games, to > which the title RTC is pointing. Why? At the datagram level, I don't see a distinction. Both A/V and non-A/V data have specific requirements for delivery probability, ordering and timeliness; the requirements are different, but both types of data have a need to have data packets delivered. I've had some comments about the "RTC" moniker before, but am not really sure what current/previous usage of the term refers to - could you help? > > "When transporting audio / video data between participants on the > current Internet, there are a number of obstacles to be faced." > Well, there is also really good news to be added: Content Distribution > Networks (CDN) support highest quality HDTV streaming to many millions > of users. CDN share something with the Internet: CDN are a general > purpose global platform that while keeping to basic HTTP protocol > support enables an endless stream of innovations that require no > network upgrades for new Web applications. CDN are also scalable > Internet style. See below how CDN could also serve as relays for RT media. I wasn't aware that CDNs had any relationship to real-time communication; will look forward to studying the details on this. Google actively uses relays to get around firewalls, and of course there is a long (and sad) history of using multicast, either at the network layer or the application layer, to get distribution trees for media, but I hadn't been aware that the CDN name was being used for this type of functionality. > > Another missing item seems to be any emphasis on the handling of media > for P2P RTC in the browser, arguably the ultimate communication > solution for many reasons, such as lowest cost of ownership, instant > scalability for peak traffic events. Would not P2P media run inside a > VPN-like network over HIP, as discussed below make a most attractive > option? Please elucidate - I may be getting some terminology wrong, but I simply don't get this. What do you mean by "handling of media for P2P RTC", what is "ultimate" about the communcation solution, and what is the scalability property you wish to explore? > > Last but not least, actually the most important for tens of millions > of Web app developers is the complete integration with all and any web > applications and integration into web development tools, such as > graphic Integrated Development Environments (IDE). > How can the required protocol expertise on media, as required here be > best hidden from app developers, so they are not discouraged from > using it? Consider me a dinosaur, but I still develop Java code in Emacs, and have friends who do Javascript in vi; I consider the hiding of properties of underlying systems a failure of our education system, which has led to fundamental architectural mistakes in the past (such as Tim Berners Lee's belief that setting up a connection across the Internet was a simple thing, and therefore reasonable to do at each request of his newly-concieved HTTP protocol). I believe that if we get a clean and comprehensible model out at the protocol specs level, and a clean and comprehensible API out at the Javascript / DOM level, the IDEs will follow when they need to. > > Unnecessary Complexity: Are there better options? Which? > > The Datagram Model that is presented in section 3.Service model. Being > an assembly of very complex constructs to be found in recent IETF > documents, arguably weighs down the Service model. This contradicts > the golden design rule that engineering is finished only when it can > be made no simpler and no more. > We also miss here a discussion of design options and the criteria for > picking any particular choice. Discussing such options in detail are > key to choosing and defending an approach for RT Web communications. Well... the model is dependent on IP, UDP and ICE. That's it. Its definition references some rather hefty specs, including PseudoTCP (unspecified) and RTP, but does not depend on them. Of those three, IP and UDP are necessary, and simple. ICE is complex, but is itself a result of multiple iterations of the "try to make things simpler, find that simpler solutions don't work for significant use cases, back off". > > > Alternate options for RT Web media > ============================== > > Missing the option of using just UDP and application level scheduling > without any other protocols. My understanding is that Skype for > example has proven such an approach for interactive a/v. Skype does > not use RTP. Neither do Apple TV, Flash video and others for streaming > media. And neither do they interoperate with each other, or with anything else. (Flash video does interoperate with some other stuff, as proven by the flash-based version of Google Talk Video). Application-over-UDP would require that we have one single spec that specifies all of the layers from the application down to UDP, including firewall / NAT traversal, codecs and so on. This seems like an approach that is anathema to the "building blocks" approach of IETF standardization. > > Another approach, also well proven for CDN is streaming HTTP. > Bidirectional HTTP and Streaming HTTP is the object of present IETF > work and it would make sense to benefit from it. Streaming HTTP is TCP-based, and TCP has long been thought to be inappropriate for real-time interactive media; it is a commonly used fallback for the cases where UDP doesn't get through, but is problematic because of the high jitter that can result from packet loss due to sequential retransmission. One of the design criteria for this work was direct browser-to-browser communication without intermediaries; the only technique I know of that works through firewalls and NATs is simultaneous-open TCP, which has a not-stellar success rate. > > > Sample scenarios for using HTTP for media transport in RTC: > > · Users are inside a single ISP, within a small geographical area > and the nearest CDN HTTP proxy serves as the media relay. A suitable > a/v codec packetization and sequencing from the end point browser > based apps can easily meet the required delay, such as less than 150 > ms end-to-end. The CDN HTTP proxy has to be instructed not to cache > this stream and is used 'as is'. As noted above, this means that we drop the requirement for direct browser-to-browser communication even for the one-on-one case. I don't believe this would be acceptable to a majority of participants. > > · Some users are geographically remote and in different ISPs. In > this case, the CDN owned fiber backbones might prove to be an > alternative to the congestion experienced from peering and backhaul. > Here too the huge CDN infrastructure is used 'as is'. Again, this means we're dropping direct traffic - or alternatively, that we're demanding two modes for the implementation, one direct and one using a CDN (or other relay). Do we then require that all communicating users are connected to the same CDN, or are we requiring that for service to be universal, there has to be an universal open CDN peering policy? Both of those seem like reasonably challenging propositions. > > Alternate Options for NAT traversal > =================================== Actually this is not an option for NAT traversal, it's an option for a different network layer. I've been fascinated by HIP ever since it was first proposed by Bob Moskwitz, especially since it seemed at the time to offer a cleaner ID/Locator split than either IPv4 or IPv6 - but it's never been a solution that was great for incremental deployment in scenarios where some degre of interworking with older equipment was required. Currently, HIP seems to deploy on top of UDP, so it's actually an additional layer of protocol compared to the proposal in the draft. > > Instead of using ICE as in RFC 5245 that is described specifically for > SIP, why not using ICE as specified 5750 for HIP since it has the > following benefits: The RFC number is wrong... it's 5770. It refers to RFC 5245 for its actual ICE specifics, and OpenHIP at least now runs by default over UDP, so the complexity of an ICE-over-HIP solution is not lower than an ICE-over-UDP solution. > > · ICE for HIP works for all application layer protocols and has > all the benefit of a generic solution Only for those application layer protocols that have a defined mapping to HIP, of course - and it will fail to interwork with the same application layer protocols over non-HIP. > · HIP supports also IPv6 transition, mobility and multi-homing > · HIP provides VPN-like security for both media and control, thus > meeting the criteria for simplicity in our contrarian approach. At the cost of any sort of interoperability with non-HIP, of course. > > Things to disagree with > ======================= > > The URI schema for datagram channels contradicts both the Internet and > Web architectural principles: > > 1. Registration of URIs contradict the loose coupling and scalability > of the Web architecture (reference) Sorry, I don't understand this. Could you elucidate? > 2. The URI registration template uses IP addresses. This contradicts > the IAB UNSAF RFC 3424 and is also one of the main weaknesses of SDP > in SIP, since the IP addresses are not information, but rather > disinformation; many intermediaries along the path will change them > unfortunately. By contrast, HIP works end-to-end like the User Space > VPN and is better positioned to handle this. The are no intermediaries > inside the VPN-like network established over HIP. Actually I was trying to represent exactly the same information as a set of ICE "a=candidate" SDP attribute (RFC 5245 section 15.1), without having read the spec for that attribute before writing what I wrote; I'll make sure to reference that spec properly and be compatible with it. My opinion about the usage of IP addresses in SIP is too voluminous to fit within the confines of this note; the whole section may be a candidate for being dropped if it turns out that the API work to be performed in the W3C can use "a=candidate" sets rather than wanting to use URIs. > 3. Why not enjoy also the flexibility not to use only DNS names for > the media description, but rather P2P names, such as in Skype? > Caution, we may open here a can of worms, but this is important as > well. It must be IMO also part of discussing the design options. Yes, it's a can of worms, since there is no referenceable document for "P2P names", nor a documented way to dereference "P2P names". I am very much disinclined to make this specification depend on undefined terms. > > Missing sections: Discussion and Conclusions > ============================================ > > The key item to discuss is if the approach in this draft meets the > basic engineering criteria: The design is the simplest possible and > nothing remains to be taken away to make it simpler and no more. (slightly tongue-in-cheek) Other efforts have made the experience that there's more disagreement about the justification than about the specification; thus, by the same engineering criteria, leaving out the discussion may make the spec simpler.... > > My conclusion is the I-D is a welcome start of work on RT interactive > communications on the web, but the approach presented, though formally > compliant with the most recent IETF application area standards work > may not be the most simple. Therefore it may not be the most > successful in the market. > > Recommendations > =============== > > The discussions of other options, such as the examples recommended > here require detailed discussions, prototyping and testing before > adopting anything resembling a standard proposal. For this reason we > suggest the RTC Web work should continue within the Internet Research > Task Force (IRTF) and I have taken the liberty to copy the IRTF Chair > Lars Eggert for this purpose. Possible work items include: > > · What is the complexity, for example measured in the number of > messages and protocol support required in the present RTC Web I-D as is? > · List and comparison of alternatives? (Such as using CDN, HIP > and P2P) Another approach is of course to ask the proponents of alternate approaches to describe them in such a way that the relative merits can be compared. In particular, I would enjoy seeing a specification of the CDN approach that was specified to a level that allows independent, interoperable implementation, since I'm not knowledgeable enough about the standardized interfaces to the CDNs to be able to produce such a document at this time. > · Would a SIP API standard and RTC Web constitute a complete > solution? If not, what is missing? It is interesting to ask "a complete solution to what". I've asked some other people to consider taking on the task of writing scenarios documents that can be used to drive requirements, but at the moment, no documents are on the table. My personal short-form is "if I can implement Google Talk Video and ChatRoulette on top of these interfaces without a plugin in the browser, it's a solution to something; if I can't, it isn't". > · Scenarios and business models. Who pays the CDN for RTC? > Business innovation is impossible to predict, but must be enabled by > providing the tools and flexibility inherent in the Darwinian Web to > the genius of application developers. Indeed, that is a good question, and one reason why I don't want to build a protocol suite that can only be used in the presence of CDNs. > · Prototypes and test reports. > > It can be argued that sending this work to the IRTF will introduce a > delay, but as mentioned, the Internet industry will produce solutions > one way or another and the challenge in the IETF work here is to > develop a standard that is most attractive to app developers and to > implementers. > See also "What Makes for a Successful Protocol", RFC 5218. An important document to read, indeed. > > Thanks, Henry > > > > > --------------010502050703080504010309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Henry,

thanks for your note!

Shortform reply:

- I think this is IETF ready at the present time.
- I would enjoy seeing a CDN-based alternative written up, but don't believe in it.
- I don't see a business case for adding HIP.
- I'll reform the URI section. It was done in a rush, and not well.

Details below.

On 12/16/10 21:47, Henry Sinnreich wrote:
A Datagram Transport for the RTC-Web profile Hi Harald,
 
I would like to add my thanks to Alan Johnston’s note, this time to your other I-D, [I-D: draft-alvestrand-dispatch-rtcweb-datagram-00] since is a timely and welcome contribution to what may well turn out to become the most exciting development in VoIP: Opening such as SIP VoIP up from its separate applications environment, Internet or telecom, into the mainstream world of applications, into the browser.
 
Given the transformative potential we believe this has, maybe a contrarian view to the solutions presented here is timely right now. The Internet industry will produce solutions one way or another and the challenge in our IETF work here is to develop a standard that is most attractive to implementers. This is the focus in the message.
Contrarian is good... it allows us to make our basic thinking clear.
 
There is an obvious need to present, discuss and research various options before developing any standard document. So here are some comments when adopting a contrarian view. This is certainly not a complete list nor does everything tie yet neatly together – the reason why we propose this work to be an IRTF (http://www.irtf.org/) work item.
Allow me to disagree.... my perception is that there is such a huge amount of existing practice (Skype, Google Talk Video, MSN Video, Adobe Connect, even ChatRoulette) that the field's experimentation phase is already well established, and may indeed be mostly behind us - the time is ripe (I think) to get some agreement on how to use the standard building blocks we have in an interoperable manner. This is not what the IRTF has been traditionally best at; it is rather a typical standards activity.
 
Last but not least, as per your model, we discuss here only media transport between browsers or between a browser and a possible RTC server, such as a conference server. All issues of control, such as rendezvous, session setup, etc. are out of scope. These topics are addressed elsewhere.
 
Missing items
=============
 
In sections 1.Introduction and 2.Terminology, the key distinction must be added between streaming audio/video (a/v) media and interactive real-time (RT) media for communications and other, such as games, to which the title RTC is pointing.
Why?

At the datagram level, I don't see a distinction. Both A/V and non-A/V data have specific requirements for delivery probability, ordering and timeliness; the requirements are different, but both types of data have a need to have data packets delivered.

I've had some comments about the "RTC" moniker before, but am not really sure what current/previous usage of the term refers to - could you help?
 
“When transporting audio / video data between participants on the current Internet, there are a number of obstacles to be faced.”
Well, there is also really good news to be added: Content Distribution Networks (CDN) support highest quality HDTV streaming to many millions of users. CDN share something with the Internet: CDN are a general purpose global platform that while keeping to basic HTTP protocol support enables an endless stream of innovations that require no network upgrades for new Web applications. CDN are also scalable Internet style. See below how CDN could also serve as relays for RT media.
I wasn't aware that CDNs had any relationship to real-time communication; will look forward to studying the details on this. Google actively uses relays to get around firewalls, and of course there is a long (and sad) history of using multicast, either at the network layer or the application layer, to get distribution trees for media, but I hadn't been aware that the CDN name was being used for this type of functionality.
 
Another missing item seems to be any emphasis on the handling of media for P2P RTC in the browser, arguably the ultimate communication solution for many reasons, such as lowest cost of ownership, instant scalability for peak traffic events. Would not P2P media run inside a VPN-like network over HIP, as discussed below make a most attractive option?
Please elucidate - I may be getting some terminology wrong, but I simply don't get this. What do you mean by "handling of media for P2P RTC", what is "ultimate" about the communcation solution, and what is the scalability property you wish to explore?
 
Last but not least, actually the most important for tens of millions of Web app developers is the complete integration with all and any web applications and integration into web development tools, such as graphic Integrated Development Environments (IDE).
How can the required protocol expertise on media, as required here be best hidden from app developers, so they are not discouraged from using it?
Consider me a dinosaur, but I still develop Java code in Emacs, and have friends who do Javascript in vi; I consider the hiding of properties of underlying systems a failure of our education system, which has led to fundamental architectural mistakes in the past (such as Tim Berners Lee's belief that setting up a connection across the Internet was a simple thing, and therefore reasonable to do at each request of his newly-concieved HTTP protocol).

I believe that if we get a clean and comprehensible model out at the protocol specs level, and a clean and comprehensible API out at the Javascript / DOM level, the IDEs will follow when they need to.
 
Unnecessary Complexity: Are there better options? Which?
 
The Datagram Model that is presented in section 3.Service model. Being an assembly of very complex constructs to be found in recent IETF documents, arguably weighs down the Service model. This contradicts the golden design rule that engineering is finished only when it can be made no simpler and no more.
We also miss here a discussion of design options and the criteria for picking any particular choice. Discussing such options in detail are key to choosing and defending an approach for RT Web communications.
Well... the model is dependent on IP, UDP and ICE. That's it.
Its definition references some rather hefty specs, including PseudoTCP (unspecified) and RTP, but does not depend on them.

Of those three, IP and UDP are necessary, and simple. ICE is complex, but is itself a result of multiple iterations of the "try to make things simpler, find that simpler solutions don't work for significant use cases, back off".
 
 
Alternate options for RT Web media
==============================
 
Missing the option of using just UDP and application level scheduling without any other protocols. My understanding is that Skype for example has proven such an approach for interactive a/v. Skype does not use RTP. Neither do Apple TV, Flash video and others for streaming media.
And neither do they interoperate with each other, or with anything else. (Flash video does interoperate with some other stuff, as proven by the flash-based version of Google Talk Video).

Application-over-UDP would require that we have one single spec that specifies all of the layers from the application down to UDP, including firewall / NAT traversal, codecs and so on. This seems like an approach that is anathema to the "building blocks" approach of IETF standardization.
 
Another approach, also well proven for CDN is streaming HTTP. Bidirectional HTTP and Streaming HTTP is the object of present IETF work and it would make sense to benefit from it.
Streaming HTTP is TCP-based, and TCP has long been thought to be inappropriate for real-time interactive media; it is a commonly used fallback for the cases where UDP doesn't get through, but is problematic because of the high jitter that can result from packet loss due to sequential retransmission.

One of the design criteria for this work was direct browser-to-browser communication without intermediaries; the only technique I know of that works through firewalls and NATs is simultaneous-open TCP, which has a not-stellar success rate.

 
Sample scenarios for using HTTP for media transport in RTC:
 
·      Users are inside a single ISP, within a small geographical area and the nearest CDN HTTP proxy serves as the media relay. A suitable a/v codec packetization and sequencing from the end point browser based apps can easily meet the required delay, such as less than 150 ms end-to-end. The CDN HTTP proxy has to be instructed not to cache this stream and is used ‘as is’.
As noted above, this means that we drop the requirement for direct browser-to-browser communication even for the one-on-one case. I don't believe this would be acceptable to a majority of participants.
 
·      Some users are geographically remote and in different ISPs. In this case, the CDN owned fiber backbones might prove to be an alternative to the congestion experienced from peering and backhaul. Here too the huge CDN infrastructure is used ‘as is’.
Again, this means we're dropping direct traffic - or alternatively, that we're demanding two modes for the implementation, one direct and one using a CDN (or other relay).

Do we then require that all communicating users are connected to the same CDN, or are we requiring that for service to be universal, there has to be an universal open CDN peering policy? Both of those seem like reasonably challenging propositions.
 
Alternate Options for NAT traversal
===================================
Actually this is not an option for NAT traversal, it's an option for a different network layer.
I've been fascinated by HIP ever since it was first proposed by Bob Moskwitz, especially since it seemed at the time to offer a cleaner ID/Locator split than either IPv4 or IPv6 - but it's never been a solution that was great for incremental deployment in scenarios where some degre of interworking with older equipment was required.

Currently, HIP seems to deploy on top of UDP, so it's actually an additional layer of protocol compared to the proposal in the draft.
 
Instead of using ICE as in RFC 5245 that is described specifically for SIP, why not using ICE as specified 5750 for HIP since it has the following benefits:
The RFC number is wrong... it's 5770. It refers to RFC 5245 for its actual ICE specifics, and OpenHIP at least now runs by default over UDP, so the complexity of an ICE-over-HIP solution is not lower than an ICE-over-UDP solution.
 
·      ICE for HIP works for all application layer protocols and has all the benefit of a generic solution
Only for those application layer protocols that have a defined mapping to HIP, of course - and it will fail to interwork with the same application layer protocols over non-HIP.
·      HIP supports also IPv6 transition, mobility and multi-homing
·      HIP provides VPN-like security for both media and control, thus meeting the criteria for simplicity in our contrarian approach.
At the cost of any sort of interoperability with non-HIP, of course.
 
Things to disagree with
=======================
 
The URI schema for datagram channels contradicts both the Internet and Web architectural principles:
 
1.  Registration of URIs contradict the loose coupling and scalability of the Web architecture (reference)
Sorry, I don't understand this. Could you elucidate?
2.  The URI registration template uses IP addresses. This contradicts the IAB UNSAF RFC 3424 and is also one of the main weaknesses of SDP in SIP, since the IP addresses are not information, but rather disinformation; many intermediaries along the path will change them unfortunately. By contrast, HIP works end-to-end like the User Space VPN and is better positioned to handle this. The are no intermediaries inside the VPN-like network established over HIP.
Actually I was trying to represent exactly the same information as a set of ICE "a=candidate" SDP attribute (RFC 5245 section 15.1), without having read the spec for that attribute before writing what I wrote; I'll make sure to reference that spec properly and be compatible with it.

My opinion about the usage of IP addresses in SIP is too voluminous to fit within the confines of this note; the whole section may be a candidate for being dropped if it turns out that the API work to be performed in the W3C can use "a=candidate" sets rather than wanting to use URIs.
3.  Why not enjoy also the flexibility not to use only DNS names for the media description, but rather P2P names, such as in Skype? Caution, we may open here a can of worms, but this is important as well. It must be IMO also part of discussing the design options.
Yes, it's a can of worms, since there is no referenceable document for "P2P names", nor a documented way to dereference "P2P names". I am very much disinclined to make this specification depend on undefined terms.
 
Missing sections: Discussion and Conclusions
============================================
 
The key item to discuss is if the approach in this draft meets the basic engineering criteria: The design is the simplest possible and nothing remains to be taken away to make it simpler and no more.
(slightly tongue-in-cheek) Other efforts have made the experience that there's more disagreement about the justification than about the specification; thus, by the same engineering criteria, leaving out the discussion may make the spec simpler....
 
My conclusion is the I-D is a welcome start of work on RT interactive communications on the web, but the approach presented, though formally compliant with the most recent IETF application area standards work may not be the most simple. Therefore it may not be the most successful in the market.
 
Recommendations
===============
 
The discussions of other options, such as the examples recommended here require detailed discussions, prototyping and testing before adopting anything resembling a standard proposal. For this reason we suggest the RTC Web work should continue within the Internet Research Task Force (IRTF) and I have taken the liberty to copy the IRTF Chair Lars Eggert for this purpose. Possible work items include:
 
·      What is the complexity, for example measured in the number of messages and protocol support required in the present RTC Web I-D as is?
·      List and comparison of alternatives? (Such as using CDN, HIP and P2P)
Another approach is of course to ask the proponents of alternate approaches to describe them in such a way that the relative merits can be compared. In particular, I would enjoy seeing a specification of the CDN approach that was specified to a level that allows independent, interoperable implementation, since I'm not knowledgeable enough about the standardized interfaces to the CDNs to be able to produce such a document at this time.
·      Would a SIP API standard and RTC Web constitute a complete solution? If not, what is missing?
It is interesting to ask "a complete solution to what". I've asked some other people to consider taking on the task of writing scenarios documents that can be used to drive requirements, but at the moment, no documents are on the table.

My personal short-form is "if I can implement Google Talk Video and ChatRoulette on top of these interfaces without a plugin in the browser, it's a solution to something; if I can't, it isn't".
·      Scenarios and business models. Who pays the CDN for RTC? Business innovation is impossible to predict, but must be enabled by providing the tools and flexibility inherent in the Darwinian Web to the genius of application developers.

Indeed, that is a good question, and one reason why I don't want to build a protocol suite that can only be used in the presence of CDNs.

·      Prototypes and test reports.
 
It can be argued that sending this work to the IRTF will introduce a delay, but as mentioned, the Internet industry will produce solutions one way or another and the challenge in the IETF work here is to develop a standard that is most attractive to app developers and to implementers.
See also “What Makes for a Successful Protocol”, RFC 5218.
An important document to read, indeed.
 
Thanks, Henry
 
 
 
 
 

--------------010502050703080504010309-- From gao.yang2@zte.com.cn Mon Dec 20 02:50:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1513A6817 for ; Mon, 20 Dec 2010 02:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Vi9m8uJsDR7 for ; Mon, 20 Dec 2010 02:50:26 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 463AB3A6813 for ; Mon, 20 Dec 2010 02:50:25 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 3510992332426; Mon, 20 Dec 2010 18:50:32 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 55813.992332426; Mon, 20 Dec 2010 18:52:13 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id oBKAqGXA081946 for ; Mon, 20 Dec 2010 18:52:16 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: dispatch@ietf.org MIME-Version: 1.0 X-KeepSent: 1BE477B7:0BD2FA41-482577FF:0039E44D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 20 Dec 2010 18:49:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-12-20 18:51:59, Serialize complete at 2010-12-20 18:51:59 Content-Type: multipart/alternative; boundary="=_alternative 003BB2B9482577FF_=" X-MAIL: mse2.zte.com.cn oBKAqGXA081946 Subject: [dispatch] Embedded SIP sessions as the Video/Audio Elements in HTML5: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 10:50:27 -0000 This is a multipart message in MIME format. --=_alternative 003BB2B9482577FF_= Content-Type: text/plain; charset="US-ASCII" Hi, >From web's perspective, this might be one easy way for realtime session/streaming in the Web. And from telecom's perspective, this is one way to open the telecom's core network's multimedia capability to the Web. There are might be some sub-topics, such as API(enhancement for SIP servlet,JSR289?),architecture and so on. Has anyone have the same interesting? Thanks, Gao =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 003BB2B9482577FF_= Content-Type: text/html; charset="US-ASCII"
Hi,

From web's perspective, this might be one easy way for realtime session/streaming in the Web. And from telecom's perspective, this is one way to open the telecom's core network's multimedia capability to the Web.

There are might be some sub-topics, such as API(enhancement for SIP servlet,JSR289?),architecture and so on. Has anyone have the same interesting?

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 003BB2B9482577FF_=-- From harald@alvestrand.no Mon Dec 20 05:46:01 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E27B3A6899 for ; Mon, 20 Dec 2010 05:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.52 X-Spam-Level: X-Spam-Status: No, score=-103.52 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7J5Nxe-jjM6U for ; Mon, 20 Dec 2010 05:46:00 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id DCF853A6895 for ; Mon, 20 Dec 2010 05:45:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4709339E138; Mon, 20 Dec 2010 14:47:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNoAOVPYrUde; Mon, 20 Dec 2010 14:47:29 +0100 (CET) Received: from [172.16.41.87] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 2512039E0BC; Mon, 20 Dec 2010 14:47:29 +0100 (CET) Message-ID: <4D0F5E85.5030408@alvestrand.no> Date: Mon, 20 Dec 2010 14:47:49 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alan Johnston References: <4CDA833D.8080203@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 13:46:01 -0000 On 12/15/10 18:09, Alan Johnston wrote: > Harald, > > Thanks for kicking off this work with your drafts. I know a lot of us > are greatly looking forward to starting this work after thinking and > talking about it for a long time. > > My thinking is basically aligned with your draft. However, I think we > need a little more clarity on exactly what we are trying to do: > exactly how do all the components talk to you each other using > standard protocols or APIs? I found your datagram session URI > proposal in the other draft a little hard to understand - I think we > will need good requirements before we can decide if this is the right > mechanism. I think the API work will be handled in W3C, and described in the form of Javascript - one central issue is that various components will have to send media to each other *without* going through the Javascript level - this is AFAIK relatively new territory for all concerned. > I also understand your arguments on connection management, which is > really signaling. I agree that it is possible for this to be a local > matter between a web browser and a web server, and that establishing > voice sessions from within a web domain can be handled without > standards, and voice sessions between web domains could be signaled > using existing standards such as SIP. > > However, I do think there is value in standardizing some kind of > lightweight API for signaling between the browser and server. Some > of us have been thinking about this for a while now: > > http://tools.ietf.org/html//draft-sinnreich-sip-web-apis > http://tools.ietf.org/html/draft-peterson-sipcore-advprop > > The good news is that this work is completely orthogonal to the mainly > media work you propose in your draft. But it does tie in nicely and > helps provide a fully interoperable set of protocols/APIs, which > ultimately is what the IETF is all about. I don't see any need for > one effort to delay the other - in fact, both could potentially be > done in separate working groups. Thanks for the pointers - will certainly read up on these! > Finally, a comment on the name for the overall effort - I know, really > important stuff... The acronym RTC has baggage in our industry, and > it might be nice avoid yet another three letter acronym ;-). I was > thinking about Web RTCom, short for Web Real Time Communications. Names are the ultimate timesink in discussion :-) - somewhat tongue-in-cheek, I wonder if the best approach is if everyone with a proposed name sends them to the BOF in Prague, we put them all in a hat, and then draw one at random :-) > - Alan - > > > > On Wed, Nov 10, 2010 at 5:34 AM, Harald Alvestrand wrote: >> This is the overview document for the IETF-related RTC-WEB work. >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 >> Date: Wed, 10 Nov 2010 03:31:05 -0800 (PST) >> From: IETF I-D Submission Tool >> To: harald@alvestrand.no >> >> A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. >> >> Filename: draft-alvestrand-dispatch-rtcweb-protocols >> Revision: 00 >> Title: Overview: Real Time Protocols for Brower-based Applications >> Creation_date: 2010-11-11 >> WG ID: Independent Submission >> Number_of_pages: 9 >> >> Abstract: >> This document gives an overview of a protocol suite intended for use >> with real-time applications that can be deployed in browsers - "real >> time communication on the Web". >> >> It intends to serve as a starting and coordination point to make sure >> all the parts that are needed to achieve this goal are findable, and >> that the parts that belong in the Internet protocol suite are fully >> specified and on the right publication track. >> >> This work is an attempt to synthesize the input of many people, but >> makes no claims to fully represent the views of any of them. All >> parts of the document should be regarded as open for discussion. >> >> >> >> The IETF Secretariat. >> >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From harald@alvestrand.no Mon Dec 20 05:34:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EEBD3A6891 for ; Mon, 20 Dec 2010 05:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7Mt--WKJa3w for ; Mon, 20 Dec 2010 05:34:36 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 77C923A67B3 for ; Mon, 20 Dec 2010 05:34:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2041139E12B; Mon, 20 Dec 2010 14:36:07 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLZ244vmXNvl; Mon, 20 Dec 2010 14:36:06 +0100 (CET) Received: from [172.16.41.87] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 445E339E0BC; Mon, 20 Dec 2010 14:36:04 +0100 (CET) Message-ID: <4D0F5BD8.4040506@alvestrand.no> Date: Mon, 20 Dec 2010 14:36:24 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" References: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------080206080403010501030402" X-Mailman-Approved-At: Mon, 20 Dec 2010 07:37:28 -0800 Cc: "pedrochas@dit.upm.es" , "CUBILLO PASTOR, CLARA \(CLARA\)" , "ORTIGA HERRERA, GUADALUPE \(GUADALUPE\)" , "jquemada@dit.upm.es" , "'dispatch@ietf.org'" , "gabriel@dit.upm.es" , "barcenilla@dit.upm.es" , "jsr@dit.upm.es" , "HERRANZ PABLO, SONIA \(SONIA\)" , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" Subject: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 13:34:37 -0000 This is a multi-part message in MIME format. --------------080206080403010501030402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/13/10 16:39, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote: > Hi everybody, > Here is the charter proposal for Q4S ( Quality for service) WG. This > WG will include the achieved works with "Q-HTTP" Forgive me if this has been asked before.... does this approach (out-of-band measurements on a different set of ports/protocols than in fact used by the application) assume that the network is not doing deep packet inspection or differential treatment of services? Is there an interaction with DSCP packet marking - could the measurement setup specify DSCP codepoints to be set on packets (and, knowing that these are changed en route, report on the DSCP codepoints of incoming packets)? In both points, it would be nice if the charter said whether it was in or out of scope. Harald > Thanks for your comments > Description of Working group > ============================ > Problem Statement: > The QoS over Internet is a hot issue today. Current QoS handling > mechanisms used in modern network transport layers (MPLS, RSVP, > Diffserv,Traffic Engineering) do not provide themselves a > QoS-on-demand end-to-end solution and existing adaptative > solutions based on In-band Control protocols (such as RTCP) > are very difficult to combine with any other protocols for which > they have not been designed for. > Four Network Parameters comprises the QoS at application level: > Bandwidth, packet-loss, latency and Jitter. > Interactive-video applications define flows in both directions. > Different applications require different constraints (in terms of > latency, jitter, packet loss) in one or both directions and > different responsiveness. The proposed solution must be an > effective out-of-band application level protocol capable of > reacting when any of these constraints are violated. Such protocol > must trigger adaptive solutions and/or QoS network profile changes. > Currently content providers are only able to provide services based > on adaptative methods or last-mille deployments which prefer > dedicated network resources (vs. Internet), and therefore, restricts > the subscriber population and increases the costs. > Objetives: > The goal of this working group is to define a > QoS application-level standard protocol optimized for its use over > the internet that may be widely implemented and easily managed > by application developers and service providers. > The core technical considerations for such protocol include, but > are not necessarily limited to, the following: > 1. Protocol design to be used in interactive applications (including > virtualized videogames,and interative-video applications) > 2. Ensuring interoperability with all existing transport protocols > 3. Optimizing for low bit rates (typlically below 2.4 kbps) > 4. To ensure a feasible practical implementation based on > policy servers and interoperability between service providers > Deliverables: > 1. Specification of protocol that meets the requirements in the > form of an Internet-Draft that defines the negotiation of QoS > parameters, the measurement process and alert mechanisms. > 2. Dimensioning rules and performance analysis > 3. A set of technical requirements for a practical > implementation which may include adaptative solutions and/or > QoS profile modification. > Goals and Milestiones > ===================== > Nov 2010 Submit Internet-Draft as a proposed standard for QoS > application-level protocol > Proposed charter for Q4S WG > Informational document with rules for dimensioning > and performance analysis > Specification of architecture document for implementation > - Jose Javier > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------080206080403010501030402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 12/13/10 16:39, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote:
 
Hi everybody,
 
Here is the charter proposal for Q4S ( Quality for service) WG. This WG will include the achieved works with  "Q-HTTP"
Forgive me if this has been asked before....

does this approach (out-of-band measurements on a different set of ports/protocols than in fact used by the application) assume that the network is not doing deep packet inspection or differential treatment of services?

Is there an interaction with DSCP packet marking - could the measurement setup specify DSCP codepoints to be set on packets (and, knowing that these are changed en route, report on the DSCP codepoints of incoming packets)?

In both points, it would be nice if the charter said whether it was in or out of scope.

                      Harald

 
Thanks for your comments
 
 
Description of Working group
============================
 
   Problem Statement:
 
   The QoS over Internet is a hot issue today. Current QoS handling
   mechanisms used in  modern network transport layers (MPLS, RSVP,
   Diffserv,Traffic Engineering) do not provide  themselves a
   QoS-on-demand end-to-end solution and existing adaptative
   solutions based on In-band Control protocols (such as RTCP)
   are very difficult to combine with any other protocols for which
   they have not been designed for.
 
   Four Network Parameters comprises the QoS at application level:
   Bandwidth, packet-loss, latency and Jitter.
 
   Interactive-video applications define flows in both directions.
   Different applications require different constraints (in terms of
   latency, jitter, packet loss) in one or both directions and
   different responsiveness. The proposed solution must be an
   effective out-of-band application level protocol capable of
   reacting when any of these constraints are violated. Such protocol
   must trigger adaptive solutions and/or QoS network profile changes.
 
   Currently content providers are only able to provide services based
   on adaptative methods or last-mille deployments which prefer
   dedicated network resources (vs. Internet), and therefore, restricts
   the subscriber population and increases the costs.
 
   Objetives:
 
   The goal of this working group is to define a
   QoS application-level  standard protocol optimized for its use over
   the internet that may be widely implemented and easily managed
   by application developers and service providers.
 
   The core technical considerations for such protocol include, but
   are not necessarily limited to, the following:
 
   1. Protocol design to be used in interactive applications (including
      virtualized videogames,and interative-video applications)
 
   2. Ensuring interoperability with all existing transport protocols
 
   3. Optimizing for low bit rates (typlically below 2.4 kbps)
 
   4. To ensure a feasible practical implementation based on
      policy servers and interoperability between service providers
 
 
   Deliverables:
 
   1. Specification of protocol that meets the requirements in the
      form of an Internet-Draft that defines the negotiation of QoS
      parameters, the measurement process and alert mechanisms.
 
   2. Dimensioning rules and performance analysis
 
   3. A set of technical requirements for a practical
      implementation which may include adaptative solutions and/or
      QoS profile modification.
 
 
Goals and Milestiones
=====================
 
Nov 2010    Submit Internet-Draft as a proposed standard for QoS
             application-level protocol
 
             Proposed charter for Q4S WG
 
             Informational document with rules for dimensioning
             and performance analysis
 
             Specification of architecture document for implementation
 
 
 
 
 
 
- Jose Javier
 
 
 
 
 

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

--------------080206080403010501030402-- From jose_javier.garcia_aranda@alcatel-lucent.com Mon Dec 20 08:49:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE2B3A6A5F for ; Mon, 20 Dec 2010 08:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.663 X-Spam-Level: X-Spam-Status: No, score=-5.663 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tr+HP9VjMqHj for ; Mon, 20 Dec 2010 08:49:47 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id ACA193A6A70 for ; Mon, 20 Dec 2010 08:49:46 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oBKGmk6b021826 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 20 Dec 2010 17:48:47 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 20 Dec 2010 17:48:46 +0100 From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: Harald Alvestrand Date: Mon, 20 Dec 2010 17:48:46 +0100 Thread-Topic: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 Thread-Index: AcugSvRWsT7gbY+GSyqLnLGU53HqvAAGPezQ Message-ID: <3349FECF788C984BB34176D70A51782F1846528D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <4D0F5BD8.4040506@alvestrand.no> In-Reply-To: <4D0F5BD8.4040506@alvestrand.no> Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3349FECF788C984BB34176D70A51782F1846528DFRMRSSXCHMBSB3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "pedrochas@dit.upm.es" , "'dispatch@ietf.org'" , "jquemada@dit.upm.es" , "gabriel@dit.upm.es" , "barcenilla@dit.upm.es" , "jsr@dit.upm.es" , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" Subject: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 16:49:48 -0000 --_000_3349FECF788C984BB34176D70A51782F1846528DFRMRSSXCHMBSB3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Harald, The approach does no assume the details of the particular implementation. T= he protocol sends ALERT when any constraint is being violated, and these AL= ERTs can be monitored using DPI and change DSCP on the fly. However, the pr= otocol does not assume it. The protocol only allow participants to know the= quality measurements and to be aware of the alerts. After an alert is rece= ived , a lot of implementations are possible . Following are some examples: - use DPI and change DSCP packet marking ( network aware of this protoc= ol) and/or other type of QoS actions over network elements like changes on = traffic mode at acces nodes or Path computation element function invocation= . - invoke a supra entity (policy service) in charge of modify quality pr= ofiles on ISPs - invoke a policy server which belongs to an ISP and ask for changes on = QoS profles - react with adaptative mechanisms ( like reduce bit-rate or functionali= ties of the application) - simultaneously apply adaptative solution and QoS profile change throug= h DPI, policy servers or whatever. Therefore the answer to your question is that the Q4S does not assume that.= We will say it explicitly in the charter thanks! - jose javier ________________________________ De: Harald Alvestrand [mailto:harald@alvestrand.no] Enviado el: lunes, 20 de diciembre de 2010 14:36 Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) CC: 'dispatch@ietf.org'; pedrochas@dit.upm.es; CUBILLO PASTOR, CLARA (CLARA= ); ORTIGA HERRERA, GUADALUPE (GUADALUPE); jquemada@dit.upm.es; HERRANZ PABL= O, SONIA (SONIA); gabriel@dit.upm.es; barcenilla@dit.upm.es; jsr@dit.upm.es= ; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) Asunto: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Versi= on 1 On 12/13/10 16:39, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote: Hi everybody, Here is the charter proposal for Q4S ( Quality for service) WG. This WG wil= l include the achieved works with "Q-HTTP" Forgive me if this has been asked before.... does this approach (out-of-band measurements on a different set of ports/pr= otocols than in fact used by the application) assume that the network is no= t doing deep packet inspection or differential treatment of services? Is there an interaction with DSCP packet marking - could the measurement se= tup specify DSCP codepoints to be set on packets (and, knowing that these a= re changed en route, report on the DSCP codepoints of incoming packets)? In both points, it would be nice if the charter said whether it was in or o= ut of scope. Harald Thanks for your comments Description of Working group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Problem Statement: The QoS over Internet is a hot issue today. Current QoS handling mechanisms used in modern network transport layers (MPLS, RSVP, Diffserv,Traffic Engineering) do not provide themselves a QoS-on-demand end-to-end solution and existing adaptative solutions based on In-band Control protocols (such as RTCP) are very difficult to combine with any other protocols for which they have not been designed for. Four Network Parameters comprises the QoS at application level: Bandwidth, packet-loss, latency and Jitter. Interactive-video applications define flows in both directions. Different applications require different constraints (in terms of latency, jitter, packet loss) in one or both directions and different responsiveness. The proposed solution must be an effective out-of-band application level protocol capable of reacting when any of these constraints are violated. Such protocol must trigger adaptive solutions and/or QoS network profile changes. Currently content providers are only able to provide services based on adaptative methods or last-mille deployments which prefer dedicated network resources (vs. Internet), and therefore, restricts the subscriber population and increases the costs. Objetives: The goal of this working group is to define a QoS application-level standard protocol optimized for its use over the internet that may be widely implemented and easily managed by application developers and service providers. The core technical considerations for such protocol include, but are not necessarily limited to, the following: 1. Protocol design to be used in interactive applications (including virtualized videogames,and interative-video applications) 2. Ensuring interoperability with all existing transport protocols 3. Optimizing for low bit rates (typlically below 2.4 kbps) 4. To ensure a feasible practical implementation based on policy servers and interoperability between service providers Deliverables: 1. Specification of protocol that meets the requirements in the form of an Internet-Draft that defines the negotiation of QoS parameters, the measurement process and alert mechanisms. 2. Dimensioning rules and performance analysis 3. A set of technical requirements for a practical implementation which may include adaptative solutions and/or QoS profile modification. Goals and Milestiones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nov 2010 Submit Internet-Draft as a proposed standard for QoS application-level protocol Proposed charter for Q4S WG Informational document with rules for dimensioning and performance analysis Specification of architecture document for implementation - Jose Javier _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_3349FECF788C984BB34176D70A51782F1846528DFRMRSSXCHMBSB3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Harald,
 
The approach does no assume the details of the=20 particular implementation. The protocol sends ALERT when any constrain= t is=20 being violated, and these ALERTs can be monitored using DPI and change DSCP= on=20 the fly. However, the protocol does not assume it. The protocol only allow= =20 participants to know the quality measurements and to be aware of the alerts= .=20 After an alert is received , a lot of implementations are possible . Follow= ing=20 are some examples:
 
   - use DPI and change DSCP packet=20 marking  ( network aware of this protocol) and/or other type of QoS ac= tions=20 over network elements like changes on traffic mode at acces nodes or Path=20 computation element function invocation.
   - invoke a supra entity  = (policy=20 service) in charge of modify quality profiles on ISPs
   - invoke a policy server which belo= ngs to=20 an ISP and ask for changes on QoS profles
   - react with adaptative mechanisms = ( like=20 reduce bit-rate or functionalities of the application)
   - simultaneously apply adaptative s= olution=20 and QoS profile change through DPI, policy servers or=20 whatever.
 
Therefore the answer to your question is that th= e Q4S=20 does not assume that. We will say it explicitly in the=20 charter
 
thanks!
 
- jose=20 javier

De: Harald Alvestrand=20 [mailto:harald@alvestrand.no]
Enviado el: lunes, 20 de diciembre= de=20 2010 14:36
Para: GARCIA ARANDA, JOSE JAVIER (JOSE=20 JAVIER)
CC: 'dispatch@ietf.org'; pedrochas@dit.upm.es; CUBILLO PA= STOR,=20 CLARA (CLARA); ORTIGA HERRERA, GUADALUPE (GUADALUPE); jquemada@dit.upm.es;= =20 HERRANZ PABLO, SONIA (SONIA); gabriel@dit.upm.es; barcenilla@dit.upm.es;=20 jsr@dit.upm.es; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
Asunto: = Re:=20 [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version=20 1

On 12/13/10 16:39, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrot= e:=20
 
Hi everybody,
 
Here is the charter proposal for Q4S ( Quality for se= rvice)=20 WG. This WG will include the achieved works with =20 "Q-HTTP"
Forgive me if this has been aske= d=20 before....

does this approach (out-of-band measurements on a differe= nt=20 set of ports/protocols than in fact used by the application) assume that th= e=20 network is not doing deep packet inspection or differential treatment of=20 services?

Is there an interaction with DSCP packet marking - could t= he=20 measurement setup specify DSCP codepoints to be set on packets (and, knowin= g=20 that these are changed en route, report on the DSCP codepoints of incoming= =20 packets)?

In both points, it would be nice if the charter said wheth= er it=20 was in or out of=20 scope.

          &= nbsp;          =20 Harald

 
Thanks for your comments
 
 
Description of Workin= g=20 group
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
 
   Problem= =20 Statement:
 
   The QoS = over=20 Internet is a hot issue today. Current QoS handling
   mechanis= ms used=20 in  modern network transport layers (MPLS, RSVP,
   Diffserv= ,Traffic=20 Engineering) do not provide  themselves a
   QoS-on-d= emand=20 end-to-end solution and existing adaptative
   solution= s based=20 on In-band Control protocols (such as RTCP)
   are very= =20 difficult to combine with any other protocols for which
   they hav= e not=20 been designed for.
 
   Four Net= work=20 Parameters comprises the QoS at application level:
   Bandwidt= h,=20 packet-loss, latency and Jitter.
 
   Interact= ive-video=20 applications define flows in both directions.
   Differen= t=20 applications require different constraints (in terms of
   latency,= jitter,=20 packet loss) in one or both directions and
   differen= t=20 responsiveness. The proposed solution must be an
   effectiv= e=20 out-of-band application level protocol capable of
   reacting= when any=20 of these constraints are violated. Such protocol
   must tri= gger=20 adaptive solutions and/or QoS network profile changes.
 
   Currentl= y content=20 providers are only able to provide services based
   on adapt= ative=20 methods or last-mille deployments which prefer
   dedicate= d network=20 resources (vs. Internet), and therefore, restricts
   the subs= criber=20 population and increases the costs.
 
  =20 Objetives:
 
   The goal= of this=20 working group is to define a
   QoS=20 application-level  standard protocol optimized for its use over=20
   the inte= rnet that=20 may be widely implemented and easily managed
   by appli= cation=20 developers and service providers.
 
   The core= =20 technical considerations for such protocol include, but
   are not= =20 necessarily limited to, the following:
 
   1. Proto= col=20 design to be used in interactive applications (including
   &nb= sp; =20 virtualized videogames,and interative-video applications)
 
   2. Ensur= ing=20 interoperability with all existing transport protocols
 
   3. Optim= izing for=20 low bit rates (typlically below 2.4 kbps)
 
   4. To en= sure a=20 feasible practical implementation based on
   &nb= sp; =20 policy servers and interoperability between service providers
 
 
  =20 Deliverables:
 
   1. Speci= fication=20 of protocol that meets the requirements in the
   &nb= sp; =20 form of an Internet-Draft that defines the negotiation of QoS
   &nb= sp; =20 parameters, the measurement process and alert mechanisms.
 
   2. Dimen= sioning=20 rules and performance analysis
 
   3. A set= of=20 technical requirements for a practical
   &nb= sp; =20 implementation which may include adaptative solutions and/or
   &nb= sp; =20 QoS profile modification.
 
 
Goals and=20 Milestiones
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /FONT>
 
Nov 2010  &= nbsp;=20 Submit Internet-Draft as a proposed standard for QoS
          &nbs= p; =20 application-level protocol
 
          &nbs= p; =20 Proposed charter for Q4S WG
 
          &nbs= p; =20 Informational document with rules for dimensioning
          &nbs= p; =20 and performance analysis
 
          &nbs= p; =20 Specification of architecture document for implementation
 
 
 
 
 
 
- Jose Javier
 
 
 
 

_______________________________________________
dispatch mailing list
dispa=
tch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--_000_3349FECF788C984BB34176D70A51782F1846528DFRMRSSXCHMBSB3d_-- From gao.yang2@zte.com.cn Mon Dec 20 22:39:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 888473A69DD for ; Mon, 20 Dec 2010 22:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AvpOF7VwM9s for ; Mon, 20 Dec 2010 22:39:11 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 259893A69C6 for ; Mon, 20 Dec 2010 22:39:10 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 3510992332426; Tue, 21 Dec 2010 14:39:19 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.16] with StormMail ESMTP id 97021.2659414649; Tue, 21 Dec 2010 14:12:47 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id oBL6IZ8A017103; Tue, 21 Dec 2010 14:18:35 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4D0F5E85.5030408@alvestrand.no> To: Harald Alvestrand MIME-Version: 1.0 X-KeepSent: 0C3764AC:969C2835-48257800:001FB7FD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 21 Dec 2010 14:15:45 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-12-21 14:18:25, Serialize complete at 2010-12-21 14:18:25 Content-Type: multipart/alternative; boundary="=_alternative 0022A73C48257800_=" X-MAIL: mse3.zte.com.cn oBL6IZ8A017103 Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 06:39:12 -0000 This is a multipart message in MIME format. --=_alternative 0022A73C48257800_= Content-Type: text/plain; charset="US-ASCII" Harald, Your draft is about realtime communication in the Web. I think SIP&SDP is one way for it, and this overlaps my concerning. I also concerne about openning multimedia capability to the Web from current SIP infrastructure, such as IMS(a system defined by 3GPP with AAA, security, QoS). IMO, if we can standardize embedded SIP session into HTML(HTML5's video/audio elements), then people can access IMS's quality multimedia service by normal Web Browser without any plugin. Thanks, Gao =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0022A73C48257800_= Content-Type: text/html; charset="US-ASCII"
Harald,

Your draft is about realtime communication in the Web. I think SIP&SDP is one way for it, and this overlaps my concerning.

I also concerne about openning multimedia capability to the Web from current SIP infrastructure, such as IMS(a system defined by 3GPP with AAA, security, QoS). IMO, if we can standardize embedded SIP session into HTML(HTML5's video/audio elements), then people can access IMS's quality multimedia service by normal Web Browser without any plugin.

Thanks,

Gao
 
===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0022A73C48257800_=-- From mary.ietf.barnes@gmail.com Tue Dec 21 10:20:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7CDB3A6B47; Tue, 21 Dec 2010 10:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.229 X-Spam-Level: X-Spam-Status: No, score=-103.229 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77Wn43bazsYp; Tue, 21 Dec 2010 10:20:49 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id B0AEE3A6A77; Tue, 21 Dec 2010 10:20:48 -0800 (PST) Received: by ywk9 with SMTP id 9so2045063ywk.31 for ; Tue, 21 Dec 2010 10:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=3sby4pXPxFwWcs3M0bFzyxzwH4TAgLbWi1MYZjhoWfE=; b=KIV186j/zWY9Z4g1B5VTURaC+Wls3rF/i/SlUIlAph11LasqHk9nlTFLWgX7wyn82n SFVvOta3pN8wPHOqumB9l0zu029lCL74ukY9rxVCoZb5PCnN0P27EfIphGrk9JIO+dfa FeuB5eODBCC1l5nyKyj4klfQtxGaWJfsTTOV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vahN9JjEkgF5x7sYLT97LxTi3ijlhSaN7et4si11liVCA+i3397r8M/PDI+IHzQobO +mHAbZYXCY5YnIT+unYT2IitTswaBXI/jZv5vVAnkHElaZVr8Z8/eU/Q1w2UmqKaP/Lf WsBZy9VHJ+ZI/N0gv92PQLWFUvENZDbipQKBE= MIME-Version: 1.0 Received: by 10.236.108.43 with SMTP id p31mr10999447yhg.22.1292955764780; Tue, 21 Dec 2010 10:22:44 -0800 (PST) Received: by 10.236.95.35 with HTTP; Tue, 21 Dec 2010 10:22:44 -0800 (PST) In-Reply-To: <20101221173342.056183A6A73@core3.amsl.com> References: <20101221173342.056183A6A73@core3.amsl.com> Date: Tue, 21 Dec 2010 12:22:44 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=90e6ba4fbe2e11f2550497efb9c5 Cc: maitai@ietf.org Subject: [dispatch] Fwd: WG Review: ControLling mUltiple streams for TElepresence (clue) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 18:20:51 -0000 --90e6ba4fbe2e11f2550497efb9c5 Content-Type: text/plain; charset=ISO-8859-1 FYI, the charter is out for community review. ---------- Forwarded message ---------- From: IESG Secretary Date: Tue, Dec 21, 2010 at 11:33 AM Subject: WG Review: ControLling mUltiple streams for TElepresence (clue) To: IETF Announcement list A new IETF working group has been proposed in the Real-Time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, December 28, 2010. ControLling mUltiple streams for TElepresence (clue) ------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-12-08 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: TBD Description of Working Group: In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience. One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders, microphones and loudspeakers. Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite. However, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor limiting the interoperability of telepresence systems is the lack of a standardized way to describe and negotiate the use of the multiple streams of audio and video comprising the media flows. The WG will create specifications for SIP-based conferencing systems to enable communication of information about media streams so that a sending system, receiving system, or intermediate system can make reasonable decisions about transmitting, selecting, and rendering media streams. This enables systems to make choices that optimize user experience. This working group is chartered to specify the following information about media streams from one entity to another entity: * Spatial relationships of cameras, displays, microphones, and loudspeakers - relative to each other and to likely positions of participants * Viewpoint, field of view/capture for camera/microphone/display/loudspeaker - so that senders and intermediate devices can understand how best to compose streams for receivers, and the receiver will know the characteristics of its received streams * Usage of the stream, for example whether the stream is presentation, or document camera output * Aspect ratio of cameras and displays * Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection) Information between sources and sinks about media stream capabilities will be exchanged. The working group will define the semantics, syntax, and transport mechanism for communicating the necessary information. It will consider whether existing protocols for signaling, messaging and transport are adequate or need to be extended. Any extensions to IETF protocols will be done in appropriate WGs, for example extensions to SDP in MMUSIC. The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as specifying the audio and video streams for defined speakers. Specifying the location of the current speakers relative to display microphones needs to be provided dynamically as speakers move. As part of the receiver telling the sender what it wants dynamically, explicit receiver notification to the sender of the desired video stream and video pause will be considered. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. The focus of this work is on multiple RTP audio and video streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. Interoperation with SIP and related standards for audio and video is required. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, floor control, conference roster. The working group may identify interoperability obstacles in existing open standards. If so, the WG will develop requirements to be communicated to other IETF WGs or Standards Forums, or recharter as appropriate. Reuse of existing protocols and backwards compatibility with SIP-compliant audio/video endpoints are important factors for the working group to consider. The work will closely coordinate with the appropriate areas (e.g., OPS and SEC), and working groups including AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. Goals and Milestones: Jul 2011 Submit informational draft to IESG on use cases Jul 2011 Submit informational draft to IESG on framework and requirements Nov 2011 Submit standards track specification(s) to IESG to support framework and requirements _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --90e6ba4fbe2e11f2550497efb9c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI, the charter is out for community review.

---------- Forwarded message ----------
From:= IESG Secretary <iesg-secretary@ietf.org>
Date: Tue, Dec 21, 2010 at 11:33 AM
Subject: WG Review: ControLling mUlt= iple streams for TElepresence (clue)
To: IETF Announcement list <ietf-announce@ietf.org>

A new IETF working group has been proposed in the Real-Time Application= s
and Infrastructure Area. =A0The IESG has not made any determination as= yet.
The following draft charter was submitted, and is provided for
informational purposes only. Please send your comments to the IESG mailing<= br>list (iesg@ietf.org) by Tuesday, De= cember 28, 2010.

ControLling mUltiple streams for TElepresence (clue= )
-------------------------------------------
Current Status: Proposed Wor= king Group
Last modified: 2010-12-08

Chairs: TBD

Real-Time= Applications and Infrastructure Area Directors:
=A0Gonzalo Camarillo &l= t;gonzalo.camarillo@erics= son.com>
=A0Robert Sparks <rjsparks@nostr= um.com>

Real-Time Applications and Infrastructure Area Adviso= r:
=A0 =A0Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>

Mailing Lists: TBD

Description of Working Group:

In the c= ontext of this WG, the term telepresence is used in a general
manner to = describe systems that provide high definition, high quality
audio/video = enabling a "being-there" experience. =A0One example is an
immersive telepresence system using specially designed and special
purpo= se rooms with multiple displays permitting life size image
reproduction = using multiple cameras, encoders, decoders, microphones
and loudspeakers= .

Current telepresence systems are based on open standards such as RTP,SIP, H.264, the H.323 suite. However, they cannot easily interoperate
= with each other without operator assistance and expensive additional
equipment which translates from one vendor to another. A major factor
li= miting the interoperability of telepresence systems is the lack of a
sta= ndardized way to describe and negotiate the use of the multiple
streams = of audio and video comprising the media flows.

The WG will create specifications for SIP-based conferencing systemsto enable communication of information about media streams so that a
se= nding system, receiving system, or intermediate system can make
reasonab= le decisions about transmitting, selecting, and rendering
media streams. This enables systems to make choices that optimize user
e= xperience.

This working group is chartered to specify the following = information
about media streams from one entity to another entity:

* Spatial relationships of cameras, displays, microphones, and
=A0lo= udspeakers - relative to each other and to likely positions of
=A0partic= ipants

* Viewpoint, field of view/capture for
=A0camera/microphon= e/display/loudspeaker - so that senders and
=A0intermediate devices can understand how best to compose streams for
= =A0receivers, and the receiver will know the characteristics of its
=A0r= eceived streams

* Usage of the stream, for example whether the strea= m is presentation,
=A0or document camera output

* Aspect ratio of cameras and displays<= br>
* Which sources a receiver wants to receive. =A0For example, it migh= t
=A0want the source for the left camera, or might want the source chose= n
=A0by VAD (Voice Activity Detection)

Information between sources and= sinks about media stream capabilities
will be exchanged.

The wor= king group will define the semantics, syntax, and transport
mechanism fo= r communicating the necessary information. It will
consider whether existing protocols for signaling, messaging and
transpo= rt are adequate or need to be extended. Any extensions to IETF
protocols= will be done in appropriate WGs, for example extensions to
SDP in MMUSI= C.

The scope of the work includes describing relatively static relationsbetween entities (participants and devices). It also includes handlingmore dynamic relationships, such as specifying the audio and video
streams for defined speakers. Specifying the location of the current
spe= akers relative to display microphones needs to be provided
dynamically a= s speakers move.

As part of the receiver telling the sender what it = wants dynamically,
explicit receiver notification to the sender of the desired video
stream= and video pause will be considered.

The scope includes both systems= that provide a fully immersive
experience, and systems that interwork w= ith them and therefore need to
understand the same multiple stream semantics.

The focus of this wor= k is on multiple RTP audio and video streams.
Other media types may be c= onsidered, however development of
methodologies for them is not within t= he scope of this work.

Interoperation with SIP and related standards for audio and video isrequired. =A0However, backwards compatibility with existing
non-standar= ds compliant telepresence systems is not required.

This working grou= p is not currently chartered to work on issues of
continuous conference control including: far end camera control, floor
c= ontrol, conference roster. The working group may identify
interoperabili= ty obstacles in existing open standards. If so, the WG
will develop requ= irements to be communicated to other IETF WGs or
Standards Forums, or recharter as appropriate.

Reuse of existing pro= tocols and backwards compatibility with
SIP-compliant audio/video endpoi= nts are important factors for the
working group to consider. The work wi= ll closely coordinate with the
appropriate areas (e.g., OPS and SEC), and working groups including
AVT,= MMUSIC, MEDIACTRL, XCON, and SIPCORE.

Goals and Milestones:

= Jul 2011 =A0Submit informational draft to IESG on use cases
Jul 2011 =A0= Submit informational draft to IESG on framework and
=A0 =A0 =A0 =A0 =A0requirements
Nov 2011 =A0Submit standards track speci= fication(s) to IESG to support
=A0 =A0 =A0 =A0 =A0framework and requirem= ents

_______________________________________________
IETF-Announc= e mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

--90e6ba4fbe2e11f2550497efb9c5-- From Markus.Isomaki@nokia.com Tue Dec 21 13:37:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EABDF3A68D3 for ; Tue, 21 Dec 2010 13:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.539 X-Spam-Level: X-Spam-Status: No, score=-4.539 tagged_above=-999 required=5 tests=[AWL=-1.941, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1X-AZ1Z8LpL for ; Tue, 21 Dec 2010 13:36:57 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 446E03A68C6 for ; Tue, 21 Dec 2010 13:36:57 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBLLcnw9003042; Tue, 21 Dec 2010 23:38:50 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Dec 2010 23:38:45 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 21 Dec 2010 22:38:44 +0100 Received: from 008-AM1MPN1-003.mgdnok.nokia.com ([169.254.3.98]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi; Tue, 21 Dec 2010 22:38:43 +0100 From: To: , Thread-Topic: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Thread-Index: AcuAy1RXtTh3Nt0jTE+h7SlrXOzekgdDJukAAN9ebfA= Date: Tue, 21 Dec 2010 21:38:42 +0000 Message-ID: References: <4CDA833D.8080203@alvestrand.no> 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_DD8B10B86502AB488CB2D3DB4C546E3806DA99008AM1MPN1003mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 21 Dec 2010 21:38:45.0306 (UTC) FILETIME=[71C391A0:01CBA157] X-Nokia-AV: Clean Cc: rtc-web@alvestrand.no, dispatch@ietf.org, ted.ietf@gmail.com Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 21:37:04 -0000 --_000_DD8B10B86502AB488CB2D3DB4C546E3806DA99008AM1MPN1003mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, all, About the video codec: Are there any arguments on why VP8 would not have IP= R issues? It is available as an open source implementation, but that does n= ot mean there are no IPR against it. My understanding is that the IPR situa= tion wrt. VP8 is still unclear and thus risky. The other issue with VP8 is,= as far as I know, the lack of a clear spec out of which independent intero= perable implementations can be created. So I don't at least buy the argument that we should choose VP8 as mandatory= to implement video codec because of IPR reasons. I'm working on a separate review on Harald's drafts (thanks for putting the= m together) and will come back to the codec issue there in more detail, but= just wanted to respond to Peter's point here. Regards, Markus From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of ext Peter Musgrave Sent: 17 December, 2010 13:48 To: Harald Alvestrand Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-= dispatch-rtcweb-protocols-00 I'd also like to echo Alan's thanks for these drafts. The protocol doc is very clear. [If you read only one dispatch draft this C= hristmas, make it this one. ;-) ] One observation to the group. The mandatory to implement video CODEC is VP8= (presumably since it does not have IPR issues - which some other choices w= ould have). Regards, Peter Musgrave Nits Introduction s/veichle/vehicle/ Section 2 Para "Within each.." s/implementaiton/implementation/ Section 4 Para1 "such as" (something missing here?) Section 5 Para2 "There is no third mandatory to implement" ? Was there a mention of a third before. Not sure why this statement is the= re. On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: This is the overview document for the IETF-related RTC-WEB work. -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Date: Wed, 10 Nov 2010 03:31:05 -0800 (PST) From: IETF I-D Submission Tool To: harald@alvestrand.no A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has= been successfully submitted by Harald Alvestrand and posted to the IETF re= pository. Filename: draft-alvestrand-dispatch-rtcweb-protocols Revision: 00 Title: Overview: Real Time Protocols for Brower-based Applications Creation_date: 2010-11-11 WG ID: Independent Submission Number_of_pages: 9 Abstract: This document gives an overview of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion. The IETF Secretariat. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_DD8B10B86502AB488CB2D3DB4C546E3806DA99008AM1MPN1003mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter, all,

 

About the video codec: Are there any arguments on why VP8 wo= uld not have IPR issues? It is available as an open source implementation, but = that does not mean there are no IPR against it. My understanding is that the IPR situation wrt. VP8 is still unclear and thus risky. The other issue with VP= 8 is, as far as I know, the lack of a clear spec out of which independent interop= erable implementations can be created.

 

So I don’t at least buy the argument that we should ch= oose VP8 as mandatory to implement video codec because of IPR reasons.

 

I’m working on a separate review on Harald’s dra= fts (thanks for putting them together) and will come back to the codec issue th= ere in more detail, but just wanted to respond to Peter’s point here.

 

Regards,

          =       Markus

 

From: dispatch-boun= ces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Peter Musgrave Sent: 17 December, 2010 13:48
To: Harald Alvestrand
Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie
Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

 

I'd also like to echo Alan's thanks for these drafts.&= nbsp;

 

The protocol doc is very clear. [If you read only one dispatch draft this Christmas, make it this one. ;-)  ]

 

One observation to the group. The mandatory to impleme= nt video CODEC is VP8 (presumably since it does not have IPR issues - which so= me other choices would have). 

 

Regards, 

 

Peter Musgrave

 

 

Nits

Introduction

s/veichle/vehicle/<= /span>

<= o:p> 

S= ection 2 Para "Within each.."

s= /implementaiton/implementation/

<= o:p> 

S= ection 4 Para1

&= quot;such as" (something missing here?)

<= o:p> 

S= ection 5 Para2

&= quot;There is no third mandatory to implement" 

?= Was there a mention of a third before. Not sure why this statement is there.

 

 

On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote:



This is the overview document for the IETF-related RTC= -WEB work.

-------- Original Message --------

Subject:=

New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

Date:

Wed, 10 Nov 2010 03:31:05 -0800 (PST)

From:

IETF I-D Submission Tool <idsubmission@ietf.org>

To:

harald@alves= trand.no

 

A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.tx=
t has been successfully submitted by Harald Alvestrand and posted to the IE=
TF repository.
 
Filename:&n=
bsp;     draft-alvestrand-dispatch-rtcweb-protocols
Revision:      00
Tit=
le:         Overview: Real Time Protocol=
s for Brower-based Applications
Creation_date:  2010-1=
1-11
WG ID:        =
 Independent Submission
Number_of_pages: 9<=
/pre>
 
Abstract:
This d=
ocument gives an overview of a protocol suite intended for use
with real-time applications that can be deployed in browsers - &qu=
ot;real
time communication on the Web".
 
It intends to serve as a starting a=
nd coordination point to make sure
all the parts that =
are needed to achieve this goal are findable, and
that=
 the parts that belong in the Internet protocol suite are fully<=
/pre>
specified and on the right publication track.
 
This work is an attempt to synthesize the inp=
ut of many people, but
makes no claims to fully repres=
ent the views of any of them.  All
parts of the d=
ocument should be regarded as open for discussion.
&nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;      
 
 
The IETF Secretariat.
=

 
 
 

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

 

--_000_DD8B10B86502AB488CB2D3DB4C546E3806DA99008AM1MPN1003mgdn_-- From singer@apple.com Tue Dec 21 13:44:08 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D6733A68C1 for ; Tue, 21 Dec 2010 13:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1vV-+jSMZNS for ; Tue, 21 Dec 2010 13:44:05 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id A3B743A6852 for ; Tue, 21 Dec 2010 13:44:04 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 8726FC5FB586; Tue, 21 Dec 2010 13:46:01 -0800 (PST) X-AuditID: 11807130-b7cb4ae000001037-64-4d1120198269 Received: from singda.apple.com (singda.apple.com [17.197.20.4]) by relay11.apple.com (Apple SCV relay) with SMTP id 0B.4C.04151.910211D4; Tue, 21 Dec 2010 13:46:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-200--1019335179 From: David Singer In-Reply-To: Date: Tue, 21 Dec 2010 13:46:00 -0800 Message-Id: <021F5744-F0AA-40CF-A755-39EBBF871C4D@apple.com> References: <4CDA833D.8080203@alvestrand.no> To: markus.isomaki@nokia.com X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: rtc-web@alvestrand.no, dispatch@ietf.org, ted.ietf@gmail.com Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 21:44:09 -0000 --Apple-Mail-200--1019335179 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have to agree. If IPR issues are what we want to avoid, VP8 seems = like a poor choice (e.g. = ). On Dec 21, 2010, at 13:38 , markus.isomaki@nokia.com wrote: > Hi Peter, all, > =20 > About the video codec: Are there any arguments on why VP8 would not = have IPR issues? It is available as an open source implementation, but = that does not mean there are no IPR against it. My understanding is that = the IPR situation wrt. VP8 is still unclear and thus risky. The other = issue with VP8 is, as far as I know, the lack of a clear spec out of = which independent interoperable implementations can be created. > =20 > So I don=92t at least buy the argument that we should choose VP8 as = mandatory to implement video codec because of IPR reasons. > =20 > I=92m working on a separate review on Harald=92s drafts (thanks for = putting them together) and will come back to the codec issue there in = more detail, but just wanted to respond to Peter=92s point here. > =20 > Regards, > Markus > =20 > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of ext Peter Musgrave > Sent: 17 December, 2010 13:48 > To: Harald Alvestrand > Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie > Subject: Re: [dispatch] Fwd: New Version Notification for = draft-alvestrand-dispatch-rtcweb-protocols-00 > =20 > I'd also like to echo Alan's thanks for these drafts.=20 > =20 > The protocol doc is very clear. [If you read only one dispatch draft = this Christmas, make it this one. ;-) ] > =20 > One observation to the group. The mandatory to implement video CODEC = is VP8 (presumably since it does not have IPR issues - which some other = choices would have).=20 > =20 > Regards,=20 > =20 > Peter Musgrave > =20 > =20 > Nits > Introduction > s/veichle/vehicle/ > =20 > Section 2 Para "Within each.." > s/implementaiton/implementation/ > =20 > Section 4 Para1 > "such as" (something missing here?) > =20 > Section 5 Para2 > "There is no third mandatory to implement"=20 > ? Was there a mention of a third before. Not sure why this statement = is there. > =20 > =20 > On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: >=20 >=20 > This is the overview document for the IETF-related RTC-WEB work. >=20 > -------- Original Message -------- > Subject: > New Version Notification for = draft-alvestrand-dispatch-rtcweb-protocols-00 > Date: > Wed, 10 Nov 2010 03:31:05 -0800 (PST) > From: > IETF I-D Submission Tool > To: > harald@alvestrand.no > =20 >=20 > A new version of I-D, = draft-alvestrand-dispatch-rtcweb-protocols-00.txt has been successfully = submitted by Harald Alvestrand and posted to the IETF repository. > =20 > Filename: draft-alvestrand-dispatch-rtcweb-protocols > Revision: 00 > Title: Overview: Real Time Protocols for Brower-based = Applications > Creation_date: 2010-11-11 > WG ID: Independent Submission > Number_of_pages: 9 > =20 > Abstract: > This document gives an overview of a protocol suite intended for use > with real-time applications that can be deployed in browsers - "real > time communication on the Web". > =20 > It intends to serve as a starting and coordination point to make sure > all the parts that are needed to achieve this goal are findable, and > that the parts that belong in the Internet protocol suite are fully > specified and on the right publication track. > =20 > This work is an attempt to synthesize the input of many people, but > makes no claims to fully represent the views of any of them. All > parts of the document should be regarded as open for discussion. > = =20 > =20 > =20 > The IETF Secretariat. > =20 > =20 > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch David Singer Multimedia and Software Standards, Apple Inc. --Apple-Mail-200--1019335179 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = have to agree.  If IPR issues are what we want to avoid, VP8 seems = like a poor choice (e.g. <http://www.digitaltrends.com/computing/mpeg-la= -looking-at-patents-for-googles-vp8webm-video/>).

On Dec 21, 2010, at 13:38 , markus.isomaki@nokia.com = wrote:

Hi Peter, = all,
About = the video codec: Are there any arguments on why VP8 would not have IPR = issues? It is available as an open source implementation, but that does = not mean there are no IPR against it. My understanding is that the IPR = situation wrt. VP8 is still unclear and thus risky. The other issue with = VP8 is, as far as I know, the lack of a clear spec out of which = independent interoperable implementations can be = created.
So I = don=92t at least buy the argument that we should choose VP8 as mandatory = to implement video codec because of IPR = reasons.
I=92m = working on a separate review on Harald=92s drafts (thanks for putting = them together) and will come back to the codec issue there in more = detail, but just wanted to respond to Peter=92s point = here.
 
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf= .org] On Behalf = Of ext Peter = Musgrave
Sent: 17 December, 2010 = 13:48
To: Harald = Alvestrand
Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie
Subject: Re: [dispatch] Fwd: New = Version Notification for = draft-alvestrand-dispatch-rtcweb-protocols-00
 
I'd also like = to echo Alan's thanks for these = drafts. 
The protocol doc is very = clear. [If you read only one dispatch draft this Christmas, make it this = one. ;-)  ]
One observation to the = group. The mandatory to implement video CODEC is VP8 (presumably since = it does not have IPR issues - which some other choices would = have). 
Peter = Musgrave
Section 2 Para "Within = each.."
Section 4 = Para1
"such as" (something missing = here?)
Section 5 = Para2
"There is no third mandatory to = implement" 
? Was = there a mention of a third before. Not sure why this statement is = there.
On 2010-11-10, at 6:34 = AM, Harald Alvestrand wrote:


This is the overview = document for the IETF-related RTC-WEB work.

-------- Original = Message --------
Subject:
New Version Notification for = draft-alvestrand-dispatch-rtcweb-protocols-00
Date:
Wed, 10 Nov 2010 03:31:05 -0800 = (PST)
IETF I-D Submission Tool 
To:
 

A new version of I-D, =
draft-alvestrand-dispatch-rtcweb-protocols-00.txt has been successfully =
submitted by Harald Alvestrand and posted to the IETF =
repository.
 
WG =
ID:         Independent =
Submission
Number_of_pages: 9
Abstract:
This =
document gives an overview of a protocol suite intended for =
use
with real-time applications that can be deployed in =
browsers - "real
time communication on the =
Web".
 
It intends to serve as a starting =
and coordination point to make sure
all the =
parts that are needed to achieve this goal are findable, =
and
that the parts that belong in the Internet protocol =
suite are fully
specified and on the right =
publication track.
 
This =
work is an attempt to synthesize the input of many people, =
but
makes no claims to fully represent the views of any of =
them.  All
parts of the document should be =
regarded as open for discussion.
 
The =
IETF Secretariat.
 
 

= --Apple-Mail-200--1019335179-- From gerardmxf@yahoo.co.uk Tue Dec 21 16:07:58 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BBD93A68D3 for ; Tue, 21 Dec 2010 16:07:58 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGYgxKLw8RTy for ; Tue, 21 Dec 2010 16:07:56 -0800 (PST) Received: from nm14.bullet.mail.ird.yahoo.com (nm14.bullet.mail.ird.yahoo.com [77.238.189.67]) by core3.amsl.com (Postfix) with SMTP id 1ED6C3A68D9 for ; Tue, 21 Dec 2010 16:07:55 -0800 (PST) Received: from [77.238.189.234] by nm14.bullet.mail.ird.yahoo.com with NNFMP; 22 Dec 2010 00:09:49 -0000 Received: from [212.82.108.113] by tm15.bullet.mail.ird.yahoo.com with NNFMP; 22 Dec 2010 00:09:49 -0000 Received: from [127.0.0.1] by omp1022.mail.ird.yahoo.com with NNFMP; 22 Dec 2010 00:09:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 715722.49484.bm@omp1022.mail.ird.yahoo.com Received: (qmail 33132 invoked by uid 60001); 22 Dec 2010 00:09:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1292976589; bh=lls5LXy4qzf15aBEbQlFyeriFAdURFiI5P2A8OMJ2wg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Xgfhwa85lFWBIQwtAI890XOk4j/rYHlNtLCMCIJprbYpgua0VvKAQt51Iez0wUFoRuqH6rBb0tiC6mwYEp2x+1i6SAM2B9f324UY1/IvCuYGplJd6XO0XyuLDxPIgapRfyqwG8mqrJVERnQuLcVwySsYb1vF/P0RCDHM8Suw24Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aoZCYPcHvq6RcVnVdDeI6sjdwNvQpyCls74lWBh2Fil/vQ7QCMjvBFR6E3kRJicVuZ/DmRvFGJ/tBf37WayDD7wiIWwSD2dzEAcrG/+K8saTDszjsOPS3yWzBS7cG53ZCsRwjtckuyxlXPCrZwBz+C7sT608ei4bQcy7ATs1nJg=; Message-ID: <610565.33122.qm@web24004.mail.ird.yahoo.com> X-YMail-OSG: gQpkp.MVM1klvrvn.7FHNuqkg41N27mJMpyTFMqeKigeJRZ SkD6J1YzOa00_Y.NXX05t0KsuJpy0xyazjQ45P7R5BvkVcyPB3OeK3.l7h.X gGyPNQ12L_ZVdjj4PoQZZgb5mGj0jQqcFrGrjU22t.7_Nzttd5Io.k0NWfIq L82ESs1ZH8D3iCO2EBGjHvPnis3fcr8s9SZHLRQrL5VY8dehIce9KWpqrXWl ID0nX45k079DuZUmtCGEb5Zds4emsHnzckk5bX9AfaczlHVgsV3Si9vWKCxr BWS4_Ae0VEMu2vxh1mNWKBxFnQz_e_YzyuZ_zYqCcu2WXpBC.XsrZf7RJgWI .fPMkiwWsnAxv145YDw-- Received: from [99.113.35.251] by web24004.mail.ird.yahoo.com via HTTP; Wed, 22 Dec 2010 00:09:49 GMT X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 References: <4CDA833D.8080203@alvestrand.no> <021F5744-F0AA-40CF-A755-39EBBF871C4D@apple.com> Date: Wed, 22 Dec 2010 00:09:49 +0000 (GMT) From: Gerard Fernando To: David Singer , dispatch@ietf.org In-Reply-To: <021F5744-F0AA-40CF-A755-39EBBF871C4D@apple.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-825955839-1292976589=:33122" Cc: rtc-web@alvestrand.no, ted.ietf@gmail.com Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 00:07:58 -0000 --0-825955839-1292976589=:33122 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I also feel that it's not appropriate to choose VP8 as a mandatory codec. I= t =0Amakes sense to limit any mandatory codecs to standards. =0A=0A=0AIf VP= 8 does need to be standardized, the IETF CODEC WG comes to my mind as a =0A= possible place to carry out such a standard - I do understand that this WG = is =0Acurrently only focused on audio. I suppose the charter could be chang= ed to =0Ainclude video. One advantage of this WG is that it aims to deliver= a =0Aroyalty-free spec. =0A=0A=0AThere's also a Call-for-Evidence put out = by ISO/MPEG with the aim of starting a =0Aroyalty-free codec development ac= tivity. =0A=0A=0ARegards=0A=0AGerard Fernando=0A=0A=0A=0A=0A_______________= _________________=0AFrom: David Singer =0ATo: markus.isom= aki@nokia.com=0ACc: rtc-web@alvestrand.no; dispatch@ietf.org; ted.ietf@gmai= l.com=0ASent: Tue, 21 December, 2010 13:46:00=0ASubject: Re: [dispatch] Fwd= : New Version Notification for =0Adraft-alvestrand-dispatch-rtcweb-protocol= s-00=0A=0AI have to agree. If IPR issues are what we want to avoid, VP8 se= ems like a poor =0Achoice (e.g. =0A).=0A=0A=0A=0AOn Dec = 21, 2010, at 13:38 , markus.isomaki@nokia.com wrote:=0A=0AHi Peter, all,=0A= > =0A>About the video codec: Are there any arguments on why VP8 would not h= ave IPR =0A>issues? It is available as an open source implementation, but t= hat does not mean =0A>there are no IPR against it. My understanding is that= the IPR situation wrt. VP8 =0A>is still unclear and thus risky. The other = issue with VP8 is, as far as I know, =0A>the lack of a clear spec out of wh= ich independent interoperable implementations =0A>can be created.=0A> =0A>S= o I don=E2=80=99t at least buy the argument that we should choose VP8 as ma= ndatory to =0A>implement video codec because of IPR reasons.=0A> =0A>I=E2= =80=99m working on a separate review on Harald=E2=80=99s drafts (thanks for= putting them =0A>together) and will come back to the codec issue there in = more detail, but just =0A>wanted to respond to Peter=E2=80=99s point here.= =0A> =0A>Regards,=0A> Markus=0A> =0A>From: dispatch-bounces@= ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf =0A>Of ext Peter Musg= rave=0A>Sent: 17 December, 2010 13:48=0A>To: Harald Alvestrand=0A>Cc: rtc-w= eb@alvestrand.no; dispatch@ietf.org; Ted Hardie=0A>Subject: Re: [dispatch] = Fwd: New Version Notification for =0A>draft-alvestrand-dispatch-rtcweb-prot= ocols-00=0A> =0A>I'd also like to echo Alan's thanks for these drafts. =0A>= =0A>The protocol doc is very clear. [If you read only one dispatch draft t= his =0A>Christmas, make it this one. ;-) ]=0A> =0A>One observation to the = group. The mandatory to implement video CODEC is VP8 =0A>(presumably since = it does not have IPR issues - which some other choices would =0A>have). =0A= > =0A>Regards, =0A> =0A>Peter Musgrave=0A> =0A> =0A>Nits=0A>Introduction=0A= >s/veichle/vehicle/=0A> =0A>Section 2 Para "Within each.."=0A>s/implementai= ton/implementation/=0A> =0A>Section 4 Para1=0A>"such as" (something missing= here?)=0A> =0A>Section 5 Para2=0A>"There is no third mandatory to implemen= t" =0A>? Was there a mention of a third before. Not sure why this statement= is there.=0A> =0A> =0A>On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote:= =0A>=0A>=0A>=0A>This is the overview document for the IETF-related RTC-WEB = work.=0A>=0A>-------- Original Message --------=0A>Subject: New Version Not= ification for =0A>draft-alvestrand-dispatch-rtcweb-protocols-00 =0A>=0A>Dat= e: Wed, 10 Nov 2010 03:31:05 -0800 (PST) =0A>From: IETF I-D Submission Tool= =0A>To: harald@alvestrand.no =0A> =0A>A new versio= n of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has been =0A>su= ccessfully submitted by Harald Alvestrand and posted to the IETF repository= .=0A> =0A>Filename: draft-alvestrand-dispatch-rtcweb-protocols=0A>Rev= ision: 00=0A>Title: Overview: Real Time Protocols for Brower-b= ased Applications=0A>Creation_date: 2010-11-11=0A>WG ID: Independe= nt Submission=0A>Number_of_pages: 9=0A> =0A>Abstract:=0A>This document giv= es an overview of a protocol suite intended for use=0A>with real-time appli= cations that can be deployed in browsers - "real=0A>time communication on t= he Web".=0A> =0A>It intends to serve as a starting and coordination point = to make sure=0A>all the parts that are needed to achieve this goal are find= able, and=0A>that the parts that belong in the Internet protocol suite are = fully=0A>specified and on the right publication track.=0A> =0A>This work i= s an attempt to synthesize the input of many people, but=0A>makes no claims= to fully represent the views of any of them. All=0A>parts of the document= should be regarded as open for discussion.=0A> = =0A> =0A> =0A> =0A>T= he IETF Secretariat.=0A> =0A> =0A> =0A>_________________________________= ______________=0A>dispatch mailing list=0A>dispatch@ietf.org=0A>https://www= .ietf.org/mailman/listinfo/dispatch=0A> =0A________________________________= _______________=0A>dispatch mailing list=0A>dispatch@ietf.org=0A>https://ww= w.ietf.org/mailman/listinfo/dispatch=0A>=0A=0ADavid Singer=0AMultimedia and= Software Standards, Apple Inc. --0-825955839-1292976589=:33122 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I also feel that it's not appropriate to choos= e VP8 as a mandatory codec. It makes sense to limit any mandatory codecs to= standards.

If VP8 does need to be standardized, the IETF CODEC WG = comes to my mind as a possible place to carry out such a standard - I do un= derstand that this WG is currently only focused on audio. I suppose the cha= rter could be changed to include video. One advantage of this WG is that it= aims to deliver a royalty-free spec.

There's also a Call-for-Evide= nce put out by ISO/MPEG with the aim of starting a royalty-free codec devel= opment activity.

Regards

Gerard Fernando

From: David Sing= er <singer@apple.com>
To: markus.isomaki@nokia.com
= Cc: rtc-web@alvestrand.no; dispatch@ietf.org; ted.ietf@gmail.com=
Sent: Tue, 21 December= , 2010 13:46:00
Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatc= h-rtcweb-protocols-00

I have to agree.  If IPR issues ar= e what we want to avoid, VP8 seems like a poor choice (e.g. <http://www.digitaltrends.com/computing/mpeg-la-= looking-at-patents-for-googles-vp8webm-video/>).

O= n Dec 21, 2010, at 13:38 , = markus.isomaki@nokia.com wrote:

Hi Peter, all,
 
About the video codec: Are there any arguments on why = VP8 would not have IPR issues? It is available as an open source implementa= tion, but that does not mean there are no IPR against it. My understanding = is that the IPR situation wrt. VP8 is still unclear and thus risky. The oth= er issue with VP8 is, as far as I know, the lack of a clear spec out of whi= ch independent interoperable implementations can be created.
 
So I don=E2= =80=99t at least buy the argument that we should choose VP8 as mandatory to= implement video codec because of IPR reasons.
 
I=E2=80=99m working on a separa= te review on Harald=E2=80=99s drafts (thanks for putting them together) and= will come back to the codec issue there in more detail, but just wanted to= respond to Peter=E2=80=99s point here.
 
     &nb= sp;          Markus
 
<= div>
From:&nbs= p;dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org]<= span class=3D"Apple-converted-space"> On Behalf Of ext Peter Musgrave
Sent:=  17 December, 2010 13= :48
To: Harald Alvestrand
Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie
Subj= ect: Re: [dispatch] F= wd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols= -00
 
I'd also like to echo A= lan's thanks for these drafts. 
 
The pro= tocol doc is very clear. [If you read only one dispatch draft this Christma= s, make it this one. ;-)  ]
 
One observation to the group. The mandatory to implement video CODEC is= VP8 (presumably since it does not have IPR issues - which some other choic= es would have). 
 
Regards= , 
 
Peter Musgrave
=
 
 
Nits
Introduction
s/veichle/vehicle/
 
Section 2 P= ara "Within each.."
s/implementaiton/implementation/
 
Section 4 Para1
"such as" (something missing here?)
<= /div>
<= span style=3D"font-size: 10pt; font-family: Courier;">  
<= /div>
Section= 5 Para2
"There is no third mandatory to implement" 
? Was= there a mention of a third before. Not sure why this statement is there.
 
 
O= n 2010-11-10, at 6:34 AM, Harald Alvestrand wrote:


This is the overview document for the IETF-related RTC-WEB work= .

-------- Original Message --------
= =
<= b>Subject:
New Version Notific= ation for draft-alvestrand-dispatch-rtcweb-protocols-00
Date:
Wed, 10 Nov 2010 03:31:05 -0800 (PST)<= /div>
From:
IETF I-D Submission Tool <= /span><idsubmission@ietf.org>
To:
=  

A new version of I-D, draft-alvestrand-dispatch-rtcwe=
b-protocols-00.txt has been successfully submitted by Harald Alvestrand and=
 posted to the IETF repository.
  
Fil=
ename:      draft-alvestrand-dispatch-rtcweb-protocols<=
/pre>
Revision:      00
Title: &n=
bsp;       Overview: Real Time Protocols for Browe=
r-based Applications
Creation_date:  2010-11-11
WG ID:         Independent Submissi=
on
Number_of_pages: 9
  
Abstract:
This document gives an overview of a protocol=
 suite intended for use
with real-time applications that ca=
n be deployed in browsers - "real
time communication on the=
 Web".
  
It intends to serve as a sta=
rting and coordination point to make sure
all the parts tha=
t are needed to achieve this goal are findable, and
that th=
e parts that belong in the Internet protocol suite are fully
specified and on the right publication track.
  =
;
This work is an attempt to synthesize the input of many p=
eople, but
makes no claims to fully represent the views of =
any of them.  All
parts of the document should be rega=
rded as open for discussion.
           &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;        
  
=

  
The IETF Secretariat.
 &=
nbsp;
  
  
_______________________________________________
dispatch mailing listdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispa= tch
 
___________________________= ____________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.or= g/mailman/listinfo/dispatch

=0A
David Sin= ger
Multimedia and Software Standards, Apple Inc.
=0A
=0A
=0A= =0A=0A=0A=0A
= --0-825955839-1292976589=:33122-- From henry.sinnreich@gmail.com Tue Dec 21 18:30:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A023A6953; Tue, 21 Dec 2010 18:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x4s-MUMAegl; Tue, 21 Dec 2010 18:30:37 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 40D5B3A68EA; Tue, 21 Dec 2010 18:30:37 -0800 (PST) Received: by yxt33 with SMTP id 33so2207675yxt.31 for ; Tue, 21 Dec 2010 18:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type; bh=kM48DsyX88y7PK12iG2GmA7epaWKijnRwidB84Rfbd0=; b=PnPsq9Z2Mecz/c1PCDpEPDhMRhE/tCuY/2dj0qTY89FYhtjlhhTSzz8P6uJqWqk/IP e4KwKpXmlBBFzIg79FdoJBjoycP5EZ0VdYGT5dr/VMpCo0eSl0D7bso9povD6xSFCuQO JAg3K7KH4xgLjQPPRjocpxz5gChx3DXZaL4iI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; b=ZF4nAhyigV7n8xJbmI23Z/mIlaDuGN8+cZS4hs/Z/CE6/uQrhpKigH60p2hAdfd72g oRkI33P846SfgoUkMdCfJn6qhm/2qded+YmWE/VC1BhaPGvB8l12zcepWcniVVYj7QtU c+ygai+TDdBFC4a9EsiiM307GIJDZE0S1ECXU= Received: by 10.100.190.3 with SMTP id n3mr3741520anf.150.1292985154181; Tue, 21 Dec 2010 18:32:34 -0800 (PST) Received: from [10.0.1.7] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id 35sm10475640ano.11.2010.12.21.18.32.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Dec 2010 18:32:33 -0800 (PST) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 21 Dec 2010 20:32:28 -0600 From: Henry Sinnreich To: , , , Message-ID: Thread-Topic: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Thread-Index: AcuAy1RXtTh3Nt0jTE+h7SlrXOzekgdDJukAAN9ebfAACsQBig== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3375808351_4771304" Cc: rtc-web@alvestrand.no, dispatch@ietf.org, ted.ietf@gmail.com Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 02:30:44 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3375808351_4771304 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable It is interesting, almost funny (or sad depending on the perspective) how the reaction to a _God Forbid_ IP-free video codec is mirroring the opposition to the Internet audio codec. That opposition proved eventually futile and we have now a CODEC WG. I hope the AD=B9s will have now the same fortitude as was shown when the Internet audio codec WG was formed. I have taken the liberty to copy the CODEC WG and hope they can participate now in the video codec discussion as well. My apology for the double posting. Thanks, Henry=20 On 12/21/10 3:38 PM, "Markus.Isomaki@nokia.com" wrote: > Hi Peter, all, > =20 > About the video codec: Are there any arguments on why VP8 would not have = IPR > issues? It is available as an open source implementation, but that does n= ot > mean there are no IPR against it. My understanding is that the IPR situat= ion > wrt. VP8 is still unclear and thus risky. The other issue with VP8 is, as= far > as I know, the lack of a clear spec out of which independent interoperabl= e > implementations can be created. > =20 > So I don=B9t at least buy the argument that we should choose VP8 as mandato= ry to > implement video codec because of IPR reasons. > =20 > I=B9m working on a separate review on Harald=B9s drafts (thanks for putting t= hem > together) and will come back to the codec issue there in more detail, but= just > wanted to respond to Peter=B9s point here. > =20 > Regards, > Markus > =20 >=20 > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh= alf > Of ext Peter Musgrave > Sent: 17 December, 2010 13:48 > To: Harald Alvestrand > Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie > Subject: Re: [dispatch] Fwd: New Version Notification for > draft-alvestrand-dispatch-rtcweb-protocols-00 > =20 >=20 > I'd also like to echo Alan's thanks for these drafts. >=20 > =20 >=20 > The protocol doc is very clear. [If you read only one dispatch draft this > Christmas, make it this one. ;-) ] >=20 > =20 >=20 > One observation to the group. The mandatory to implement video CODEC is V= P8 > (presumably since it does not have IPR issues - which some other choices = would > have).=20 >=20 > =20 >=20 > Regards,=20 >=20 > =20 >=20 > Peter Musgrave >=20 > =20 >=20 > =20 >=20 > Nits >=20 > Introduction >=20 > s/veichle/vehicle/ >=20 > =20 >=20 > Section 2 Para "Within each.." >=20 > s/implementaiton/implementation/ >=20 > =20 >=20 > Section 4 Para1 >=20 > "such as" (something missing here?) >=20 > =20 >=20 > Section 5 Para2 >=20 > "There is no third mandatory to implement" >=20 > ? Was there a mention of a third before. Not sure why this statement is t= here. >=20 > =20 > =20 >=20 > On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: >=20 >=20 > This is the overview document for the IETF-related RTC-WEB work. >=20 > -------- Original Message -------- > =20 > =20 --B_3375808351_4771304 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-di= spatch-rtcweb-protocols-00 It is interesting, almost funny (or sad depending on the perspective) how = the reaction to a _God Forbid_ IP-free video codec is mirroring the oppositi= on to the Internet audio codec. That opposition proved eventually futile and= we have now a CODEC WG.
I hope the AD’s will have now the same fortitude as was shown when th= e Internet audio codec WG was formed.

I have taken the liberty to copy the CODEC WG and hope they can participate= now in the video codec discussion as well.
My apology for the double posting.

Thanks, Henry


On 12/21/10 3:38 PM, "Markus.Isomak= i@nokia.com" <Markus.Isomaki@= nokia.com> wrote:

<= FONT COLOR=3D"#1F497D">Hi Peter, a= ll,
 
About the video codec: Are there any arguments on why VP8 would not have IP= R issues? It is available as an open source implementation, but that does no= t mean there are no IPR against it. My understanding is that the IPR situati= on wrt. VP8 is still unclear and thus risky. The other issue with VP8 is, as= far as I know, the lack of a clear spec out of which independent interopera= ble implementations can be created.
 
So I don’t at least buy the argument that we should choose VP8 as man= datory to implement video codec because of IPR reasons.
 
I’m working on a separate review on Harald’s drafts (thanks for= putting them together) and will come back to the codec issue there in more = detail, but just wanted to respond to Peter’s point here.
 
Regards,
            &nb= sp;   Markus
 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Peter Musgrav= e
Sent: 17 December, 2010 13:48
To: Harald Alvestrand
Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie
Subject: Re: [dispatch] Fwd: New Version Notification for draft-alve= strand-dispatch-rtcweb-protocols-00

I'd also like to echo Alan's thanks for these drafts.



The protocol doc is very clear. [If you read only one dispatch d= raft this Christmas, make it this one. ;-)  ]

One observation to the group. The mandatory to implement video C= ODEC is VP8 (presumably since it does not have IPR issues - which some other= choices would have).



Regards,



Peter Musgrave



Nits

Introduction

s/veichle/vehicle/

Section 2 Para "Within each.."

s/implementaiton/implementation/

Section 4 Para1

"such as" (something missing here?)

Section 5 Para2

"There is no third mandatory to implement"

? Was there a mention of a third before. Not sure why this = statement is there.
 

On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote:


This is the overview document for the IETF-related RTC-WEB work.

-------- Original Message --------

  
--B_3375808351_4771304-- From bernard_aboba@hotmail.com Tue Dec 21 22:16:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF4633A69B5 for ; Tue, 21 Dec 2010 22:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.064 X-Spam-Level: X-Spam-Status: No, score=-102.064 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1ZVrU03VUQP for ; Tue, 21 Dec 2010 22:16:24 -0800 (PST) Received: from blu0-omc3-s38.blu0.hotmail.com (blu0-omc3-s38.blu0.hotmail.com [65.55.116.113]) by core3.amsl.com (Postfix) with ESMTP id 1EEBB3A69B3 for ; Tue, 21 Dec 2010 22:16:24 -0800 (PST) Received: from BLU152-W54 ([65.55.116.72]) by blu0-omc3-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Dec 2010 22:18:20 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_ae413f5c-6442-4bf8-bcc7-f9525112b102_" X-Originating-IP: [24.17.191.115] From: Bernard Aboba To: , , Date: Tue, 21 Dec 2010 22:18:20 -0800 Importance: Normal In-Reply-To: References: <4CDA833D.8080203@alvestrand.no>, , MIME-Version: 1.0 X-OriginalArrivalTime: 22 Dec 2010 06:18:20.0959 (UTC) FILETIME=[07E6B2F0:01CBA1A0] Cc: rtc-web@alvestrand.no, dispatch@ietf.org, ted.ietf@gmail.com Subject: Re: [dispatch] [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 06:16:26 -0000 --_ae413f5c-6442-4bf8-bcc7-f9525112b102_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It does appear presumptive to suggest that a codec that hasn't completed a = standardization process be made "mandatory to implement." Since there have been some large judgments over use of=20 allegedly "free" codecs=2C the lesson is that codecs that are claimed to=20 be "free of encumbrance" may in time be discovered not to be. The IETF pro= cess can potentially be useful in helping to clarify the IPR status of code= cs. However=2C those wheels grind slowly.=20 From: Markus.Isomaki@nokia.com To: peter.musgrave@magorcorp.com=3B harald@alvestrand.no Date: Tue=2C 21 Dec 2010 21:38:42 +0000 CC: rtc-web@alvestrand.no=3B dispatch@ietf.org=3B ted.ietf@gmail.com Subject: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alves= trand-dispatch-rtcweb-protocols-00 Hi Peter=2C all=2C =20 About the video codec: Are there any arguments on why VP8 would not have IPR issues? It is available as an open source implementation=2C bu= t that does not mean there are no IPR against it. My understanding is that the IPR situation wrt. VP8 is still unclear and thus risky. The other issue with VP= 8 is=2C as far as I know=2C the lack of a clear spec out of which independent inter= operable implementations can be created. =20 So I don=92t at least buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons. =20 I=92m working on a separate review on Harald=92s drafts (thanks for putting them together) and will come back to the codec issue th= ere in more detail=2C but just wanted to respond to Peter=92s point here. =20 Regards=2C Markus =20 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Peter Musgrave Sent: 17 December=2C 2010 13:48 To: Harald Alvestrand Cc: rtc-web@alvestrand.no=3B dispatch@ietf.org=3B Ted Hardie Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 =20 I'd also like to echo Alan's thanks for these drafts.=20 =20 The protocol doc is very clear. [If you read only one dispatch draft this Christmas=2C make it this one. =3B-) ] =20 One observation to the group. The mandatory to implement video CODEC is VP8 (presumably since it does not have IPR issues - which so= me other choices would have).=20 =20 Regards=2C=20 =20 Peter Musgrave =20 =20 Nits Introduction s/veichle/vehicle/ =20 Section 2 Para "Within each.." s/implementaiton/implementation/ =20 Section 4 Para1 "such as" (something missing here?) =20 Section 5 Para2 "There is no third mandatory to implement"=20 ? Was there a mention of a third before. Not sure why this statement is there. =20 =20 On 2010-11-10=2C at 6:34 AM=2C Harald Alvestrand wrote: This is the overview document for the IETF-related RTC-WEB work. -------- Original Message --------=20 =20 =20 Subject:=20 =20 =20 New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 =20 =20 =20 =20 Date:=20 =20 =20 Wed=2C 10 Nov 2010 03:31:05 -0800 (PST) =20 =20 =20 =20 From:=20 =20 =20 IETF I-D Submission Tool =20 =20 =20 =20 To:=20 =20 =20 harald@alvestrand.no =20 =20 =20 A new version of I-D=2C draft-alvestrand-dispatch-rtcweb-protocols-00.txt h= as been successfully submitted by Harald Alvestrand and posted to the IETF = repository. Filename: draft-alvestrand-dispatch-rtcweb-protocolsRevisi= on: 00Title: Overview: Real Time Protocols for Brower-based Ap= plicationsCreation_date: 2010-11-11WG ID: Independent SubmissionNu= mber_of_pages: 9 Abstract:This document gives an overview of a protocol sui= te intended for usewith real-time applications that can be deployed in brow= sers - "realtime communication on the Web". It intends to serve as a starti= ng and coordination point to make sureall the parts that are needed to achi= eve this goal are findable=2C andthat the parts that belong in the Internet= protocol suite are fullyspecified and on the right publication track. This= work is an attempt to synthesize the input of many people=2C butmakes no c= laims to fully represent the views of any of them. Allparts of the documen= t should be regarded as open for discussion. = The IETF Secretariat. = =20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =20 _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web = --_ae413f5c-6442-4bf8-bcc7-f9525112b102_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It does appear presumptive to suggest that a codec that hasn't completed a = standardization process be made "mandatory to implement."

Since ther= e have been some large judgments over use of=20 allegedly "free" codecs=2C the lesson is that codecs that are claimed to=20 be "free of encumbrance" may in time be discovered not to be. =3B The I= ETF process can potentially be useful in helping to clarify the IPR status = of codecs. =3B However=2C those wheels grind slowly.

From: Markus.Isomaki@nokia.com
To: peter.musgrave@magorcor= p.com=3B harald@alvestrand.no
Date: Tue=2C 21 Dec 2010 21:38:42 +0000CC: rtc-web@alvestrand.no=3B dispatch@ietf.org=3B ted.ietf@gmail.com
Su= bject: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestr= and-dispatch-rtcweb-protocols-00

Hi Peter=2C all= =2C

 =3B

About the video c= odec: Are there any arguments on why VP8 would not have IPR issues? It is available as an open source implementation=2C bu= t that does not mean there are no IPR against it. My understanding is that the IPR situation wrt. VP8 is still unclear and thus risky. The other issue with VP= 8 is=2C as far as I know=2C the lack of a clear spec out of which independent inter= operable implementations can be created.

 =3B

So I don=92t at l= east buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons.

 =3B

I=92m working on = a separate review on Harald=92s drafts (thanks for putting them together) and will come back to the codec issue th= ere in more detail=2C but just wanted to respond to Peter=92s point here.

 =3B

Regards=2C=

 =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B Markus

 =3B

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Peter Musgrave Sent: 17 December=2C 2010 13:48
To: Harald Alvestrand
Cc: rtc-web@alvestrand.no=3B dispatch@ietf.org=3B Ted Hardie
Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

 =3B

I'd also like to echo Alan's thanks for these dra= fts. =3B

 =3B

The protocol doc is very clear. [If you read only= one dispatch draft this Christmas=2C make it this one. =3B-)  =3B]

 =3B

One observation to the group. The mandatory to im= plement video CODEC is VP8 (presumably since it does not have IPR issues - which so= me other choices would have). =3B

 =3B

Regards=2C =3B

 =3B

Peter Musgrave

 =3B

 =3B

Nits

Introduction

s/veichle/vehicle/

 =3B

Section 2 Para "Within each.."

s/implementaiton/implementation/

 =3B

Section 4 Para1

"such as" (something missing here?)

 =3B

Section 5 Para2

"There is no third mandatory to implement" =3B

? Was there a mention of a third before. Not sure why this statement is there.

 =3B

 =3B

On 2010-11-10=2C at 6:34 AM=2C Harald Alvestrand = wrote:



This is the overview document for the IETF-relate= d RTC-WEB work.

-------- Original Message --------

= Subject:

New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

= Date:

Wed=2C 10 Nov 2010 03:31:05 -0800 (PST)

= From:

IETF I-D Submission Tool <=3Bidsubmission@ietf.org>=3B

= To:

harald@= alvestrand.no

 =3B

A new version of I-D=2C draft-alvestrand-dispatch-rtcweb-protocols-00.=
txt has been successfully submitted by Harald Alvestrand and posted to the =
IETF repository.
 =3B
Filename: =3B =3B&nbs=
p=3B =3B  draft-alvestrand-dispatch-rtcweb-protocols
Revision=
: =3B =3B =3B =3B  00
Title: =3B =3B =
=3B =3B =3B =3B =3B  Overview: Real Time Protocols for Brow=
er-based Applications
Creation_date:  2010-11-11
WG ID:=
 =3B =3B =3B =3B =3B =3B =3B  Independent Submi=
ssion
Number_of_pages: 9
 =3B
Abstract:
This document gives an overview of a protocol suite intended for u=
se
with real-time applications that can be deployed in browsers -=
 "real
time communication on the Web".
 =3B
It intends to serve as a starting and coordination point to make sure
all the parts that are needed to achieve this goal are findable=2C =
and
that the parts that belong in the Internet protocol suite are=
 fully
specified and on the right publication track.
&n=
bsp=3B
This work is an attempt to synthesize the input of many pe=
ople=2C but
makes no claims to fully represent the views of any o=
f them. =3B All
parts of the document should be regarded as o=
pen for discussion.
 =3B =3B =3B =3B =3B =
=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=
 =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb=
sp=3B =3B =3B =3B =3B =3B =3B =3B =3B =
=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=
 =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb=
sp=3B =3B =3B =3B =3B =3B =3B =3B =3B =
=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=
 =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb=
sp=3B 
 =3B
 =3B
The IETF Secretariat=
.
 =3B
 =3B
 =3B

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

 =3B


_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web = --_ae413f5c-6442-4bf8-bcc7-f9525112b102_-- From ingemar.s.johansson@ericsson.com Tue Dec 21 23:42:08 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B74833A6ACC for ; Tue, 21 Dec 2010 23:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+XOaKd6PDu2 for ; Tue, 21 Dec 2010 23:42:07 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0750A3A6A58 for ; Tue, 21 Dec 2010 23:42:06 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-90-4d11ac43fad9 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1F.14.23694.34CA11D4; Wed, 22 Dec 2010 08:44:03 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.48]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 22 Dec 2010 08:44:02 +0100 From: Ingemar Johansson S To: "dispatch@ietf.org" Date: Wed, 22 Dec 2010 08:44:01 +0100 Thread-Topic: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Thread-Index: AcuhWH5Hgnr3InAhTVWNtOBRG9neQAAUgKVg Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtc-web@alvestrand.no" , "Markus.Isomaki@nokia.com" Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 07:42:08 -0000 Hi Not meaning to express any preference in any direction but more a question = to the more experiened IETFers.=20 My impression here is that algorithms devised outside the IETF are rarely m= andated in IETF frameworks.=20 Two examples that I can come up with are=20 SRTP (RFC3711): Only specifies the framework for secure RTP but does not ma= ndate any encryption/authentication algorithms. Not sure if excryption algo= s are specified in separate RFC's=20 FECFRAME (RFC6015): Specifies the framework for generic FEC, generic enough= to plug in any FEC algo, the actual FEC algos are specified in separate dr= afs (http://tools.ietf.org/wg/fecframe/) Perhaps there are similar examples in other IETF areas that can serve as gu= idance ?, you may want to ping the eriIetf list on this (I leave it up to y= ou) So to me it seems like there is preference to _not_ mandate algorithms (com= pression, fec, encryption) in IETF frameworks (I can imagine one specific r= eason to this). And... as I believe that RTC-Web will be some kind of frame= work I would say that this would apply here as well ?.=20 Please feel free to bash my conclusion. /Ingemar ------------------------------------------- Message: 1 Date: Tue, 21 Dec 2010 21:38:42 +0000 From: Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 To: , Cc: rtc-web@alvestrand.no, dispatch@ietf.org, ted.ietf@gmail.com Message-ID: =09 Content-Type: text/plain; charset=3D"us-ascii" Hi Peter, all, About the video codec: Are there any arguments on why VP8 would not have IP= R issues? It is available as an open source implementation, but that does n= ot mean there are no IPR against it. My understanding is that the IPR situa= tion wrt. VP8 is still unclear and thus risky. The other issue with VP8 is,= as far as I know, the lack of a clear spec out of which independent intero= perable implementations can be created. So I don't at least buy the argument that we should choose VP8 as mandatory= to implement video codec because of IPR reasons. I'm working on a separate review on Harald's drafts (thanks for putting the= m together) and will come back to the codec issue there in more detail, but= just wanted to respond to Peter's point here. Regards, Markus From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of ext Peter Musgrave Sent: 17 December, 2010 13:48 To: Harald Alvestrand Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-= dispatch-rtcweb-protocols-00 I'd also like to echo Alan's thanks for these drafts. The protocol doc is very clear. [If you read only one dispatch draft this C= hristmas, make it this one. ;-) ] One observation to the group. The mandatory to implement video CODEC is VP8= (presumably since it does not have IPR issues - which some other choices w= ould have). Regards, Peter Musgrave Nits Introduction s/veichle/vehicle/ Section 2 Para "Within each.." s/implementaiton/implementation/ Section 4 Para1 "such as" (something missing here?) Section 5 Para2 "There is no third mandatory to implement" ? Was there a mention of a third before. Not sure why this statement is the= re. On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: This is the overview document for the IETF-related RTC-WEB work. -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Date: Wed, 10 Nov 2010 03:31:05 -0800 (PST) From: IETF I-D Submission Tool To: harald@alvestrand.no A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has= been successfully submitted by Harald Alvestrand and posted to the IETF re= pository. Filename: draft-alvestrand-dispatch-rtcweb-protocols Revision: 00 Title: Overview: Real Time Protocols for Brower-based Applications Creation_date: 2010-11-11 WG ID: Independent Submission Number_of_pages: 9 Abstract: This document gives an overview of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion. The IETF Secretariat. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ From Markus.Isomaki@nokia.com Tue Dec 21 23:44:40 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575353A69A6; Tue, 21 Dec 2010 23:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.215 X-Spam-Level: X-Spam-Status: No, score=-4.215 tagged_above=-999 required=5 tests=[AWL=-1.617, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPWHSulqvEBf; Tue, 21 Dec 2010 23:44:33 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 32C7A3A691F; Tue, 21 Dec 2010 23:44:32 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBM7kQbB032272; Wed, 22 Dec 2010 09:46:27 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 09:46:15 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 22 Dec 2010 08:46:14 +0100 Received: from 008-AM1MPN1-003.mgdnok.nokia.com ([169.254.3.98]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi; Wed, 22 Dec 2010 08:46:15 +0100 From: To: , , , Thread-Topic: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Thread-Index: AQHLoYCJzA9cAQBb2Ee2VTvzg0kiIJOsD4uw Date: Wed, 22 Dec 2010 07:46:12 +0000 Message-ID: References: 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_DD8B10B86502AB488CB2D3DB4C546E3806DE66008AM1MPN1003mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 22 Dec 2010 07:46:15.0843 (UTC) FILETIME=[4FFA1F30:01CBA1AC] X-Nokia-AV: Clean Cc: rtc-web@alvestrand.no, dispatch@ietf.org, ted.ietf@gmail.com Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 07:44:40 -0000 --_000_DD8B10B86502AB488CB2D3DB4C546E3806DE66008AM1MPN1003mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The good thing about Opus codec is that as it has been developed through th= e IETF process, the ownership and change control issues are clear. This mak= es referencing and even mandating it by IETF or W3C more comfortable. Markus From: ext Henry Sinnreich [mailto:henry.sinnreich@gmail.com] Sent: 22 December, 2010 04:32 To: Isomaki Markus (Nokia-CIC/Espoo); peter.musgrave@magorcorp.com; harald@= alvestrand.no; codec@ietf.org Cc: rtc-web@alvestrand.no; dispatch@ietf.org; ted.ietf@gmail.com Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-= dispatch-rtcweb-protocols-00 It is interesting, almost funny (or sad depending on the perspective) how t= he reaction to a _God Forbid_ IP-free video codec is mirroring the oppositi= on to the Internet audio codec. That opposition proved eventually futile an= d we have now a CODEC WG. I hope the AD's will have now the same fortitude as was shown when the Inte= rnet audio codec WG was formed. I have taken the liberty to copy the CODEC WG and hope they can participate= now in the video codec discussion as well. My apology for the double posting. Thanks, Henry On 12/21/10 3:38 PM, "Markus.Isomaki@nokia.com" = wrote: Hi Peter, all, About the video codec: Are there any arguments on why VP8 would not have IP= R issues? It is available as an open source implementation, but that does n= ot mean there are no IPR against it. My understanding is that the IPR situa= tion wrt. VP8 is still unclear and thus risky. The other issue with VP8 is,= as far as I know, the lack of a clear spec out of which independent intero= perable implementations can be created. So I don't at least buy the argument that we should choose VP8 as mandatory= to implement video codec because of IPR reasons. I'm working on a separate review on Harald's drafts (thanks for putting the= m together) and will come back to the codec issue there in more detail, but= just wanted to respond to Peter's point here. Regards, Markus From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of ext Peter Musgrave Sent: 17 December, 2010 13:48 To: Harald Alvestrand Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-= dispatch-rtcweb-protocols-00 I'd also like to echo Alan's thanks for these drafts. The protocol doc is very clear. [If you read only one dispatch draft this C= hristmas, make it this one. ;-) ] One observation to the group. The mandatory to implement video CODEC is VP8= (presumably since it does not have IPR issues - which some other choices w= ould have). Regards, Peter Musgrave Nits Introduction s/veichle/vehicle/ Section 2 Para "Within each.." s/implementaiton/implementation/ Section 4 Para1 "such as" (something missing here?) Section 5 Para2 "There is no third mandatory to implement" ? Was there a mention of a third before. Not sure why this statement is the= re. On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: This is the overview document for the IETF-related RTC-WEB work. -------- Original Message -------- --_000_DD8B10B86502AB488CB2D3DB4C546E3806DE66008AM1MPN1003mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

Hi,

 

The good thing about Opus codec is that as it has been devel= oped through the IETF process, the ownership and change control issues are clear= . This makes referencing and even mandating it by IETF or W3C more comfortable.

 

Markus

 

 

From: ext Henry Sin= nreich [mailto:henry.sinnreich@gmail.com]
Sent: 22 December, 2010 04:32
To: Isomaki Markus (Nokia-CIC/Espoo); peter.musgrave@magorcorp.com; harald@alvestrand.no; codec@ietf.org
Cc: rtc-web@alvestrand.no; dispatch@ietf.org; ted.ietf@gmail.com
Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

 

It is interesting, almost funny (or sad depending on the perspective) how the reaction to a _God Forbid_ IP-free vi= deo codec is mirroring the opposition to the Internet audio codec. That opposit= ion proved eventually futile and we have now a CODEC WG.
I hope the AD’s will have now the same fortitude as was shown when th= e Internet audio codec WG was formed.

I have taken the liberty to copy the CODEC WG and hope they can participate= now in the video codec discussion as well.
My apology for the double posting.

Thanks, Henry


On 12/21/10 3:38 PM, "Markus.Isom= aki@nokia.com" <Markus.Isomaki@nokia.com> w= rote:

Hi Peter, all,
 
About the video codec: Are there any arguments on why VP8 would not have IP= R issues? It is available as an open source implementation, but that does not mean there are no IPR against it. My understanding is that the IPR situatio= n wrt. VP8 is still unclear and thus risky. The other issue with VP8 is, as f= ar as I know, the lack of a clear spec out of which independent interoperable implementations can be created.
 
So I don’t at least buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons.
 
I’m working on a separate review on Harald’s drafts (thanks for putting them together) and will come back to the codec issue there in more detail, but just wanted to respond to Peter’s point here.
 
Regards,
            &nb= sp;   Markus
 
=
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org<= /a>] On Behalf Of ext Peter Musgrave
Sent: 17 December, 2010 13:48
To: Harald Alvestrand
Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie
Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00


I'd also like to echo Alan's thanks for these drafts.



The protocol doc is very clear. [If you read only one dispatch draft this Christmas, make it this one. ;-)  ]



One observation to the group. The mandatory to implement video CODEC= is VP8 (presumably since it does not have IPR issues - which some other choice= s would have).



Regards,



Peter Musgrave





Nits
=
Introduction
=
s/veichle/vehicle/
=

=
Section 2 Para "Within each.."
=
s/implementaito= n/implementation/
=

=
Section 4 Para1=
=
"such as&q= uot; (something missing here?)
=

=
Section 5 Para2=
=
"There is = no third mandatory to implement"
=
? Was there a m= ention of a third before. Not sure why this statement is there.
=

 

On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote:


This is the overview document for the IETF-related RTC-WEB work.

-------- Original Message --------

  

--_000_DD8B10B86502AB488CB2D3DB4C546E3806DE66008AM1MPN1003mgdn_-- From harald@alvestrand.no Wed Dec 22 07:12:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2923A6A17 for ; Wed, 22 Dec 2010 07:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdMuQ-SHcFOv for ; Wed, 22 Dec 2010 07:12:25 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id A16DC3A69F9 for ; Wed, 22 Dec 2010 07:12:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EEC0739E113; Wed, 22 Dec 2010 16:13:59 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7utSJZ76yYfo; Wed, 22 Dec 2010 16:13:59 +0100 (CET) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 4853B39E089; Wed, 22 Dec 2010 16:13:59 +0100 (CET) Message-ID: <4D1215CD.6090904@alvestrand.no> Date: Wed, 22 Dec 2010 16:14:21 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bernard Aboba References: <4CDA833D.8080203@alvestrand.no>, , In-Reply-To: Content-Type: multipart/alternative; boundary="------------090306000506090608070205" Cc: dispatch@ietf.org, rtc-web@alvestrand.no, ted.ietf@gmail.com Subject: [dispatch] Codec standardization (Re: [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 15:12:26 -0000 This is a multi-part message in MIME format. --------------090306000506090608070205 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/22/10 07:18, Bernard Aboba wrote: > It does appear presumptive to suggest that a codec that hasn't > completed a standardization process be made "mandatory to implement." > > Since there have been some large judgments over use of allegedly > "free" codecs, the lesson is that codecs that are claimed to be "free > of encumbrance" may in time be discovered not to be. The IETF process > can potentially be useful in helping to clarify the IPR status of > codecs. However, those wheels grind slowly. I agree that we can't make anything mandatory to implement that we don't have an accepted stable, publicly available reference for. (I'm working on solving that for the case of VP8). However, I don't agree that we necessarily have to complete a standards process in order to refer to it; that would put, for instance, the Zip format (used, among other places, in OOXML and ODF) out of scope for standards. WRT IPR issues: I think we just have to push forward on the assumption that all IPR holders who are part of the process will do their duty and disclose any relevant IPR, and hope that IPR held by nonparticipants in the process is not serious enough to cause us to regret our decision. Note: The statement about VP8 in the rtcweb-protocols document is a placeholder, put in there to indicate that we need to have the discussion. It's not a WG decision, but input to a WG discussion. Harald --------------090306000506090608070205 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 12/22/10 07:18, Bernard Aboba wrote:
It does appear presumptive to suggest that a codec that hasn't completed a standardization process be made "mandatory to implement."

Since there have been some large judgments over use of allegedly "free" codecs, the lesson is that codecs that are claimed to be "free of encumbrance" may in time be discovered not to be.  The IETF process can potentially be useful in helping to clarify the IPR status of codecs.  However, those wheels grind slowly.
I agree that we can't make anything mandatory to implement that we don't have an accepted stable, publicly available reference for. (I'm working on solving that for the case of VP8).

However, I don't agree that we necessarily have to complete a standards process in order to refer to it; that would put, for instance, the Zip format (used, among other places, in OOXML and ODF) out of scope for standards.

WRT IPR issues: I think we just have to push forward on the assumption that all IPR holders who are part of the process will do their duty and disclose any relevant IPR, and hope that IPR held by nonparticipants in the process is not serious enough to cause us to regret our decision.

Note: The statement about VP8 in the rtcweb-protocols document is a placeholder, put in there to indicate that we need to have the discussion. It's not a WG decision, but input to a WG discussion.

                      Harald



--------------090306000506090608070205-- From roar.hagen@gmail.com Tue Dec 21 23:47:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B522F3A691F for ; Tue, 21 Dec 2010 23:47:44 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvRoT9RBdGsq for ; Tue, 21 Dec 2010 23:47:41 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 628B13A6805 for ; Tue, 21 Dec 2010 23:47:41 -0800 (PST) Received: by qyj19 with SMTP id 19so5066040qyj.10 for ; Tue, 21 Dec 2010 23:49:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=SwC7D5OtvQkqv6SMcmjhEmYJuH54Ub5Rzegzl8Ohjdc=; b=LtrhBLeEo4TOpgWmfZFUTC4M2mXTBU7vRJiG6lyQ9+8FpNKLBfEuzmmt9NE2PSu8xe yADJ2XRtsT4Z20Rjy+Ea/z2sH8mfKww8J5VQWy6wUG2xcKfroSmBBK11rRuwE0KlpOu9 gbttKOIoF4o+sIW3vq8OxXYKEN5piZhEDUkcA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cbsXa/4ZY7fPVR8rITxKXpnMXqTBbPYEjx1jXI0lY+LaENZUOZ/ne8r5P1/sAQdij7 t9/GVcmPh3ZDLvfgZPhVrgiglBcfBR++rjPvstOjh5PxVquuixoJbVNzaKs45rlXln40 GprOZ5LY7oQW4HKHd/BVIJN68iCVWMWL3WLE4= MIME-Version: 1.0 Received: by 10.224.11.16 with SMTP id r16mr6288414qar.18.1293004178731; Tue, 21 Dec 2010 23:49:38 -0800 (PST) Received: by 10.220.177.140 with HTTP; Tue, 21 Dec 2010 23:49:38 -0800 (PST) In-Reply-To: References: <4CDA833D.8080203@alvestrand.no> <021F5744-F0AA-40CF-A755-39EBBF871C4D@apple.com> Date: Wed, 22 Dec 2010 08:49:38 +0100 Message-ID: From: Roar Hagen To: Silvia Pfeiffer Content-Type: multipart/alternative; boundary=0015175cdf30c433740497fafe5b X-Mailman-Approved-At: Wed, 22 Dec 2010 07:12:41 -0800 Cc: ted.ietf@gmail.com, dispatch@ietf.org, rtc-web@alvestrand.no Subject: Re: [dispatch] [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 07:47:44 -0000 --0015175cdf30c433740497fafe5b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree with what Silvia says here. Similarly, I believe royalty free is th= e goal/requirement for the new internet audio codec currently being standardized by the IETF. Furthermore, the term IPR free is also wrong sinc= e the designers/contributors that make the codec royalty free usually have IP= R in th codec. The best one can do is to do your best in avoiding other known IPR. Roar On Wed, Dec 22, 2010 at 8:31 AM, Silvia Pfeiffer wrote: > Where is the MPEG-LA patent pool for WebM? As far as I can tell this has > just been a hollow announcement, but MPEG-LA have not been able to set up > such a patent pool yet. Maybe it's because there aren't any patents out > there that are being infringed? Unfortunately, the non-existence of > infringing patents can never be proven and this situation is therefore > always open to creating fear, uncertainty and doubt. > > Also note that going through an actual standardisation process and becomi= ng > part of a license pool by MPEG-LA doesn't actually protect you from lawsu= its > for patent infringement, see e.g. > > http://www.itnews.com.au/News/74186,apple-samsung-and-sandisk-hit-by-mp3-= patent-claim.aspx > > MPEG-LA patent pools are only there to protect you from lawsuits of paten= ts > that are being made available through the pool. The pool is not an insura= nce > against patent infringement lawsuits - not even from those that have join= ed > the patent pool, as the law suit of Lucent against MicroSoft has taught u= s: > http://en.wikipedia.org/wiki/Alcatel-Lucent_v._Microsoft > > As said before: IPR issues are not a good decision factor on which to > select a codec for common use. Royalty-free is important. And the rest > should be based on technical merit. > > Regards, > Silvia. > > > On Tue, Dec 21, 2010 at 10:46 PM, David Singer wrote: > >> I have to agree. If IPR issues are what we want to avoid, VP8 seems lik= e >> a poor choice (e.g. < >> http://www.digitaltrends.com/computing/mpeg-la-looking-at-patents-for-go= ogles-vp8webm-video/ >> >). >> >> On Dec 21, 2010, at 13:38 , markus.isomaki@nokia.com wrote: >> >> Hi Peter, all, >> >> About the video codec: Are there any arguments on why VP8 would not have >> IPR issues? It is available as an open source implementation, but that d= oes >> not mean there are no IPR against it. My understanding is that the IPR >> situation wrt. VP8 is still unclear and thus risky. The other issue with= VP8 >> is, as far as I know, the lack of a clear spec out of which independent >> interoperable implementations can be created. >> >> So I don=92t at least buy the argument that we should choose VP8 as >> mandatory to implement video codec because of IPR reasons. >> >> I=92m working on a separate review on Harald=92s drafts (thanks for putt= ing >> them together) and will come back to the codec issue there in more detai= l, >> but just wanted to respond to Peter=92s point here. >> >> Regards, >> Markus >> >> *From:* dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] *On >> Behalf Of *ext Peter Musgrave >> *Sent:* 17 December, 2010 13:48 >> *To:* Harald Alvestrand >> *Cc:* rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie >> *Subject:* Re: [dispatch] Fwd: New Version Notification for >> draft-alvestrand-dispatch-rtcweb-protocols-00 >> >> I'd also like to echo Alan's thanks for these drafts. >> >> The protocol doc is very clear. [If you read only one dispatch draft thi= s >> Christmas, make it this one. ;-) ] >> >> One observation to the group. The mandatory to implement video CODEC is >> VP8 (presumably since it does not have IPR issues - which some other cho= ices >> would have). >> >> Regards, >> >> Peter Musgrave >> >> >> Nits >> Introduction >> s/veichle/vehicle/ >> >> Section 2 Para "Within each.." >> s/implementaiton/implementation/ >> >> Section 4 Para1 >> "such as" (something missing here?) >> >> Section 5 Para2 >> "There is no third mandatory to implement" >> ? Was there a mention of a third before. Not sure why this statement is >> there. >> >> >> On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: >> >> >> This is the overview document for the IETF-related RTC-WEB work. >> >> -------- Original Message -------- >> *Subject:* >> New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-= 00 >> *Date:* >> Wed, 10 Nov 2010 03:31:05 -0800 (PST) >> *From:* >> IETF I-D Submission Tool >> *To:* >> harald@alvestrand.no >> >> >> >> A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt = has been successfully submitted by Harald Alvestrand and posted to the IETF= repository. >> >> >> >> Filename: draft-alvestrand-dispatch-rtcweb-protocols >> >> Revision: 00 >> >> Title: Overview: Real Time Protocols for Brower-based Applicatio= ns >> >> Creation_date: 2010-11-11 >> >> WG ID: Independent Submission >> >> Number_of_pages: 9 >> >> >> >> Abstract: >> >> This document gives an overview of a protocol suite intended for use >> >> with real-time applications that can be deployed in browsers - "real >> >> time communication on the Web". >> >> >> >> It intends to serve as a starting and coordination point to make sure >> >> all the parts that are needed to achieve this goal are findable, and >> >> that the parts that belong in the Internet protocol suite are fully >> >> specified and on the right publication track. >> >> >> >> This work is an attempt to synthesize the input of many people, but >> >> makes no claims to fully represent the views of any of them. All >> >> parts of the document should be regarded as open for discussion. >> >> >> >> >> >> >> >> The IETF Secretariat. >> >> >> >> >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> David Singer >> Multimedia and Software Standards, Apple Inc. >> >> >> _______________________________________________ >> >> RTC-Web mailing list >> RTC-Web@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/rtc-web >> >> > > _______________________________________________ > RTC-Web mailing list > RTC-Web@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web > > --0015175cdf30c433740497fafe5b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree with what Silvia says here. Similarly, I believe royalty free is th= e goal/requirement for the new internet audio codec currently being standar= dized by the IETF. Furthermore, the term IPR free is also wrong since the d= esigners/contributors that make the codec royalty free usually have IPR in = th codec. The best one can do is to do your best in avoiding other known IP= R.

Roar

On Wed, Dec 22, 2010 = at 8:31 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
Where is the MPEG-LA patent pool for WebM? As far as I can tell this has ju= st been a hollow announcement, but MPEG-LA have not been able to set up suc= h a patent pool yet. Maybe it's because there aren't any patents ou= t there that are being infringed? Unfortunately, the non-existence of infri= nging patents can never be proven and this situation is therefore always op= en to creating fear, uncertainty and doubt.

Also note that going through an actual standardisation process and beco= ming part of a license pool by MPEG-LA doesn't actually protect you fro= m lawsuits for patent infringement, see e.g.
http://www.itnews.com.au/News/74186,apple-samsung-and-sa= ndisk-hit-by-mp3-patent-claim.aspx

MPEG-LA patent pools are only there to protect you from lawsuits of pat= ents that are being made available through the pool. The pool is not an ins= urance against patent infringement lawsuits - not even from those that have= joined the patent pool, as the law suit of Lucent against MicroSoft has ta= ught us: http://en.wikipedia.org/wiki/Alcatel-Lucent_v._Microso= ft

As said before: IPR issues are not a good decision factor on which to s= elect a codec for common use. Royalty-free is important. And the rest shoul= d be based on technical merit.

Regards,
S= ilvia.


On Tue, Dec 21, 2010 at 10:46 PM, David Singer <singer@apple.com> wrote:
I have to agree. =A0If IPR issues are w= hat we want to avoid, VP8 seems like a poor choice (e.g. <http://www.digitaltrends.com/computing/mp= eg-la-looking-at-patents-for-googles-vp8webm-video/>).

On Dec 21, 2010, at 13:38 , markus.isomaki@nokia.com<= /a> wrote:

Hi Peter, all,
=A0
About the video codec: Are there any arguments on why VP8 would n= ot have IPR issues? It is available as an open source implementation, but t= hat does not mean there are no IPR against it. My understanding is that the= IPR situation wrt. VP8 is still unclear and thus risky. The other issue wi= th VP8 is, as far as I know, the lack of a clear spec out of which independ= ent interoperable implementations can be created.
=A0
So I don=92t at least buy the argument that we should choose VP8 = as mandatory to implement video codec because of IPR reasons.
=A0
I=92m working on a separate review on Harald=92s drafts (thanks f= or putting them together) and will come back to the codec issue there in mo= re detail, but just wanted to respond to Peter=92s point here.
=A0
Regards,
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Markus
=A0
From:=A0dispatch-bounces@ietf.org=A0[m= ailto:dispat= ch-bounces@ietf.org]=A0On Behalf Of=A0= ext Peter Musgrave
Sent:=A017 December, 2010 13:48
To:=A0<= /span>Harald Alvestrand
Cc:=A0rtc-web@alvestrand.no;=A0dispatch@ietf.org; Ted Hardie
Subject:=A0Re: [dispatch] Fwd: New Version Notification= for draft-alvestrand-dispatch-rtcweb-protocols-00
=
=A0
I'd also like to echo Alan's t= hanks for these drafts.=A0
=A0
The protocol doc is very clear. = [If you read only one dispatch draft this Christmas, make it this one. ;-) = =A0]
=A0
=A0
Regards,=A0
=A0
Peter Musgrave
<= div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif"> =A0
=A0
Nits<= /div>
Introduction
s/veichle/vehicle/
=A0
Section 2 Para "Wit= hin each.."
s/implementaiton/implementation/
=A0
Section 4 Para1
"such as" (something missing here?)
=A0
Section 5 Para2
"There is no third mandatory to implement"=A0
? Was there a mention of a third before. Not sure why this statem= ent is there.
=A0
=A0
On 2010-11-10, at 6:34 AM, Harald= Alvestrand wrote:


This is the overview document for= the IETF-related RTC-WEB work.

-------- Original Message --------
Subject:
= New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00<= /div>
Date:
Wed, 10 Nov 2010 03:31:05 -0800 (PST)
From:
IET= F I-D Submission Tool=A0<ids= ubmission@ietf.org>
To:

=A0

A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has=
 been successfully submitted by Harald Alvestrand and posted to the IETF re=
pository.
=A0
Filename:=A0=A0=A0=A0  draft-alvestrand-dispatch-rtcw=
eb-protocols
Revision:=A0=A0=A0=A0  00
Title:=A0=A0=A0=A0=A0=A0=A0  Ov=
erview: Real Time Protocols for Brower-based Applications
Creation_date:  2010-11-11
WG ID:=A0=A0=A0=A0=A0=A0=A0  I=
ndependent Submission
Number_of_pages: 9
=A0
Abstract:
This document gives an overview of a protocol suite intended f=
or use
with real-time applications that can be deployed in browsers - "real
time communication on the Web".
=A0
It intends to serve as a starting and coordination po=
int to make sure
all the parts that are needed to achieve this goal are findable, and
<=
pre style=3D"margin:0cm 0cm 0.0001pt;font-size:10pt;font-family:'Courie=
r New'">that the parts that belong in the Internet protocol suite are f=
ully
specified and on the right publication track.
=A0
This work is an attempt to synthesize the input of ma=
ny people, but
makes no claims to fully represent the views of any of them.=A0 All
parts of the document should be regarded as open for discussion.= 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 
=A0
=A0
The IETF Secretariat.
=A0
=A0
=A0
_____________________________________= __________
dispatch mailing list
dispatch@= ietf.org
https://www.ietf.org/mailm= an/listinfo/dispatch
=A0
_______________________________________________
dis= patch mailing list
dispatch@ietf.org
https://www.ietf.org/mailm= an/listinfo/dispatch

David Singer
Multimedia and Software Standards, Apple I= nc.


____________________________________= ___________

RTC-Web mailing list
RTC-Web@alvestra= nd.no
http://www.alvestrand.no/mailman/listinfo/rtc-web



_______________________________________________
RTC-Web mailing list
RTC-Web@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtc-web


--0015175cdf30c433740497fafe5b-- From tterribe@email.unc.edu Wed Dec 22 04:40:09 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82EC43A684F for ; Wed, 22 Dec 2010 04:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb47+YXBR0BL for ; Wed, 22 Dec 2010 04:40:08 -0800 (PST) Received: from mxip3i.isis.unc.edu (mxip3i.isis.unc.edu [152.2.2.195]) by core3.amsl.com (Postfix) with ESMTP id 845E23A6843 for ; Wed, 22 Dec 2010 04:40:08 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAF+BEU2sGgRa/2dsb2JhbACjPoFKuh6IZ4VJBIRmhh6DEQw X-IronPort-AV: E=Sophos;i="4.60,213,1291611600"; d="scan'208";a="14786698" Received: from mr2a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.90]) by mxip3o.isis.unc.edu with ESMTP; 22 Dec 2010 07:41:47 -0500 Received: from [192.168.11.4] (pool-71-114-26-50.washdc.dsl-w.verizon.net [71.114.26.50]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id oBMCfiKX010788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Dec 2010 07:41:45 -0500 (EST) Message-ID: <4D11F207.9060908@email.unc.edu> Date: Wed, 22 Dec 2010 04:41:43 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101120 Gentoo/2.0.10 SeaMonkey/2.0.10 MIME-Version: 1.0 References: <4CDA833D.8080203@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 22 Dec 2010 07:12:41 -0800 Cc: rtc-web@alvestrand.no, dispatch@ietf.org Subject: Re: [dispatch] [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 12:45:06 -0000 > http://www.webmproject.org/media/pdf/vp8-bitstream.pdf . An independent > implementation of VP8 can be made by anyone, see > http://www.webmproject.org/license/bitstream/ . And, in particular, an independent implementation has been made, namely ffvp8: http://x264dev.multimedia.cx/archives/499 From harald@alvestrand.no Wed Dec 22 07:16:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6423A6A4C for ; Wed, 22 Dec 2010 07:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVjfxlD1tpwE for ; Wed, 22 Dec 2010 07:16:21 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id D96793A6A17 for ; Wed, 22 Dec 2010 07:16:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A386539E113; Wed, 22 Dec 2010 16:17:56 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKiqZqawkJbE; Wed, 22 Dec 2010 16:17:55 +0100 (CET) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 9C18239E089; Wed, 22 Dec 2010 16:17:54 +0100 (CET) Message-ID: <4D1216B8.8000103@alvestrand.no> Date: Wed, 22 Dec 2010 16:18:16 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: David Singer References: <4CDA833D.8080203@alvestrand.no> <021F5744-F0AA-40CF-A755-39EBBF871C4D@apple.com> In-Reply-To: <021F5744-F0AA-40CF-A755-39EBBF871C4D@apple.com> Content-Type: multipart/alternative; boundary="------------060603090504010900070709" Cc: dispatch@ietf.org, rtc-web@alvestrand.no, ted.ietf@gmail.com Subject: [dispatch] VP8 IPR claims (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 15:16:23 -0000 This is a multi-part message in MIME format. --------------060603090504010900070709 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 12/21/10 22:46, David Singer wrote: > I have to agree. If IPR issues are what we want to avoid, VP8 seems > like a poor choice (e.g. > ). That article is by now 7 months old (May 2010), and AFAIK, no specific IPR claims have been made public. I wouldn't presume to claim that this proves anything. Harald > > On Dec 21, 2010, at 13:38 , markus.isomaki@nokia.com > wrote: > >> Hi Peter, all, >> About the video codec: Are there any arguments on why VP8 would not >> have IPR issues? It is available as an open source implementation, >> but that does not mean there are no IPR against it. My understanding >> is that the IPR situation wrt. VP8 is still unclear and thus risky. >> The other issue with VP8 is, as far as I know, the lack of a clear >> spec out of which independent interoperable implementations can be >> created. >> So I don’t at least buy the argument that we should choose VP8 as >> mandatory to implement video codec because of IPR reasons. >> I’m working on a separate review on Harald’s drafts (thanks for >> putting them together) and will come back to the codec issue there in >> more detail, but just wanted to respond to Peter’s point here. >> Regards, >> Markus >> *From:*dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org]*On >> Behalf Of*ext Peter Musgrave >> *Sent:*17 December, 2010 13:48 >> *To:*Harald Alvestrand >> *Cc:*rtc-web@alvestrand.no >> ;dispatch@ietf.org >> ; Ted Hardie >> *Subject:*Re: [dispatch] Fwd: New Version Notification for >> draft-alvestrand-dispatch-rtcweb-protocols-00 >> I'd also like to echo Alan's thanks for these drafts. >> The protocol doc is very clear. [If you read only one dispatch draft >> this Christmas, make it this one. ;-) ] >> One observation to the group. The mandatory to implement video CODEC >> is VP8 (presumably since it does not have IPR issues - which some >> other choices would have). >> Regards, >> Peter Musgrave >> Nits >> Introduction >> s/veichle/vehicle/ >> Section 2 Para "Within each.." >> s/implementaiton/implementation/ >> Section 4 Para1 >> "such as" (something missing here?) >> Section 5 Para2 >> "There is no third mandatory to implement" >> ? Was there a mention of a third before. Not sure why this statement >> is there. >> On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: >> >> >> This is the overview document for the IETF-related RTC-WEB work. >> >> -------- Original Message -------- >> *Subject:* >> >> New Version Notification for >> draft-alvestrand-dispatch-rtcweb-protocols-00 >> *Date:* >> >> Wed, 10 Nov 2010 03:31:05 -0800 (PST) >> *From:* >> >> IETF I-D Submission Tool >> >> *To:* >> >> harald@alvestrand.no >> >> A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. >> >> Filename: draft-alvestrand-dispatch-rtcweb-protocols >> Revision: 00 >> Title: Overview: Real Time Protocols for Brower-based Applications >> Creation_date: 2010-11-11 >> WG ID: Independent Submission >> Number_of_pages: 9 >> >> Abstract: >> This document gives an overview of a protocol suite intended for use >> with real-time applications that can be deployed in browsers - "real >> time communication on the Web". >> >> It intends to serve as a starting and coordination point to make sure >> all the parts that are needed to achieve this goal are findable, and >> that the parts that belong in the Internet protocol suite are fully >> specified and on the right publication track. >> >> This work is an attempt to synthesize the input of many people, but >> makes no claims to fully represent the views of any of them. All >> parts of the document should be regarded as open for discussion. >> >> >> >> The IETF Secretariat. >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > David Singer > Multimedia and Software Standards, Apple Inc. > --------------060603090504010900070709 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 12/21/10 22:46, David Singer wrote:
I have to agree.  If IPR issues are what we want to avoid, VP8 seems like a poor choice (e.g. <http://www.digitaltrends.com/computing/mpeg-la-looking-at-patents-for-googles-vp8webm-video/>).
That article is by now 7 months old (May 2010), and AFAIK, no specific IPR claims have been made public.

I wouldn't presume to claim that this proves anything.

                      Harald


On Dec 21, 2010, at 13:38 , markus.isomaki@nokia.com wrote:

Hi Peter, all,
 
About the video codec: Are there any arguments on why VP8 would not have IPR issues? It is available as an open source implementation, but that does not mean there are no IPR against it. My understanding is that the IPR situation wrt. VP8 is still unclear and thus risky. The other issue with VP8 is, as far as I know, the lack of a clear spec out of which independent interoperable implementations can be created.
 
So I don’t at least buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons.
 
I’m working on a separate review on Harald’s drafts (thanks for putting them together) and will come back to the codec issue there in more detail, but just wanted to respond to Peter’s point here.
 
Regards,
                Markus
 
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Peter Musgrave
Sent: 17 December, 2010 13:48
To: Harald Alvestrand
Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie
Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00
 
I'd also like to echo Alan's thanks for these drafts. 
 
The protocol doc is very clear. [If you read only one dispatch draft this Christmas, make it this one. ;-)  ]
 
One observation to the group. The mandatory to implement video CODEC is VP8 (presumably since it does not have IPR issues - which some other choices would have). 
 
Regards, 
 
Peter Musgrave
 
 
Nits
Introduction
s/veichle/vehicle/
 
Section 2 Para "Within each.."
s/implementaiton/implementation/
 
Section 4 Para1
"such as" (something missing here?)
 
Section 5 Para2
"There is no third mandatory to implement" 
? Was there a mention of a third before. Not sure why this statement is there.
 
 
On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote:


This is the overview document for the IETF-related RTC-WEB work.

-------- Original Message --------
Subject:
New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00
Date:
Wed, 10 Nov 2010 03:31:05 -0800 (PST)
From:
IETF I-D Submission Tool <idsubmission@ietf.org>
To:

 

A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.
 
Filename:      draft-alvestrand-dispatch-rtcweb-protocols
Revision:      00
Title:         Overview: Real Time Protocols for Brower-based Applications
Creation_date:  2010-11-11
WG ID:         Independent Submission
Number_of_pages: 9
 
Abstract:
This document gives an overview of a protocol suite intended for use
with real-time applications that can be deployed in browsers - "real
time communication on the Web".
 
It intends to serve as a starting and coordination point to make sure
all the parts that are needed to achieve this goal are findable, and
that the parts that belong in the Internet protocol suite are fully
specified and on the right publication track.
 
This work is an attempt to synthesize the input of many people, but
makes no claims to fully represent the views of any of them.  All
parts of the document should be regarded as open for discussion.
                                                                                  
 
 
The IETF Secretariat.
 
 
 
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
 
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

David Singer
Multimedia and Software Standards, Apple Inc.


--------------060603090504010900070709-- From tterriberry@mozilla.com Wed Dec 22 07:23:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B623A6A35 for ; Wed, 22 Dec 2010 07:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+gpMSrFEcna for ; Wed, 22 Dec 2010 07:23:43 -0800 (PST) Received: from mxip3i.isis.unc.edu (mxip3i.isis.unc.edu [152.2.2.195]) by core3.amsl.com (Postfix) with ESMTP id CF6AD3A6A17 for ; Wed, 22 Dec 2010 07:23:42 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAN6mEU2sGgRS/2dsb2JhbACjP4FKwy6FSQSEZokvDA X-IronPort-AV: E=Sophos;i="4.60,213,1291611600"; d="scan'208";a="14815254" Received: from mr1a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.82]) by mxip3o.isis.unc.edu with ESMTP; 22 Dec 2010 10:25:38 -0500 Received: from [192.168.11.4] (pool-71-114-26-50.washdc.dsl-w.verizon.net [71.114.26.50]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id oBMFPaBO001934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Dec 2010 10:25:37 -0500 (EST) Message-ID: <4D121870.9090105@mozilla.com> Date: Wed, 22 Dec 2010 07:25:36 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101120 Gentoo/2.0.10 SeaMonkey/2.0.10 MIME-Version: 1.0 References: <4CDA833D.8080203@alvestrand.no>, , <4D1215CD.6090904@alvestrand.no> In-Reply-To: <4D1215CD.6090904@alvestrand.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 22 Dec 2010 07:30:23 -0800 Cc: rtc-web@alvestrand.no, dispatch@ietf.org Subject: Re: [dispatch] [RTW] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 15:23:43 -0000 > WRT IPR issues: I think we just have to push forward on the assumption > that all IPR holders who are part of the process will do their duty and > disclose any relevant IPR, and hope that IPR held by nonparticipants in > the process is not serious enough to cause us to regret our decision. We don't have to limit ourselves to just hope (and in this case I think it would be a bad idea). There are processes in other non-IETF standards organizations to address patents held by nonpaticipants as well (for example, a W3C PAG). From juberti@google.com Wed Dec 22 08:13:45 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2203A6AF8 for ; Wed, 22 Dec 2010 08:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqaMOBwvCBiK for ; Wed, 22 Dec 2010 08:13:43 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 04EA33A6B12 for ; Wed, 22 Dec 2010 08:13:42 -0800 (PST) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id oBMGFeag020960 for ; Wed, 22 Dec 2010 08:15:40 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1293034541; bh=VrqLDYAmX8L7jagyX3yWq+ewgfs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=n+1RwSfAQ61qBb5RnCkhFFwn9kshxZ2mjVKTv8vGVreZuKMkFvoNvROew6h1LrnUe WyCGfbaCUUbuWy900otGQ== Received: from qwh6 (qwh6.prod.google.com [10.241.194.198]) by hpaq5.eem.corp.google.com with ESMTP id oBMGFbaH016937 for ; Wed, 22 Dec 2010 08:15:39 -0800 Received: by qwh6 with SMTP id 6so5459971qwh.35 for ; Wed, 22 Dec 2010 08:15:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=McbPUi3cLJWZw/s0KYEOw9fd2kLUYQKpDdW+4EUtOsA=; b=VlVdAE1/ogP0vUqXv13w02MUKXfbReuzo6bDJal2ynsPXIXubp7MnFTZJqA2boFZCv dm2lN88aN1NM9dcGTYOw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=oQWwXpzJRGLnmZEF/MaR8Oq9vaOnQnTPorxXdwxZOalkyk2ouCbAd7J/DJaY29tO3C YkALo7hoNX9o+xGpX1gg== Received: by 10.229.186.75 with SMTP id cr11mr6260743qcb.113.1293034538789; Wed, 22 Dec 2010 08:15:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.135.9 with HTTP; Wed, 22 Dec 2010 08:15:18 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Wed, 22 Dec 2010 08:15:18 -0800 Message-ID: To: Ingemar Johansson S Content-Type: multipart/alternative; boundary=0016364ec8345deb80049802107c X-System-Of-Record: true X-Mailman-Approved-At: Wed, 22 Dec 2010 08:29:28 -0800 Cc: "rtc-web@alvestrand.no" , "dispatch@ietf.org" , "Markus.Isomaki@nokia.com" Subject: Re: [dispatch] [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 16:13:45 -0000 --0016364ec8345deb80049802107c Content-Type: text/plain; charset=UTF-8 Ingemar, RFC 3711 defines AES as the default encryption algorithm and HMAC-SHA1 as the default authentication algorithm for SRTP. As a result, those algorithms are used by pretty much every application that uses SRTP, which makes interoperability much easier. I think a similar statement can be made regarding the selection of MTI video codecs. There are various reasons why one might choose one codec versus another. But if we are unable to pick at least one default/MTI codec (for each media type), interoperability and thereby adoption of this platform will be much more challenging. --justin On Tue, Dec 21, 2010 at 11:44 PM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > Not meaning to express any preference in any direction but more a question > to the more experiened IETFers. > > My impression here is that algorithms devised outside the IETF are rarely > mandated in IETF frameworks. > > Two examples that I can come up with are > > SRTP (RFC3711): Only specifies the framework for secure RTP but does not > mandate any encryption/authentication algorithms. Not sure if excryption > algos are specified in separate RFC's > > FECFRAME (RFC6015): Specifies the framework for generic FEC, generic enough > to plug in any FEC algo, the actual FEC algos are specified in separate > drafs (http://tools.ietf.org/wg/fecframe/) > Perhaps there are similar examples in other IETF areas that can serve as > guidance ?, you may want to ping the eriIetf list on this (I leave it up to > you) > > So to me it seems like there is preference to _not_ mandate algorithms > (compression, fec, encryption) in IETF frameworks (I can imagine one > specific reason to this). And... as I believe that RTC-Web will be some kind > of framework I would say that this would apply here as well ?. > > Please feel free to bash my conclusion. > > /Ingemar > > > ------------------------------------------- > Message: 1 > Date: Tue, 21 Dec 2010 21:38:42 +0000 > From: > Subject: Re: [dispatch] Fwd: New Version Notification for > draft-alvestrand-dispatch-rtcweb-protocols-00 > To: , > Cc: rtc-web@alvestrand.no, dispatch@ietf.org, ted.ietf@gmail.com > Message-ID: > < > DD8B10B86502AB488CB2D3DB4C546E3806DA99@008-AM1MPN1-003.mgdnok.nokia.com> > > Content-Type: text/plain; charset="us-ascii" > > Hi Peter, all, > > About the video codec: Are there any arguments on why VP8 would not have > IPR issues? It is available as an open source implementation, but that does > not mean there are no IPR against it. My understanding is that the IPR > situation wrt. VP8 is still unclear and thus risky. The other issue with VP8 > is, as far as I know, the lack of a clear spec out of which independent > interoperable implementations can be created. > > So I don't at least buy the argument that we should choose VP8 as mandatory > to implement video codec because of IPR reasons. > > I'm working on a separate review on Harald's drafts (thanks for putting > them together) and will come back to the codec issue there in more detail, > but just wanted to respond to Peter's point here. > > Regards, > Markus > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of ext Peter Musgrave > Sent: 17 December, 2010 13:48 > To: Harald Alvestrand > Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie > Subject: Re: [dispatch] Fwd: New Version Notification for > draft-alvestrand-dispatch-rtcweb-protocols-00 > > I'd also like to echo Alan's thanks for these drafts. > > The protocol doc is very clear. [If you read only one dispatch draft this > Christmas, make it this one. ;-) ] > > One observation to the group. The mandatory to implement video CODEC is VP8 > (presumably since it does not have IPR issues - which some other choices > would have). > > Regards, > > Peter Musgrave > > > Nits > Introduction > s/veichle/vehicle/ > > Section 2 Para "Within each.." > s/implementaiton/implementation/ > > Section 4 Para1 > "such as" (something missing here?) > > Section 5 Para2 > "There is no third mandatory to implement" > ? Was there a mention of a third before. Not sure why this statement is > there. > > > On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: > > > This is the overview document for the IETF-related RTC-WEB work. > > -------- Original Message -------- > Subject: > > New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 > > Date: > > Wed, 10 Nov 2010 03:31:05 -0800 (PST) > > From: > > IETF I-D Submission Tool idsubmission@ietf.org> > > To: > > harald@alvestrand.no > > > > A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has > been successfully submitted by Harald Alvestrand and posted to the IETF > repository. > > > > Filename: draft-alvestrand-dispatch-rtcweb-protocols > > Revision: 00 > > Title: Overview: Real Time Protocols for Brower-based Applications > > Creation_date: 2010-11-11 > > WG ID: Independent Submission > > Number_of_pages: 9 > > > > Abstract: > > This document gives an overview of a protocol suite intended for use > > with real-time applications that can be deployed in browsers - "real > > time communication on the Web". > > > > It intends to serve as a starting and coordination point to make sure > > all the parts that are needed to achieve this goal are findable, and > > that the parts that belong in the Internet protocol suite are fully > > specified and on the right publication track. > > > > This work is an attempt to synthesize the input of many people, but > > makes no claims to fully represent the views of any of them. All > > parts of the document should be regarded as open for discussion. > > > > > > > > The IETF Secretariat. > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/dispatch/attachments/20101221/46ec4317/attachment.htm > > > > ------------------------------ > _______________________________________________ > RTC-Web mailing list > RTC-Web@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web > --0016364ec8345deb80049802107c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ingemar,

RFC 3711 defines AES as the default encryption = algorithm and HMAC-SHA1 as the default authentication algorithm for SRTP. A= s a result, those algorithms are used by pretty much every application that= uses SRTP, which makes interoperability much easier.

I think a similar statement can be made regarding the s= election of MTI video codecs. There are various reasons why one might choos= e one codec versus another. But if we are unable to pick at least one defau= lt/MTI codec (for each media type), interoperability and thereby adoption o= f this platform will be much more challenging.

--justin

On Tu= e, Dec 21, 2010 at 11:44 PM, Ingemar Johansson S <ingemar.s.johansson@ericsso= n.com> wrote:
Hi

Not meaning to express any preference in any direction but more a question = to the more experiened IETFers.

My impression here is that algorithms devised outside the IETF are rarely m= andated in IETF frameworks.

Two examples that I can come up with are

SRTP (RFC3711): Only specifies the framework for secure RTP but does not ma= ndate any encryption/authentication algorithms. Not sure if excryption algo= s are specified in separate RFC's

FECFRAME (RFC6015): Specifies the framework for generic FEC, generic enough= to plug in any FEC algo, the actual FEC algos are specified in separate dr= afs (http:= //tools.ietf.org/wg/fecframe/)
Perhaps there are similar examples in other IETF areas that can serve as gu= idance ?, you may want to ping the eriIetf list on this (I leave it up to y= ou)

So to me it seems like there is preference to _not_ mandate algorithms (com= pression, fec, encryption) in IETF frameworks (I can imagine one specific r= eason to this). And... as I believe that RTC-Web will be some kind of frame= work I would say that this would apply here as well ?.

Please feel free to bash my conclusion.

/Ingemar


-------------------------------------------
Message: 1
Date: Tue, 21 Dec 2010 21:38:42 +0000
From: <Markus.Isomaki@nokia.com>
Subject: Re: [dispatch] Fwd: New Version Notificati= on =C2=A0 for
=C2=A0 =C2=A0 =C2=A0 =C2=A0draft-alvestrand-dispatch-rtcweb-protocols-00
To: <peter.musgrave@magorcorp.com>, <harald@alvestrand.no>
Cc: rtc-web@alvestrand.no, dispatch@ietf.org, ted.ietf@gmail.com
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0<DD8B10B86502AB488CB2D3DB4C5= 46E3806DA99@008-AM1MPN1-003.mgdnok.nokia.com>

Content-Type: text/plain; charset=3D"us-ascii"

Hi Peter, all,

About the video codec: Are there any arguments on why VP8 would not have IP= R issues? It is available as an open source implementation, but that does n= ot mean there are no IPR against it. My understanding is that the IPR situa= tion wrt. VP8 is still unclear and thus risky. The other issue with VP8 is,= as far as I know, the lack of a clear spec out of which independent intero= perable implementations can be created.

So I don't at least buy the argument that we should choose VP8 as manda= tory to implement video codec because of IPR reasons.

I'm working on a separate review on Harald's drafts (thanks for put= ting them together) and will come back to the codec issue there in more det= ail, but just wanted to respond to Peter's point here.

Regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Markus

From: dispatch-bounces@ietf.or= g [mailto:dispatch-bounces= @ietf.org] On Behalf Of ext Peter Musgrave
Sent: 17 December, 2010 13:48
To: Harald Alvestrand
Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie
Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-= dispatch-rtcweb-protocols-00

I'd also like to echo Alan's thanks for these drafts.

The protocol doc is very clear. [If you read only one dispatch draft this C= hristmas, make it this one. ;-) =C2=A0]

One observation to the group. The mandatory to implement video CODEC is VP8= (presumably since it does not have IPR issues - which some other choices w= ould have).

Regards,

Peter Musgrave


Nits
Introduction
s/veichle/vehicle/

Section 2 Para "Within each.."
s/implementaiton/implementation/

Section 4 Para1
"such as" (something missing here?)

Section 5 Para2
"There is no third mandatory to implement"
? Was there a mention of a third before. Not sure why this statement is the= re.


On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote:


This is the overview document for the IETF-related RTC-WEB work.

-------- Original Message --------
Subject:

New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00<= br>
Date:

Wed, 10 Nov 2010 03:31:05 -0800 (PST)

From:

IETF I-D Submission Tool <idsubmission@ietf.org><mailto:idsubmission@ietf.org>

To:

harald@alvestrand.no<mailto:= harald@alvestrand.no>



A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has= been successfully submitted by Harald Alvestrand and posted to the IETF re= pository.



Filename: =C2=A0 =C2=A0 =C2=A0draft-alvestrand-dispatch-rtcweb-protocols
Revision: =C2=A0 =C2=A0 =C2=A000

Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 Overview: Real Time Protocols for Brower= -based Applications

Creation_date: =C2=A02010-11-11

WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 Independent Submission

Number_of_pages: 9



Abstract:

This document gives an overview of a protocol suite intended for use

with real-time applications that can be deployed in browsers - "real
time communication on the Web".



It intends to serve as a starting and coordination point to make sure

all the parts that are needed to achieve this goal are findable, and

that the parts that belong in the Internet protocol suite are fully

specified and on the right publication track.



This work is an attempt to synthesize the input of many people, but

makes no claims to fully represent the views of any of them. =C2=A0All

parts of the document should be regarded as open for discussion.







The IETF Secretariat.






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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/= mail-archive/web/dispatch/attachments/20101221/46ec4317/attachment.htm&= gt;

------------------------------
_________________________________________= ______
RTC-Web mailing list
RTC-Web@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtc-web

--0016364ec8345deb80049802107c-- From henry.sinnreich@gmail.com Wed Dec 22 09:44:57 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5C33A6B94 for ; Wed, 22 Dec 2010 09:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jdq7MY82xcdy for ; Wed, 22 Dec 2010 09:44:51 -0800 (PST) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id CFA963A6BB2 for ; Wed, 22 Dec 2010 09:44:50 -0800 (PST) Received: by gwb20 with SMTP id 20so4963407gwb.15 for ; Wed, 22 Dec 2010 09:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type; bh=Bp6nkhZHqSuDG3TEUC10FZsGhC5oBrtTkV8YuDdh3qs=; b=P6C0/aWfnynCkiHc4yLwsFVaiJy3RH8bXBL+pgSaviDVwHPZ6B2IVYu7D41wj0rZ/5 /pZw6Bdx17xA9VL4aoCuUVHcmqqN1GQVEgOaxlqcTfqavQTE5YCUzqd9RkCPK7Ii5/pC Sypp5woZnksmB7nwgV/Zvi77guKVLSQV+/a/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; b=L1UVSU0R9AaPTR3sQpSvovub6eCZnnXvR/aua1A8UnGATHFqeK1rEZMSAsNdZOsI2H Vjb36UO6di9g9q5zEZ8vOFX9cc/M9SsLDrlK9eWxBR4XLkfEQM9aa2K9b4z27uHq9jIJ /BmGPfvZsGPPAxk6BVlwn5pKQovJPdYVDSJxs= Received: by 10.151.49.18 with SMTP id b18mr10938794ybk.299.1293040005807; Wed, 22 Dec 2010 09:46:45 -0800 (PST) Received: from [10.0.1.7] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id r41sm5930552yba.4.2010.12.22.09.46.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Dec 2010 09:46:44 -0800 (PST) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 22 Dec 2010 11:46:41 -0600 From: Henry Sinnreich To: Harald Alvestrand , Bernard Aboba Message-ID: Thread-Topic: [dispatch] Codec standardization (Re: [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) Thread-Index: AcuiADCkxEOszWLxM0ydgoAqoQp+bQ== In-Reply-To: <4D1215CD.6090904@alvestrand.no> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3375863204_5722200" Cc: rtc-web@alvestrand.no, dispatch@ietf.org, Greg Herlein , ted.ietf@gmail.com Subject: Re: [dispatch] Codec standardization (Re: [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 17:44:57 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3375863204_5722200 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable >The statement about VP8 in the rtcweb-protocols document is a placeholder, >put in there to indicate that we need to have the discussion. It's not a W= G decision, but input to a WG discussion. This is an excellent position, thanks Harald! Now that many people agree on the need for an =B3IP-free as possible=B2 RTC Web codec, it would be a good start to make a short list of candidates and then discuss them on merit. Such as IMO (sorry I am not a video codec expert): V8, Theora and what other may contribute that require no IP. Even just starting with a table like http://en.wikipedia.org/wiki/Comparison_of_video_codecs To avoid rat holes and flames, I suggest not even to mention H.264 :-) except as an example for what not to adopt. Henry On 12/22/10 9:14 AM, "Harald Alvestrand" wrote: > On 12/22/10 07:18, Bernard Aboba wrote: >> It does appear presumptive to suggest that a codec that hasn't complet= ed a >> standardization process be made "mandatory to implement." >> =20 >> Since there have been some large judgments over use of allegedly "free" >> codecs, the lesson is that codecs that are claimed to be "free of >> encumbrance" may in time be discovered not to be.=A0 The IETF process can >> potentially be useful in helping to clarify the IPR status of codecs.=A0 >> However, those wheels grind slowly. >> =20 > I agree that we can't make anything mandatory to implement that we don't= have > an accepted stable, publicly available reference for. (I'm working on sol= ving > that for the case of VP8). > =20 > However, I don't agree that we necessarily have to complete a standards > process in order to refer to it; that would put, for instance, the Zip fo= rmat > (used, among other places, in OOXML and ODF) out of scope for standards. > =20 > WRT IPR issues: I think we just have to push forward on the assumption t= hat > all IPR holders who are part of the process will do their duty and disclo= se > any relevant IPR, and hope that IPR held by nonparticipants in the proces= s is > not serious enough to cause us to regret our decision. > =20 > Note: The statement about VP8 in the rtcweb-protocols document is a > placeholder, put in there to indicate that we need to have the discussion= . > It's not a WG decision, but input to a WG discussion. > =20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Harald > =20 > =20 > =20 > =20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --B_3375863204_5722200 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [dispatch] Codec standardization (Re: [RTW] Fwd: New Version Not= ification for draft-alvestrand-dispatch-rtcweb-protocols-00) >The statement about VP8 in the rtcweb-protocols document is a placehol= der,
>put in there to indicate that we need to have the discussion. It's not = a WG decision, but input to a WG discussion.

This is an excellent position, thanks Harald!

Now that many people agree on the need for an “IP-free as possible= 221; RTC Web codec, it would be a good start to make a short list of candida= tes and then discuss them on merit. Such as IMO (sorry I am not a video code= c expert): V8, Theora and what other may contribute that require no IP. Even= just starting with a table like
http://en= .wikipedia.org/wiki/Comparison_of_video_codecs

To avoid rat holes and flames, I suggest not even to mention H.264 :-) exce= pt as an example for what not to adopt.

Henry


On 12/22/10 9:14 AM, "Harald Alvestrand" <harald@alvestrand.no> wrote:

<= SPAN STYLE=3D'font-size:13pt'>   On 12/22/10 07:18, Bernard Aboba wr= ote:
<= SPAN STYLE=3D'font-size:13pt'>  It does appear presumptive to suggest tha= t a codec that hasn't completed a standardization process be made "mand= atory to implement."
 
 Since there have been some large judgments over use of allegedly &quo= t;free" codecs, the lesson is that codecs that are claimed to be "= free of encumbrance" may in time be discovered not to be.=A0 The IETF pro= cess can potentially be useful in helping to clarify the IPR status of codec= s.=A0 However, those wheels grind slowly.
 
= I agree that we can't make anything mandatory = to implement that we don't have an accepted stable, publicly available refer= ence for. (I'm working on solving that for the case of VP8).
 
 However, I don't agree that we necessarily have to complete a standar= ds process in order to refer to it; that would put, for instance, the Zip fo= rmat (used, among other places, in OOXML and ODF) out of scope for standards= .
 
 WRT IPR issues: I think we just have to push forward on the assumptio= n that all IPR holders who are part of the process will do their duty and di= sclose any relevant IPR, and hope that IPR held by nonparticipants in the pr= ocess is not serious enough to cause us to regret our decision.
 
 Note: The statement about VP8 in the rtcweb-protocols document is a p= laceholder, put in there to indicate that we need to have the discussion. It= 's not a WG decision, but input to a WG discussion.
 
 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Harald
 
 
 
 
__________________________= _____________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dispatch
--B_3375863204_5722200-- From Markus.Isomaki@nokia.com Wed Dec 22 13:11:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22203A68BE for ; Wed, 22 Dec 2010 13:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.484 X-Spam-Level: X-Spam-Status: No, score=-4.484 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95kJmd5dsCOT for ; Wed, 22 Dec 2010 13:11:01 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 210AE3A6B82 for ; Wed, 22 Dec 2010 13:10:57 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBMLCmDg017473; Wed, 22 Dec 2010 23:12:50 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 23:12:43 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 22 Dec 2010 22:12:43 +0100 Received: from 008-AM1MPN1-003.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi; Wed, 22 Dec 2010 22:12:43 +0100 From: To: , Thread-Topic: Codec standardization (Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) Thread-Index: AQHLoerrMKmBEv+rBUKb7AaARfoLD5Os8Ykg Date: Wed, 22 Dec 2010 21:12:41 +0000 Message-ID: References: <4CDA833D.8080203@alvestrand.no>, , <4D1215CD.6090904@alvestrand.no> In-Reply-To: <4D1215CD.6090904@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_DD8B10B86502AB488CB2D3DB4C546E38082C42008AM1MPN1003mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 22 Dec 2010 21:12:43.0773 (UTC) FILETIME=[F96E4AD0:01CBA21C] X-Nokia-AV: Clean Cc: rtc-web@alvestrand.no, dispatch@ietf.org, ted.ietf@gmail.com Subject: Re: [dispatch] Codec standardization (Re: [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 21:11:11 -0000 --_000_DD8B10B86502AB488CB2D3DB4C546E38082C42008AM1MPN1003mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Harald, We can reference things as long as they are public and stable. But I also t= hink that if we were to mandate some technology as part of an IETF standard= , the future development of that technology should preferably be done under= an open process. How does the future development of VP8 (or VP9) will happ= en from that point of view? I've seen some concerns about this so it would = be good to get the facts. As long as VP8 spec itself is not published as an Internet-draft, I don't s= uppose the IETF IPR rules apply to it. So I'm not sure which process we are= following with it right now. That would be good to clarify. Regards, Markus From: ext Harald Alvestrand [mailto:harald@alvestrand.no] Sent: 22 December, 2010 17:14 To: Bernard Aboba Cc: Isomaki Markus (Nokia-CIC/Espoo); peter.musgrave@magorcorp.com; rtc-web= @alvestrand.no; dispatch@ietf.org; ted.ietf@gmail.com Subject: Codec standardization (Re: [RTW] [dispatch] Fwd: New Version Notif= ication for draft-alvestrand-dispatch-rtcweb-protocols-00) On 12/22/10 07:18, Bernard Aboba wrote: It does appear presumptive to suggest that a codec that hasn't completed a = standardization process be made "mandatory to implement." Since there have been some large judgments over use of allegedly "free" cod= ecs, the lesson is that codecs that are claimed to be "free of encumbrance"= may in time be discovered not to be. The IETF process can potentially be = useful in helping to clarify the IPR status of codecs. However, those whee= ls grind slowly. I agree that we can't make anything mandatory to implement that we don't ha= ve an accepted stable, publicly available reference for. (I'm working on so= lving that for the case of VP8). However, I don't agree that we necessarily have to complete a standards pro= cess in order to refer to it; that would put, for instance, the Zip format = (used, among other places, in OOXML and ODF) out of scope for standards. WRT IPR issues: I think we just have to push forward on the assumption that= all IPR holders who are part of the process will do their duty and disclos= e any relevant IPR, and hope that IPR held by nonparticipants in the proces= s is not serious enough to cause us to regret our decision. Note: The statement about VP8 in the rtcweb-protocols document is a placeho= lder, put in there to indicate that we need to have the discussion. It's no= t a WG decision, but input to a WG discussion. Harald --_000_DD8B10B86502AB488CB2D3DB4C546E38082C42008AM1MPN1003mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Harald,

 

We can reference things as long as they are public and stabl= e. But I also think that if we were to mandate some technology as part of an I= ETF standard, the future development of that technology should preferably be do= ne under an open process. How does the future development of VP8 (or VP9) will happen from that point of view? I’ve seen some concerns about this so= it would be good to get the facts.

 

As long as VP8 spec itself is not published as an Internet-d= raft, I don’t suppose the IETF IPR rules apply to it. So I’m not sure which process we are following with it right now. That would be good to clarify.

 

Regards,

          =       Markus

 

 

From: ext Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: 22 December, 2010 17:14
To: Bernard Aboba
Cc: Isomaki Markus (Nokia-CIC/Espoo); peter.musgrave@magorcorp.com; rtc-web@alvestrand.no; dispatch@ietf.org; ted.ietf@gmail.com
Subject: Codec standardization (Re: [RTW] [dispatch] Fwd: New Versio= n Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)<= /span>

 

On 12/22/10 07:18, Bernard Aboba wrote:

It does appear presumptive to suggest that a codec tha= t hasn't completed a standardization process be made "mandatory to implement."

Since there have been some large judgments over use of allegedly "free" codecs, the lesson is that codecs that are claimed to be "free of encumbrance" may in time be discovered not to be.  = The IETF process can potentially be useful in helping to clarify the IPR status= of codecs.  However, those wheels grind slowly.

I agree that we can't m= ake anything mandatory to implement that we don't have an accepted stable, publ= icly available reference for. (I'm working on solving that for the case of VP8).=

However, I don't agree that we necessarily have to complete a standards pro= cess in order to refer to it; that would put, for instance, the Zip format (used= , among other places, in OOXML and ODF) out of scope for standards.

WRT IPR issues: I think we just have to push forward on the assumption that= all IPR holders who are part of the process will do their duty and disclose any relevant IPR, and hope that IPR held by nonparticipants in the process is n= ot serious enough to cause us to regret our decision.

Note: The statement about VP8 in the rtcweb-protocols document is a placeholder, put in there to indicate that we need to have the discussion. = It's not a WG decision, but input to a WG discussion.

            &nb= sp;         Harald


--_000_DD8B10B86502AB488CB2D3DB4C546E38082C42008AM1MPN1003mgdn_-- From Markus.Isomaki@nokia.com Wed Dec 22 13:32:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C40C3A68BA for ; Wed, 22 Dec 2010 13:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.373 X-Spam-Level: X-Spam-Status: No, score=-4.373 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maIRSuKwpUzp for ; Wed, 22 Dec 2010 13:32:39 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 29D883A68BE for ; Wed, 22 Dec 2010 13:32:38 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBMLYLK7003029; Wed, 22 Dec 2010 23:34:25 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 23:34:18 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 22 Dec 2010 22:34:17 +0100 Received: from 008-AM1MPN1-003.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi; Wed, 22 Dec 2010 22:34:17 +0100 From: To: , Thread-Topic: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Thread-Index: AQHLofOJPFDT+2SanEqfIel6xBFOZZOs9hag Date: Wed, 22 Dec 2010 21:34:15 +0000 Message-ID: References: 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_DD8B10B86502AB488CB2D3DB4C546E38082C70008AM1MPN1003mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 22 Dec 2010 21:34:18.0200 (UTC) FILETIME=[FCF82D80:01CBA21F] X-Nokia-AV: Clean Cc: rtc-web@alvestrand.no, dispatch@ietf.org Subject: Re: [dispatch] [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 21:32:41 -0000 --_000_DD8B10B86502AB488CB2D3DB4C546E38082C70008AM1MPN1003mgdn_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpJdCB3b3VsZCBiZSB2ZXJ5IGRlc2lyYWJsZSB0byBhZ3JlZSBvbiB0aGUg TVRJIGNvZGVjcyBmb3IgYm90aCBhdWRpbyBhbmQgdmlkZW8gdG8gZW5zdXJlIGludGVyb3BlcmFi aWxpdHkuIEFzIHlvdSBzYXkgcGVvcGxlL2NvbXBhbmllcyBoYXZlIGRpZmZlcmVudCByZWFzb25z IGZvciBwcmVmZXJyaW5nIGNvZGVjcy4gSW4gY2FzZSBvZiB2aWRlbyBjb2RlY3MgdGhlIHJlYWxp dHkgaXMgdGhhdCBpdCB3aWxsIGJlIHZlcnkgZGlmZmljdWx0IHRvIHJlYWNoIGFuIGFncmVlbWVu dCBvdmVyIFZQOCB2cy4gSC4yNjQuDQoNCk9uZSBvZiB0aGUgcHJhY3RpY2FsIHJlYXNvbnMgdG8g cHJlZmVyIEguMjY0IGlzIHRoYXQgaXMgYWxyZWFkeSBzbyB3aWRlbHkgc3VwcG9ydGVkLiBGb3Ig aW5zdGFuY2UgaW4gbW9iaWxlIGRldmljZXMgSFcgYWNjZWxlcmF0aW9uIGlzIGltcG9ydGFudCAo ZXNwZWNpYWxseSBmb3IgZW5jb2RpbmcpLCBhbmQgd2UgaGF2ZSBpdCB0b2RheSBpbiBtYW55IHBs YXRmb3JtcyBmb3IgSC4yNjQsIGJ1dCBub3QgbmVjZXNzYXJpbHkgZm9yIG90aGVyIHZpZGVvIGNv ZGVjcy4NCg0KTWFya3VzDQoNCg0KRnJvbTogZXh0IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJl cnRpQGdvb2dsZS5jb21dDQpTZW50OiAyMiBEZWNlbWJlciwgMjAxMCAxODoxNQ0KVG86IEluZ2Vt YXIgSm9oYW5zc29uIFMNCkNjOiBkaXNwYXRjaEBpZXRmLm9yZzsgcnRjLXdlYkBhbHZlc3RyYW5k Lm5vOyBJc29tYWtpIE1hcmt1cyAoTm9raWEtQ0lDL0VzcG9vKQ0KU3ViamVjdDogUmU6IFtSVFdd IFtkaXNwYXRjaF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWFsdmVz dHJhbmQtZGlzcGF0Y2gtcnRjd2ViLXByb3RvY29scy0wMA0KDQpJbmdlbWFyLA0KDQpSRkMgMzcx MSBkZWZpbmVzIEFFUyBhcyB0aGUgZGVmYXVsdCBlbmNyeXB0aW9uIGFsZ29yaXRobSBhbmQgSE1B Qy1TSEExIGFzIHRoZSBkZWZhdWx0IGF1dGhlbnRpY2F0aW9uIGFsZ29yaXRobSBmb3IgU1JUUC4g QXMgYSByZXN1bHQsIHRob3NlIGFsZ29yaXRobXMgYXJlIHVzZWQgYnkgcHJldHR5IG11Y2ggZXZl cnkgYXBwbGljYXRpb24gdGhhdCB1c2VzIFNSVFAsIHdoaWNoIG1ha2VzIGludGVyb3BlcmFiaWxp dHkgbXVjaCBlYXNpZXIuDQoNCkkgdGhpbmsgYSBzaW1pbGFyIHN0YXRlbWVudCBjYW4gYmUgbWFk ZSByZWdhcmRpbmcgdGhlIHNlbGVjdGlvbiBvZiBNVEkgdmlkZW8gY29kZWNzLiBUaGVyZSBhcmUg dmFyaW91cyByZWFzb25zIHdoeSBvbmUgbWlnaHQgY2hvb3NlIG9uZSBjb2RlYyB2ZXJzdXMgYW5v dGhlci4gQnV0IGlmIHdlIGFyZSB1bmFibGUgdG8gcGljayBhdCBsZWFzdCBvbmUgZGVmYXVsdC9N VEkgY29kZWMgKGZvciBlYWNoIG1lZGlhIHR5cGUpLCBpbnRlcm9wZXJhYmlsaXR5IGFuZCB0aGVy ZWJ5IGFkb3B0aW9uIG9mIHRoaXMgcGxhdGZvcm0gd2lsbCBiZSBtdWNoIG1vcmUgY2hhbGxlbmdp bmcuDQoNCi0tanVzdGluDQoNCk9uIFR1ZSwgRGVjIDIxLCAyMDEwIGF0IDExOjQ0IFBNLCBJbmdl bWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTxtYWlsdG86 aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpDQoNCk5vdCBtZWFu aW5nIHRvIGV4cHJlc3MgYW55IHByZWZlcmVuY2UgaW4gYW55IGRpcmVjdGlvbiBidXQgbW9yZSBh IHF1ZXN0aW9uIHRvIHRoZSBtb3JlIGV4cGVyaWVuZWQgSUVURmVycy4NCg0KTXkgaW1wcmVzc2lv biBoZXJlIGlzIHRoYXQgYWxnb3JpdGhtcyBkZXZpc2VkIG91dHNpZGUgdGhlIElFVEYgYXJlIHJh cmVseSBtYW5kYXRlZCBpbiBJRVRGIGZyYW1ld29ya3MuDQoNClR3byBleGFtcGxlcyB0aGF0IEkg Y2FuIGNvbWUgdXAgd2l0aCBhcmUNCg0KU1JUUCAoUkZDMzcxMSk6IE9ubHkgc3BlY2lmaWVzIHRo ZSBmcmFtZXdvcmsgZm9yIHNlY3VyZSBSVFAgYnV0IGRvZXMgbm90IG1hbmRhdGUgYW55IGVuY3J5 cHRpb24vYXV0aGVudGljYXRpb24gYWxnb3JpdGhtcy4gTm90IHN1cmUgaWYgZXhjcnlwdGlvbiBh bGdvcyBhcmUgc3BlY2lmaWVkIGluIHNlcGFyYXRlIFJGQydzDQoNCkZFQ0ZSQU1FIChSRkM2MDE1 KTogU3BlY2lmaWVzIHRoZSBmcmFtZXdvcmsgZm9yIGdlbmVyaWMgRkVDLCBnZW5lcmljIGVub3Vn aCB0byBwbHVnIGluIGFueSBGRUMgYWxnbywgdGhlIGFjdHVhbCBGRUMgYWxnb3MgYXJlIHNwZWNp ZmllZCBpbiBzZXBhcmF0ZSBkcmFmcyAoaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2ZlY2ZyYW1l LykNClBlcmhhcHMgdGhlcmUgYXJlIHNpbWlsYXIgZXhhbXBsZXMgaW4gb3RoZXIgSUVURiBhcmVh cyB0aGF0IGNhbiBzZXJ2ZSBhcyBndWlkYW5jZSA/LCB5b3UgbWF5IHdhbnQgdG8gcGluZyB0aGUg ZXJpSWV0ZiBsaXN0IG9uIHRoaXMgKEkgbGVhdmUgaXQgdXAgdG8geW91KQ0KDQpTbyB0byBtZSBp dCBzZWVtcyBsaWtlIHRoZXJlIGlzIHByZWZlcmVuY2UgdG8gX25vdF8gbWFuZGF0ZSBhbGdvcml0 aG1zIChjb21wcmVzc2lvbiwgZmVjLCBlbmNyeXB0aW9uKSBpbiBJRVRGIGZyYW1ld29ya3MgKEkg Y2FuIGltYWdpbmUgb25lIHNwZWNpZmljIHJlYXNvbiB0byB0aGlzKS4gQW5kLi4uIGFzIEkgYmVs aWV2ZSB0aGF0IFJUQy1XZWIgd2lsbCBiZSBzb21lIGtpbmQgb2YgZnJhbWV3b3JrIEkgd291bGQg c2F5IHRoYXQgdGhpcyB3b3VsZCBhcHBseSBoZXJlIGFzIHdlbGwgPy4NCg0KUGxlYXNlIGZlZWwg ZnJlZSB0byBiYXNoIG15IGNvbmNsdXNpb24uDQoNCi9JbmdlbWFyDQoNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KTWVzc2FnZTogMQ0KRGF0ZTogVHVlLCAy MSBEZWMgMjAxMCAyMTozODo0MiArMDAwMA0KRnJvbTogPE1hcmt1cy5Jc29tYWtpQG5va2lhLmNv bTxtYWlsdG86TWFya3VzLklzb21ha2lAbm9raWEuY29tPj4NClN1YmplY3Q6IFJlOiBbZGlzcGF0 Y2hdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uICAgZm9yDQogICAgICAgZHJhZnQtYWx2 ZXN0cmFuZC1kaXNwYXRjaC1ydGN3ZWItcHJvdG9jb2xzLTAwDQpUbzogPHBldGVyLm11c2dyYXZl QG1hZ29yY29ycC5jb208bWFpbHRvOnBldGVyLm11c2dyYXZlQG1hZ29yY29ycC5jb20+PiwgPGhh cmFsZEBhbHZlc3RyYW5kLm5vPG1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubz4+DQpDYzogcnRj LXdlYkBhbHZlc3RyYW5kLm5vPG1haWx0bzpydGMtd2ViQGFsdmVzdHJhbmQubm8+LCBkaXNwYXRj aEBpZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmc+LCB0ZWQuaWV0ZkBnbWFpbC5jb208 bWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbT4NCk1lc3NhZ2UtSUQ6DQogICAgICAgPEREOEIxMEI4 NjUwMkFCNDg4Q0IyRDNEQjRDNTQ2RTM4MDZEQTk5QDAwOC1BTTFNUE4xLTAwMy5tZ2Rub2subm9r aWEuY29tPG1haWx0bzpERDhCMTBCODY1MDJBQjQ4OENCMkQzREI0QzU0NkUzODA2REE5OUAwMDgt QU0xTVBOMS0wMDMubWdkbm9rLm5va2lhLmNvbT4+DQoNCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFp bjsgY2hhcnNldD0idXMtYXNjaWkiDQoNCkhpIFBldGVyLCBhbGwsDQoNCkFib3V0IHRoZSB2aWRl byBjb2RlYzogQXJlIHRoZXJlIGFueSBhcmd1bWVudHMgb24gd2h5IFZQOCB3b3VsZCBub3QgaGF2 ZSBJUFIgaXNzdWVzPyBJdCBpcyBhdmFpbGFibGUgYXMgYW4gb3BlbiBzb3VyY2UgaW1wbGVtZW50 YXRpb24sIGJ1dCB0aGF0IGRvZXMgbm90IG1lYW4gdGhlcmUgYXJlIG5vIElQUiBhZ2FpbnN0IGl0 LiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIElQUiBzaXR1YXRpb24gd3J0LiBWUDggaXMg c3RpbGwgdW5jbGVhciBhbmQgdGh1cyByaXNreS4gVGhlIG90aGVyIGlzc3VlIHdpdGggVlA4IGlz LCBhcyBmYXIgYXMgSSBrbm93LCB0aGUgbGFjayBvZiBhIGNsZWFyIHNwZWMgb3V0IG9mIHdoaWNo IGluZGVwZW5kZW50IGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zIGNhbiBiZSBjcmVhdGVk Lg0KDQpTbyBJIGRvbid0IGF0IGxlYXN0IGJ1eSB0aGUgYXJndW1lbnQgdGhhdCB3ZSBzaG91bGQg Y2hvb3NlIFZQOCBhcyBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IHZpZGVvIGNvZGVjIGJlY2F1c2Ug b2YgSVBSIHJlYXNvbnMuDQoNCkknbSB3b3JraW5nIG9uIGEgc2VwYXJhdGUgcmV2aWV3IG9uIEhh cmFsZCdzIGRyYWZ0cyAodGhhbmtzIGZvciBwdXR0aW5nIHRoZW0gdG9nZXRoZXIpIGFuZCB3aWxs IGNvbWUgYmFjayB0byB0aGUgY29kZWMgaXNzdWUgdGhlcmUgaW4gbW9yZSBkZXRhaWwsIGJ1dCBq dXN0IHdhbnRlZCB0byByZXNwb25kIHRvIFBldGVyJ3MgcG9pbnQgaGVyZS4NCg0KUmVnYXJkcywN CiAgICAgICAgICAgICAgIE1hcmt1cw0KDQpGcm9tOiBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmRpc3BhdGNoLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYg T2YgZXh0IFBldGVyIE11c2dyYXZlDQpTZW50OiAxNyBEZWNlbWJlciwgMjAxMCAxMzo0OA0KVG86 IEhhcmFsZCBBbHZlc3RyYW5kDQpDYzogcnRjLXdlYkBhbHZlc3RyYW5kLm5vPG1haWx0bzpydGMt d2ViQGFsdmVzdHJhbmQubm8+OyBkaXNwYXRjaEBpZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2hAaWV0 Zi5vcmc+OyBUZWQgSGFyZGllDQpTdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBGd2Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYWx2ZXN0cmFuZC1kaXNwYXRjaC1ydGN3ZWItcHJv dG9jb2xzLTAwDQoNCkknZCBhbHNvIGxpa2UgdG8gZWNobyBBbGFuJ3MgdGhhbmtzIGZvciB0aGVz ZSBkcmFmdHMuDQoNClRoZSBwcm90b2NvbCBkb2MgaXMgdmVyeSBjbGVhci4gW0lmIHlvdSByZWFk IG9ubHkgb25lIGRpc3BhdGNoIGRyYWZ0IHRoaXMgQ2hyaXN0bWFzLCBtYWtlIGl0IHRoaXMgb25l LiA7LSkgIF0NCg0KT25lIG9ic2VydmF0aW9uIHRvIHRoZSBncm91cC4gVGhlIG1hbmRhdG9yeSB0 byBpbXBsZW1lbnQgdmlkZW8gQ09ERUMgaXMgVlA4IChwcmVzdW1hYmx5IHNpbmNlIGl0IGRvZXMg bm90IGhhdmUgSVBSIGlzc3VlcyAtIHdoaWNoIHNvbWUgb3RoZXIgY2hvaWNlcyB3b3VsZCBoYXZl KS4NCg0KUmVnYXJkcywNCg0KUGV0ZXIgTXVzZ3JhdmUNCg0KDQpOaXRzDQpJbnRyb2R1Y3Rpb24N CnMvdmVpY2hsZS92ZWhpY2xlLw0KDQpTZWN0aW9uIDIgUGFyYSAiV2l0aGluIGVhY2guLiINCnMv aW1wbGVtZW50YWl0b24vaW1wbGVtZW50YXRpb24vDQoNClNlY3Rpb24gNCBQYXJhMQ0KInN1Y2gg YXMiIChzb21ldGhpbmcgbWlzc2luZyBoZXJlPykNCg0KU2VjdGlvbiA1IFBhcmEyDQoiVGhlcmUg aXMgbm8gdGhpcmQgbWFuZGF0b3J5IHRvIGltcGxlbWVudCINCj8gV2FzIHRoZXJlIGEgbWVudGlv biBvZiBhIHRoaXJkIGJlZm9yZS4gTm90IHN1cmUgd2h5IHRoaXMgc3RhdGVtZW50IGlzIHRoZXJl Lg0KDQoNCk9uIDIwMTAtMTEtMTAsIGF0IDY6MzQgQU0sIEhhcmFsZCBBbHZlc3RyYW5kIHdyb3Rl Og0KDQoNClRoaXMgaXMgdGhlIG92ZXJ2aWV3IGRvY3VtZW50IGZvciB0aGUgSUVURi1yZWxhdGVk IFJUQy1XRUIgd29yay4NCg0KLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0KU3Vi amVjdDoNCg0KTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1hbHZlc3RyYW5kLWRp c3BhdGNoLXJ0Y3dlYi1wcm90b2NvbHMtMDANCg0KRGF0ZToNCg0KV2VkLCAxMCBOb3YgMjAxMCAw MzozMTowNSAtMDgwMCAoUFNUKQ0KDQpGcm9tOg0KSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIDxp ZHN1Ym1pc3Npb25AaWV0Zi5vcmc8bWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZz4+PG1haWx0 bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmc8bWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZz4+DQoN ClRvOg0KDQpoYXJhbGRAYWx2ZXN0cmFuZC5ubzxtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm8+ PG1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubzxtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm8+ Pg0KDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWFsdmVzdHJhbmQtZGlzcGF0Y2gt cnRjd2ViLXByb3RvY29scy0wMC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBIYXJhbGQgQWx2ZXN0cmFuZCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoN Cg0KDQpGaWxlbmFtZTogICAgICBkcmFmdC1hbHZlc3RyYW5kLWRpc3BhdGNoLXJ0Y3dlYi1wcm90 b2NvbHMNCg0KUmV2aXNpb246ICAgICAgMDANCg0KVGl0bGU6ICAgICAgICAgT3ZlcnZpZXc6IFJl YWwgVGltZSBQcm90b2NvbHMgZm9yIEJyb3dlci1iYXNlZCBBcHBsaWNhdGlvbnMNCg0KQ3JlYXRp b25fZGF0ZTogIDIwMTAtMTEtMTENCg0KV0cgSUQ6ICAgICAgICAgSW5kZXBlbmRlbnQgU3VibWlz c2lvbg0KDQpOdW1iZXJfb2ZfcGFnZXM6IDkNCg0KDQoNCkFic3RyYWN0Og0KDQpUaGlzIGRvY3Vt ZW50IGdpdmVzIGFuIG92ZXJ2aWV3IG9mIGEgcHJvdG9jb2wgc3VpdGUgaW50ZW5kZWQgZm9yIHVz ZQ0KDQp3aXRoIHJlYWwtdGltZSBhcHBsaWNhdGlvbnMgdGhhdCBjYW4gYmUgZGVwbG95ZWQgaW4g YnJvd3NlcnMgLSAicmVhbA0KDQp0aW1lIGNvbW11bmljYXRpb24gb24gdGhlIFdlYiIuDQoNCg0K DQpJdCBpbnRlbmRzIHRvIHNlcnZlIGFzIGEgc3RhcnRpbmcgYW5kIGNvb3JkaW5hdGlvbiBwb2lu dCB0byBtYWtlIHN1cmUNCg0KYWxsIHRoZSBwYXJ0cyB0aGF0IGFyZSBuZWVkZWQgdG8gYWNoaWV2 ZSB0aGlzIGdvYWwgYXJlIGZpbmRhYmxlLCBhbmQNCg0KdGhhdCB0aGUgcGFydHMgdGhhdCBiZWxv bmcgaW4gdGhlIEludGVybmV0IHByb3RvY29sIHN1aXRlIGFyZSBmdWxseQ0KDQpzcGVjaWZpZWQg YW5kIG9uIHRoZSByaWdodCBwdWJsaWNhdGlvbiB0cmFjay4NCg0KDQoNClRoaXMgd29yayBpcyBh biBhdHRlbXB0IHRvIHN5bnRoZXNpemUgdGhlIGlucHV0IG9mIG1hbnkgcGVvcGxlLCBidXQNCg0K bWFrZXMgbm8gY2xhaW1zIHRvIGZ1bGx5IHJlcHJlc2VudCB0aGUgdmlld3Mgb2YgYW55IG9mIHRo ZW0uICBBbGwNCg0KcGFydHMgb2YgdGhlIGRvY3VtZW50IHNob3VsZCBiZSByZWdhcmRlZCBhcyBv cGVuIGZvciBkaXNjdXNzaW9uLg0KDQoNCg0KDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdC4N Cg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCmRpc3BhdGNoQGlldGYub3JnPG1haWx0bzpkaXNw YXRjaEBpZXRmLm9yZz48bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnPG1haWx0bzpkaXNwYXRjaEBp ZXRmLm9yZz4+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNo DQotLS0tLS0tLS0tLS0tLSBuZXh0IHBhcnQgLS0tLS0tLS0tLS0tLS0NCkFuIEhUTUwgYXR0YWNo bWVudCB3YXMgc2NydWJiZWQuLi4NClVSTDogPGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9kaXNwYXRjaC9hdHRhY2htZW50cy8yMDEwMTIyMS80NmVjNDMxNy9hdHRhY2htZW50 Lmh0bT4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUlRDLVdlYiBtYWlsaW5nIGxpc3QNClJU Qy1XZWJAYWx2ZXN0cmFuZC5ubzxtYWlsdG86UlRDLVdlYkBhbHZlc3RyYW5kLm5vPg0KaHR0cDov L3d3dy5hbHZlc3RyYW5kLm5vL21haWxtYW4vbGlzdGluZm8vcnRjLXdlYg0KDQo= --_000_DD8B10B86502AB488CB2D3DB4C546E38082C70008AM1MPN1003mgdn_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRl bnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1H ZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0K PHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQg NCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0K PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYg Y2xhc3M9V29yZFNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9y OiMxRjQ5N0QnPkhpIEp1c3Rpbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkl0IHdv dWxkIGJlIHZlcnkgZGVzaXJhYmxlIHRvIGFncmVlIG9uIHRoZSBNVEkgY29kZWNzIGZvciBib3Ro DQphdWRpbyBhbmQgdmlkZW8gdG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHkuIEFzIHlvdSBzYXkg cGVvcGxlL2NvbXBhbmllcyBoYXZlDQpkaWZmZXJlbnQgcmVhc29ucyBmb3IgcHJlZmVycmluZyBj b2RlY3MuIEluIGNhc2Ugb2YgdmlkZW8gY29kZWNzIHRoZSByZWFsaXR5IGlzDQp0aGF0IGl0IHdp bGwgYmUgdmVyeSBkaWZmaWN1bHQgdG8gcmVhY2ggYW4gYWdyZWVtZW50IG92ZXIgVlA4IHZzLiBI LjI2NC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5PbmUgb2YgdGhlIHByYWN0aWNh bCByZWFzb25zIHRvIHByZWZlciBILjI2NCBpcyB0aGF0IGlzIGFscmVhZHkNCnNvIHdpZGVseSBz dXBwb3J0ZWQuIEZvciBpbnN0YW5jZSBpbiBtb2JpbGUgZGV2aWNlcyBIVyBhY2NlbGVyYXRpb24g aXMNCmltcG9ydGFudCAoZXNwZWNpYWxseSBmb3IgZW5jb2RpbmcpLCBhbmQgd2UgaGF2ZSBpdCB0 b2RheSBpbiBtYW55IHBsYXRmb3JtcyBmb3INCkguMjY0LCBidXQgbm90IG5lY2Vzc2FyaWx5IGZv ciBvdGhlciB2aWRlbyBjb2RlY3MuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+TWFy a3VzPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN CmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+DQoNCjxkaXY+DQoNCjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPiBleHQgSnVzdGluIFViZXJ0aQ0KW21haWx0bzpqdWJlcnRpQGdvb2ds ZS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiAyMiBEZWNlbWJlciwgMjAxMCAxODoxNTxicj4NCjxi PlRvOjwvYj4gSW5nZW1hciBKb2hhbnNzb24gUzxicj4NCjxiPkNjOjwvYj4gZGlzcGF0Y2hAaWV0 Zi5vcmc7IHJ0Yy13ZWJAYWx2ZXN0cmFuZC5ubzsgSXNvbWFraSBNYXJrdXMNCihOb2tpYS1DSUMv RXNwb28pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbUlRXXSBbZGlzcGF0Y2hdIEZ3ZDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1hbHZlc3RyYW5kLWRpc3BhdGNoLXJ0Y3dl Yi1wcm90b2NvbHMtMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+SW5nZW1hciw8bzpwPjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPlJGQyAzNzExIGRlZmluZXMgQUVTIGFzIHRoZSBkZWZhdWx0IGVuY3J5cHRp b24gYWxnb3JpdGhtIGFuZA0KSE1BQy1TSEExIGFzIHRoZSBkZWZhdWx0IGF1dGhlbnRpY2F0aW9u IGFsZ29yaXRobSBmb3IgU1JUUC4gQXMgYSByZXN1bHQsIHRob3NlDQphbGdvcml0aG1zIGFyZSB1 c2VkIGJ5IHByZXR0eSBtdWNoIGV2ZXJ5IGFwcGxpY2F0aW9uIHRoYXQgdXNlcyBTUlRQLCB3aGlj aA0KbWFrZXMgaW50ZXJvcGVyYWJpbGl0eSBtdWNoIGVhc2llci48bzpwPjwvbzpwPjwvcD4NCg0K PC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5JIHRoaW5rIGEgc2lt aWxhciBzdGF0ZW1lbnQgY2FuIGJlIG1hZGUgcmVnYXJkaW5nIHRoZQ0Kc2VsZWN0aW9uIG9mIE1U SSB2aWRlbyBjb2RlY3MuIFRoZXJlIGFyZSB2YXJpb3VzIHJlYXNvbnMgd2h5IG9uZSBtaWdodCBj aG9vc2UNCm9uZSBjb2RlYyB2ZXJzdXMgYW5vdGhlci4gQnV0IGlmIHdlIGFyZSB1bmFibGUgdG8g cGljayBhdCBsZWFzdCBvbmUgZGVmYXVsdC9NVEkNCmNvZGVjIChmb3IgZWFjaCBtZWRpYSB0eXBl KSwgaW50ZXJvcGVyYWJpbGl0eSBhbmQgdGhlcmVieSBhZG9wdGlvbiBvZiB0aGlzDQpwbGF0Zm9y bSB3aWxsIGJlIG11Y2ggbW9yZSBjaGFsbGVuZ2luZy48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+ DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0K PC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4tLWp1c3RpbjxvOnA+PC9vOnA+ PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+T24gVHVlLCBEZWMgMjEs IDIwMTAgYXQgMTE6NDQgUE0sIEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0OzxhDQpocmVmPSJtYWls dG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20iPmluZ2VtYXIucy5qb2hhbnNzb25A ZXJpY3Nzb24uY29tPC9hPiZndDsNCndyb3RlOjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+SGk8YnI+DQo8YnI+DQpOb3QgbWVhbmluZyB0byBleHByZXNzIGFueSBwcmVmZXJl bmNlIGluIGFueSBkaXJlY3Rpb24gYnV0IG1vcmUgYSBxdWVzdGlvbiB0bw0KdGhlIG1vcmUgZXhw ZXJpZW5lZCBJRVRGZXJzLjxicj4NCjxicj4NCk15IGltcHJlc3Npb24gaGVyZSBpcyB0aGF0IGFs Z29yaXRobXMgZGV2aXNlZCBvdXRzaWRlIHRoZSBJRVRGIGFyZSByYXJlbHkNCm1hbmRhdGVkIGlu IElFVEYgZnJhbWV3b3Jrcy48YnI+DQo8YnI+DQpUd28gZXhhbXBsZXMgdGhhdCBJIGNhbiBjb21l IHVwIHdpdGggYXJlPGJyPg0KPGJyPg0KU1JUUCAoUkZDMzcxMSk6IE9ubHkgc3BlY2lmaWVzIHRo ZSBmcmFtZXdvcmsgZm9yIHNlY3VyZSBSVFAgYnV0IGRvZXMgbm90DQptYW5kYXRlIGFueSBlbmNy eXB0aW9uL2F1dGhlbnRpY2F0aW9uIGFsZ29yaXRobXMuIE5vdCBzdXJlIGlmIGV4Y3J5cHRpb24g YWxnb3MNCmFyZSBzcGVjaWZpZWQgaW4gc2VwYXJhdGUgUkZDJ3M8YnI+DQo8YnI+DQpGRUNGUkFN RSAoUkZDNjAxNSk6IFNwZWNpZmllcyB0aGUgZnJhbWV3b3JrIGZvciBnZW5lcmljIEZFQywgZ2Vu ZXJpYyBlbm91Z2ggdG8NCnBsdWcgaW4gYW55IEZFQyBhbGdvLCB0aGUgYWN0dWFsIEZFQyBhbGdv cyBhcmUgc3BlY2lmaWVkIGluIHNlcGFyYXRlIGRyYWZzICg8YQ0KaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL3dnL2ZlY2ZyYW1lLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRm Lm9yZy93Zy9mZWNmcmFtZS88L2E+KTxicj4NClBlcmhhcHMgdGhlcmUgYXJlIHNpbWlsYXIgZXhh bXBsZXMgaW4gb3RoZXIgSUVURiBhcmVhcyB0aGF0IGNhbiBzZXJ2ZSBhcw0KZ3VpZGFuY2UgPywg eW91IG1heSB3YW50IHRvIHBpbmcgdGhlIGVyaUlldGYgbGlzdCBvbiB0aGlzIChJIGxlYXZlIGl0 IHVwIHRvDQp5b3UpPGJyPg0KPGJyPg0KU28gdG8gbWUgaXQgc2VlbXMgbGlrZSB0aGVyZSBpcyBw cmVmZXJlbmNlIHRvIF9ub3RfIG1hbmRhdGUgYWxnb3JpdGhtcw0KKGNvbXByZXNzaW9uLCBmZWMs IGVuY3J5cHRpb24pIGluIElFVEYgZnJhbWV3b3JrcyAoSSBjYW4gaW1hZ2luZSBvbmUgc3BlY2lm aWMNCnJlYXNvbiB0byB0aGlzKS4gQW5kLi4uIGFzIEkgYmVsaWV2ZSB0aGF0IFJUQy1XZWIgd2ls bCBiZSBzb21lIGtpbmQgb2YNCmZyYW1ld29yayBJIHdvdWxkIHNheSB0aGF0IHRoaXMgd291bGQg YXBwbHkgaGVyZSBhcyB3ZWxsID8uPGJyPg0KPGJyPg0KUGxlYXNlIGZlZWwgZnJlZSB0byBiYXNo IG15IGNvbmNsdXNpb24uPGJyPg0KPGJyPg0KL0luZ2VtYXI8YnI+DQo8YnI+DQo8YnI+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KTWVzc2FnZTogMTxv OnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+RGF0ZTogVHVlLCAy MSBEZWMgMjAxMCAyMTozODo0MiArMDAwMDxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPkZyb206ICZsdDs8YSBocmVmPSJtYWlsdG86TWFya3Vz Lklzb21ha2lAbm9raWEuY29tIj5NYXJrdXMuSXNvbWFraUBub2tpYS5jb208L2E+Jmd0OzxvOnA+ PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPlN1Ympl Y3Q6IFJlOiBbZGlzcGF0Y2hdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uICZuYnNwOw0K Zm9yPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtYWx2ZXN0cmFuZC1kaXNw YXRjaC1ydGN3ZWItcHJvdG9jb2xzLTAwPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+VG86ICZsdDs8YSBocmVmPSJtYWlsdG86cGV0ZXIubXVz Z3JhdmVAbWFnb3Jjb3JwLmNvbSI+cGV0ZXIubXVzZ3JhdmVAbWFnb3Jjb3JwLmNvbTwvYT4mZ3Q7 LA0KJmx0OzxhIGhyZWY9Im1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubyI+aGFyYWxkQGFsdmVz dHJhbmQubm88L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPkNjOiA8YSBocmVmPSJtYWlsdG86cnRjLXdlYkBhbHZlc3RyYW5kLm5vIj5ydGMtd2Vi QGFsdmVzdHJhbmQubm88L2E+LA0KPGEgaHJlZj0ibWFpbHRvOmRpc3BhdGNoQGlldGYub3JnIj5k aXNwYXRjaEBpZXRmLm9yZzwvYT4sIDxhDQpocmVmPSJtYWlsdG86dGVkLmlldGZAZ21haWwuY29t Ij50ZWQuaWV0ZkBnbWFpbC5jb208L2E+PGJyPg0KTWVzc2FnZS1JRDo8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGENCmhyZWY9Im1haWx0bzpERDhCMTBCODY1MDJBQjQ4OENC MkQzREI0QzU0NkUzODA2REE5OUAwMDgtQU0xTVBOMS0wMDMubWdkbm9rLm5va2lhLmNvbSI+REQ4 QjEwQjg2NTAyQUI0ODhDQjJEM0RCNEM1NDZFMzgwNkRBOTlAMDA4LUFNMU1QTjEtMDAzLm1nZG5v ay5ub2tpYS5jb208L2E+Jmd0Ozxicj4NCjxicj4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsg Y2hhcnNldD0mcXVvdDt1cy1hc2NpaSZxdW90OzxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8 ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48 YnI+DQpIaSBQZXRlciwgYWxsLDxicj4NCjxicj4NCkFib3V0IHRoZSB2aWRlbyBjb2RlYzogQXJl IHRoZXJlIGFueSBhcmd1bWVudHMgb24gd2h5IFZQOCB3b3VsZCBub3QgaGF2ZSBJUFINCmlzc3Vl cz8gSXQgaXMgYXZhaWxhYmxlIGFzIGFuIG9wZW4gc291cmNlIGltcGxlbWVudGF0aW9uLCBidXQg dGhhdCBkb2VzIG5vdA0KbWVhbiB0aGVyZSBhcmUgbm8gSVBSIGFnYWluc3QgaXQuIE15IHVuZGVy c3RhbmRpbmcgaXMgdGhhdCB0aGUgSVBSIHNpdHVhdGlvbg0Kd3J0LiBWUDggaXMgc3RpbGwgdW5j bGVhciBhbmQgdGh1cyByaXNreS4gVGhlIG90aGVyIGlzc3VlIHdpdGggVlA4IGlzLCBhcyBmYXIN CmFzIEkga25vdywgdGhlIGxhY2sgb2YgYSBjbGVhciBzcGVjIG91dCBvZiB3aGljaCBpbmRlcGVu ZGVudCBpbnRlcm9wZXJhYmxlDQppbXBsZW1lbnRhdGlvbnMgY2FuIGJlIGNyZWF0ZWQuPGJyPg0K PGJyPg0KU28gSSBkb24ndCBhdCBsZWFzdCBidXkgdGhlIGFyZ3VtZW50IHRoYXQgd2Ugc2hvdWxk IGNob29zZSBWUDggYXMgbWFuZGF0b3J5IHRvDQppbXBsZW1lbnQgdmlkZW8gY29kZWMgYmVjYXVz ZSBvZiBJUFIgcmVhc29ucy48YnI+DQo8YnI+DQpJJ20gd29ya2luZyBvbiBhIHNlcGFyYXRlIHJl dmlldyBvbiBIYXJhbGQncyBkcmFmdHMgKHRoYW5rcyBmb3IgcHV0dGluZyB0aGVtDQp0b2dldGhl cikgYW5kIHdpbGwgY29tZSBiYWNrIHRvIHRoZSBjb2RlYyBpc3N1ZSB0aGVyZSBpbiBtb3JlIGRl dGFpbCwgYnV0IGp1c3QNCndhbnRlZCB0byByZXNwb25kIHRvIFBldGVyJ3MgcG9pbnQgaGVyZS48 YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtNYXJrdXM8YnI+DQo8YnI+DQpGcm9tOiA8YSBocmVmPSJt YWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZyI+ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9y ZzwvYT4NClttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmci PmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KT24gQmVoYWxmIE9mIGV4dCBQZXRlciBN dXNncmF2ZTxicj4NClNlbnQ6IDE3IERlY2VtYmVyLCAyMDEwIDEzOjQ4PGJyPg0KVG86IEhhcmFs ZCBBbHZlc3RyYW5kPGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpydGMtd2ViQGFsdmVzdHJhbmQu bm8iPnJ0Yy13ZWJAYWx2ZXN0cmFuZC5ubzwvYT47IDxhDQpocmVmPSJtYWlsdG86ZGlzcGF0Y2hA aWV0Zi5vcmciPmRpc3BhdGNoQGlldGYub3JnPC9hPjsgVGVkIEhhcmRpZTxicj4NClN1YmplY3Q6 IFJlOiBbZGlzcGF0Y2hdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KZHJhZnQt YWx2ZXN0cmFuZC1kaXNwYXRjaC1ydGN3ZWItcHJvdG9jb2xzLTAwPGJyPg0KPGJyPg0KSSdkIGFs c28gbGlrZSB0byBlY2hvIEFsYW4ncyB0aGFua3MgZm9yIHRoZXNlIGRyYWZ0cy48YnI+DQo8YnI+ DQpUaGUgcHJvdG9jb2wgZG9jIGlzIHZlcnkgY2xlYXIuIFtJZiB5b3UgcmVhZCBvbmx5IG9uZSBk aXNwYXRjaCBkcmFmdCB0aGlzDQpDaHJpc3RtYXMsIG1ha2UgaXQgdGhpcyBvbmUuIDstKSAmbmJz cDtdPGJyPg0KPGJyPg0KT25lIG9ic2VydmF0aW9uIHRvIHRoZSBncm91cC4gVGhlIG1hbmRhdG9y eSB0byBpbXBsZW1lbnQgdmlkZW8gQ09ERUMgaXMgVlA4DQoocHJlc3VtYWJseSBzaW5jZSBpdCBk b2VzIG5vdCBoYXZlIElQUiBpc3N1ZXMgLSB3aGljaCBzb21lIG90aGVyIGNob2ljZXMgd291bGQN CmhhdmUpLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KUGV0ZXIgTXVzZ3JhdmU8YnI+ DQo8YnI+DQo8YnI+DQpOaXRzPGJyPg0KSW50cm9kdWN0aW9uPGJyPg0Kcy92ZWljaGxlL3ZlaGlj bGUvPGJyPg0KPGJyPg0KU2VjdGlvbiAyIFBhcmEgJnF1b3Q7V2l0aGluIGVhY2guLiZxdW90Ozxi cj4NCnMvaW1wbGVtZW50YWl0b24vaW1wbGVtZW50YXRpb24vPGJyPg0KPGJyPg0KU2VjdGlvbiA0 IFBhcmExPGJyPg0KJnF1b3Q7c3VjaCBhcyZxdW90OyAoc29tZXRoaW5nIG1pc3NpbmcgaGVyZT8p PGJyPg0KPGJyPg0KU2VjdGlvbiA1IFBhcmEyPGJyPg0KJnF1b3Q7VGhlcmUgaXMgbm8gdGhpcmQg bWFuZGF0b3J5IHRvIGltcGxlbWVudCZxdW90Ozxicj4NCj8gV2FzIHRoZXJlIGEgbWVudGlvbiBv ZiBhIHRoaXJkIGJlZm9yZS4gTm90IHN1cmUgd2h5IHRoaXMgc3RhdGVtZW50IGlzIHRoZXJlLjxi cj4NCjxicj4NCjxicj4NCk9uIDIwMTAtMTEtMTAsIGF0IDY6MzQgQU0sIEhhcmFsZCBBbHZlc3Ry YW5kIHdyb3RlOjxicj4NCjxicj4NCjxicj4NClRoaXMgaXMgdGhlIG92ZXJ2aWV3IGRvY3VtZW50 IGZvciB0aGUgSUVURi1yZWxhdGVkIFJUQy1XRUIgd29yay48YnI+DQo8YnI+DQotLS0tLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tPGJyPg0KU3ViamVjdDo8YnI+DQo8YnI+DQpOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWFsdmVzdHJhbmQtZGlzcGF0Y2gtcnRjd2ViLXBy b3RvY29scy0wMDxicj4NCjxicj4NCkRhdGU6PGJyPg0KPGJyPg0KV2VkLCAxMCBOb3YgMjAxMCAw MzozMTowNSAtMDgwMCAoUFNUKTxicj4NCjxicj4NCkZyb206PG86cD48L286cD48L3A+DQoNCjwv ZGl2Pg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPklFVEYgSS1EIFN1Ym1pc3Npb24g VG9vbCAmbHQ7PGENCmhyZWY9Im1haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmciPmlkc3VibWlz c2lvbkBpZXRmLm9yZzwvYT4mZ3Q7Jmx0O21haWx0bzo8YQ0KaHJlZj0ibWFpbHRvOmlkc3VibWlz c2lvbkBpZXRmLm9yZyI+aWRzdWJtaXNzaW9uQGlldGYub3JnPC9hPiZndDs8YnI+DQo8YnI+DQpU bzo8YnI+DQo8YnI+DQo8YSBocmVmPSJtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm8iPmhhcmFs ZEBhbHZlc3RyYW5kLm5vPC9hPiZsdDttYWlsdG86PGENCmhyZWY9Im1haWx0bzpoYXJhbGRAYWx2 ZXN0cmFuZC5ubyI+aGFyYWxkQGFsdmVzdHJhbmQubm88L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0K DQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPg0KPGJyPg0KPGJyPg0KQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWFsdmVzdHJhbmQtZGlzcGF0Y2gtcnRjd2ViLXByb3RvY29scy0w MC50eHQgaGFzDQpiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSGFyYWxkIEFsdmVzdHJh bmQgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0KcmVwb3NpdG9yeS48YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQpGaWxlbmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1hbHZlc3RyYW5kLWRpc3Bh dGNoLXJ0Y3dlYi1wcm90b2NvbHM8YnI+DQo8YnI+DQpSZXZpc2lvbjogJm5ic3A7ICZuYnNwOyAm bmJzcDswMDxicj4NCjxicj4NClRpdGxlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgT3Zl cnZpZXc6IFJlYWwgVGltZSBQcm90b2NvbHMgZm9yDQpCcm93ZXItYmFzZWQgQXBwbGljYXRpb25z PGJyPg0KPGJyPg0KQ3JlYXRpb25fZGF0ZTogJm5ic3A7MjAxMC0xMS0xMTxicj4NCjxicj4NCldH IElEOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kZXBlbmRlbnQgU3VibWlzc2lvbjxi cj4NCjxicj4NCk51bWJlcl9vZl9wYWdlczogOTxicj4NCjxicj4NCjxicj4NCjxicj4NCkFic3Ry YWN0Ojxicj4NCjxicj4NClRoaXMgZG9jdW1lbnQgZ2l2ZXMgYW4gb3ZlcnZpZXcgb2YgYSBwcm90 b2NvbCBzdWl0ZSBpbnRlbmRlZCBmb3IgdXNlPGJyPg0KPGJyPg0Kd2l0aCByZWFsLXRpbWUgYXBw bGljYXRpb25zIHRoYXQgY2FuIGJlIGRlcGxveWVkIGluIGJyb3dzZXJzIC0gJnF1b3Q7cmVhbDxi cj4NCjxicj4NCnRpbWUgY29tbXVuaWNhdGlvbiBvbiB0aGUgV2ViJnF1b3Q7Ljxicj4NCjxicj4N Cjxicj4NCjxicj4NCkl0IGludGVuZHMgdG8gc2VydmUgYXMgYSBzdGFydGluZyBhbmQgY29vcmRp bmF0aW9uIHBvaW50IHRvIG1ha2Ugc3VyZTxicj4NCjxicj4NCmFsbCB0aGUgcGFydHMgdGhhdCBh cmUgbmVlZGVkIHRvIGFjaGlldmUgdGhpcyBnb2FsIGFyZSBmaW5kYWJsZSwgYW5kPGJyPg0KPGJy Pg0KdGhhdCB0aGUgcGFydHMgdGhhdCBiZWxvbmcgaW4gdGhlIEludGVybmV0IHByb3RvY29sIHN1 aXRlIGFyZSBmdWxseTxicj4NCjxicj4NCnNwZWNpZmllZCBhbmQgb24gdGhlIHJpZ2h0IHB1Ymxp Y2F0aW9uIHRyYWNrLjxicj4NCjxicj4NCjxicj4NCjxicj4NClRoaXMgd29yayBpcyBhbiBhdHRl bXB0IHRvIHN5bnRoZXNpemUgdGhlIGlucHV0IG9mIG1hbnkgcGVvcGxlLCBidXQ8YnI+DQo8YnI+ DQptYWtlcyBubyBjbGFpbXMgdG8gZnVsbHkgcmVwcmVzZW50IHRoZSB2aWV3cyBvZiBhbnkgb2Yg dGhlbS4gJm5ic3A7QWxsPGJyPg0KPGJyPg0KcGFydHMgb2YgdGhlIGRvY3VtZW50IHNob3VsZCBi ZSByZWdhcmRlZCBhcyBvcGVuIGZvciBkaXNjdXNzaW9uLjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0Ljxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KZGlzcGF0Y2ggbWFpbGluZyBsaXN0PG86cD48L286 cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGEgaHJlZj0ibWFpbHRvOmRp c3BhdGNoQGlldGYub3JnIj5kaXNwYXRjaEBpZXRmLm9yZzwvYT4mbHQ7bWFpbHRvOjxhDQpocmVm PSJtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmciPmRpc3BhdGNoQGlldGYub3JnPC9hPiZndDs8bzpw PjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t Ym90dG9tOjEyLjBwdCc+PGENCmhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGlzcGF0Y2giIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Rpc3BhdGNoPC9hPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPi0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAtLS0tLS0tLS0tLS0tLTxi cj4NCkFuIEhUTUwgYXR0YWNobWVudCB3YXMgc2NydWJiZWQuLi48YnI+DQpVUkw6ICZsdDs8YQ0K aHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2Rpc3BhdGNoL2F0dGFj aG1lbnRzLzIwMTAxMjIxLzQ2ZWM0MzE3L2F0dGFjaG1lbnQuaHRtIg0KdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kaXNwYXRjaC9hdHRhY2htZW50 cy8yMDEwMTIyMS80NmVjNDMxNy9hdHRhY2htZW50Lmh0bTwvYT4mZ3Q7PGJyPg0KPGJyPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQoNCjxkaXY+DQoNCjxk aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NClJUQy1XZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOlJUQy1XZWJAYWx2ZXN0cmFuZC5ubyI+UlRDLVdlYkBhbHZlc3RyYW5kLm5vPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5uby9tYWlsbWFuL2xpc3RpbmZvL3J0 Yy13ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmFsdmVzdHJhbmQubm8vbWFpbG1hbi9s aXN0aW5mby9ydGMtd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoN CjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwv ZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K --_000_DD8B10B86502AB488CB2D3DB4C546E38082C70008AM1MPN1003mgdn_-- From harald@alvestrand.no Wed Dec 22 14:43:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24C43A6B96 for ; Wed, 22 Dec 2010 14:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ht+K30rhigm for ; Wed, 22 Dec 2010 14:43:06 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id C74903A68D6 for ; Wed, 22 Dec 2010 14:43:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7FB7A39E11A; Wed, 22 Dec 2010 23:44:42 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV0sOFddzqrs; Wed, 22 Dec 2010 23:44:40 +0100 (CET) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 3B68E39E089; Wed, 22 Dec 2010 23:44:40 +0100 (CET) Message-ID: <4D127F6E.9060305@alvestrand.no> Date: Wed, 22 Dec 2010 23:45:02 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <4CDA833D.8080203@alvestrand.no>, , <4D1215CD.6090904@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040207090303010602000000" Cc: bernard_aboba@hotmail.com, rtc-web@alvestrand.no, dispatch@ietf.org, ted.ietf@gmail.com Subject: Re: [dispatch] Codec standardization (Re: [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 22:43:11 -0000 This is a multi-part message in MIME format. --------------040207090303010602000000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/22/10 22:12, Markus.Isomaki@nokia.com wrote: > > Hi Harald, > > We can reference things as long as they are public and stable. But I > also think that if we were to mandate some technology as part of an > IETF standard, the future development of that technology should > preferably be done under an open process. How does the future > development of VP8 (or VP9) will happen from that point of view? I've > seen some concerns about this so it would be good to get the facts. > VP8 (the bitstream format) is not going to change in any incompatible way. Too much software and hardware is already dependent on the current definition. It seems reasonable to do the development of a successor specification in a standards body, but that's probably going to take a few years. > > As long as VP8 spec itself is not published as an Internet-draft, I > don't suppose the IETF IPR rules apply to it. So I'm not sure which > process we are following with it right now. That would be good to clarify. > I'm hoping to make that clearer within a few weeks - sorry that I can't say more yet. > > Regards, > > Markus > > *From:*ext Harald Alvestrand [mailto:harald@alvestrand.no] > *Sent:* 22 December, 2010 17:14 > *To:* Bernard Aboba > *Cc:* Isomaki Markus (Nokia-CIC/Espoo); peter.musgrave@magorcorp.com; > rtc-web@alvestrand.no; dispatch@ietf.org; ted.ietf@gmail.com > *Subject:* Codec standardization (Re: [RTW] [dispatch] Fwd: New > Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) > > On 12/22/10 07:18, Bernard Aboba wrote: > > It does appear presumptive to suggest that a codec that hasn't > completed a standardization process be made "mandatory to implement." > > Since there have been some large judgments over use of allegedly > "free" codecs, the lesson is that codecs that are claimed to be "free > of encumbrance" may in time be discovered not to be. The IETF process > can potentially be useful in helping to clarify the IPR status of > codecs. However, those wheels grind slowly. > > I agree that we can't make anything mandatory to implement that we > don't have an accepted stable, publicly available reference for. (I'm > working on solving that for the case of VP8). > > However, I don't agree that we necessarily have to complete a > standards process in order to refer to it; that would put, for > instance, the Zip format (used, among other places, in OOXML and ODF) > out of scope for standards. > > WRT IPR issues: I think we just have to push forward on the assumption > that all IPR holders who are part of the process will do their duty > and disclose any relevant IPR, and hope that IPR held by > nonparticipants in the process is not serious enough to cause us to > regret our decision. > > Note: The statement about VP8 in the rtcweb-protocols document is a > placeholder, put in there to indicate that we need to have the > discussion. It's not a WG decision, but input to a WG discussion. > > Harald > > --------------040207090303010602000000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 12/22/10 22:12, Markus.Isomaki@nokia.com wrote:

Hi Harald,

 

We can reference things as long as they are public and stable. But I also think that if we were to mandate some technology as part of an IETF standard, the future development of that technology should preferably be done under an open process. How does the future development of VP8 (or VP9) will happen from that point of view? I’ve seen some concerns about this so it would be good to get the facts.

VP8 (the bitstream format) is not going to change in any incompatible way. Too much software and hardware is already dependent on the current definition.
It seems reasonable to do the development of a successor specification in a standards body, but that's probably going to take a few years.

 

As long as VP8 spec itself is not published as an Internet-draft, I don’t suppose the IETF IPR rules apply to it. So I’m not sure which process we are following with it right now. That would be good to clarify.

I'm hoping to make that clearer within a few weeks - sorry that I can't say more yet.

 

Regards,

                Markus

 

 

From: ext Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: 22 December, 2010 17:14
To: Bernard Aboba
Cc: Isomaki Markus (Nokia-CIC/Espoo); peter.musgrave@magorcorp.com; rtc-web@alvestrand.no; dispatch@ietf.org; ted.ietf@gmail.com
Subject: Codec standardization (Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)

 

On 12/22/10 07:18, Bernard Aboba wrote:

It does appear presumptive to suggest that a codec that hasn't completed a standardization process be made "mandatory to implement."

Since there have been some large judgments over use of allegedly "free" codecs, the lesson is that codecs that are claimed to be "free of encumbrance" may in time be discovered not to be.  The IETF process can potentially be useful in helping to clarify the IPR status of codecs.  However, those wheels grind slowly.

I agree that we can't make anything mandatory to implement that we don't have an accepted stable, publicly available reference for. (I'm working on solving that for the case of VP8).

However, I don't agree that we necessarily have to complete a standards process in order to refer to it; that would put, for instance, the Zip format (used, among other places, in OOXML and ODF) out of scope for standards.

WRT IPR issues: I think we just have to push forward on the assumption that all IPR holders who are part of the process will do their duty and disclose any relevant IPR, and hope that IPR held by nonparticipants in the process is not serious enough to cause us to regret our decision.

Note: The statement about VP8 in the rtcweb-protocols document is a placeholder, put in there to indicate that we need to have the discussion. It's not a WG decision, but input to a WG discussion.

                      Harald



--------------040207090303010602000000-- From singer@apple.com Wed Dec 22 14:44:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 459E43A6B72 for ; Wed, 22 Dec 2010 14:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E3E4KIL0Fql for ; Wed, 22 Dec 2010 14:44:46 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 653593A68D6 for ; Wed, 22 Dec 2010 14:44:46 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 971DEC1AFE57; Wed, 22 Dec 2010 14:46:37 -0800 (PST) X-AuditID: 11807134-b7cfdae000001831-82-4d127fcdcf8a Received: from singda.apple.com (singda.apple.com [17.197.20.4]) by relay14.apple.com (Apple SCV relay) with SMTP id 3B.DA.06193.DCF721D4; Wed, 22 Dec 2010 14:46:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David Singer In-Reply-To: <4D1215CD.6090904@alvestrand.no> Date: Wed, 22 Dec 2010 14:46:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2B4B7D62-0643-49CA-9883-014CA849C413@apple.com> References: <4CDA833D.8080203@alvestrand.no> <4D1215CD.6090904@alvestrand.no> To: rtc-web@alvestrand.no X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org Subject: Re: [dispatch] Codec standardization (Re: [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 22:44:47 -0000 I should say that I am perfectly happy to have the discussion about = whether, and what, to mandate codec(s). If the placeholder is there to = spark the discussion, you succeeded! For me, significant IPR risk is worse than a payment -- free but risky = is not an improvement on costs-but-low-risk. But others may differ, of = course. I do think we should be looking carefully at layered design. Ideally, = we define the missing technology bits -- HTML, Javascript/DOM, and so = on; and then, perhaps, we write an umbrella specification that uses = those, and other technology pieces, to achieve an interoperable end. = But the pieces should 'make sense' by themselves, and be usable with = other assemblages, I think, if the specs are to have 'legs' and survive = over years. The pieces are ideally stable standards/publications in = their own right (and I agree, sometimes, rarely, something is stable and = well-known enough, such as ZIP or ID3 tags, without being a 'standard'). I also agree that RF codecs are happening and are here to stay. Those = of you who know me from MPEG will have heard this before. They will = exist, and they will have a place. MPEG is working (slowly) on RF codecs = as well. As to what MPEG-LA is doing, I am afraid I don't actually know. We'd = have to ask them, and they tend not to reply. The silence is strange, = but I don't think that mitigates the possibility that there is an IPR = entanglement. Despite Henry's position (that mentioning VP8 results in no rat-holes = and flames, and that mentioning H.264 will) I think we should consider = the balance between cost, risk, quality, and existing adoption, and it = would be foolish to omit cost-bearing codecs from that analysis, as = H.264 is widely used already. The link between open-source and royalty-free is not perfect; there are = quality open-source implementations of non-free codecs, for a start, and = there are companies who license proprietary systems royalty-free. Let's = not confuse the two, even if they often occur together. David Singer Multimedia and Software Standards, Apple Inc. From ingemar.s.johansson@ericsson.com Thu Dec 23 01:42:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977303A6AF1 for ; Thu, 23 Dec 2010 01:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRGa5VWINA3H for ; Thu, 23 Dec 2010 01:42:18 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 866C73A6AE4 for ; Thu, 23 Dec 2010 01:42:17 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-6a-4d1319f03e7b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 15.9C.23694.0F9131D4; Thu, 23 Dec 2010 10:44:16 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.218]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 23 Dec 2010 10:44:15 +0100 From: Ingemar Johansson S To: Justin Uberti Date: Thu, 23 Dec 2010 10:44:14 +0100 Thread-Topic: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Thread-Index: Acuh83o5OH+nd7mVS3mX4Lt7xBRd7AAji3Ig Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: multipart/alternative; boundary="_000_DBB1DC060375D147AC43F310AD987DCC22B1CF239DESESSCMS0366e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtc-web@alvestrand.no" , "dispatch@ietf.org" , "Markus.Isomaki@nokia.com" Subject: Re: [dispatch] [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 09:42:20 -0000 --_000_DBB1DC060375D147AC43F310AD987DCC22B1CF239DESESSCMS0366e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Justin In some sense you are very right but I make a slightly different interpreta= tion. Quoting section 4 in RFC3711 "While there are numerous encryption and message authentication algorithms = that can be used in SRTP, below we define default algorithms in order to av= oid the complexity of specifying the encodings for the signaling of algorit= hm and parameter identifiers. The defined algorithms have been chosen as th= ey fulfill the goals listed in Section 2. Recommendations on how to extend = SRTP with new transforms are given in Section 6." I don't interpret this as mandatory to implement said algorithms, rather I = see this as something needed to make the RFC complete. The encryption can b= e negotiated out of band so an implementer can avoid said algorithms comple= tely if he/she wants to. Now I don't say that this is _the_ interpretation, please correct me if nee= cessary. I don't intend to enter a heated debate about which codecs should be used. My concern is more that it is not good to end up in a situation where a man= datory codec is specified in an IETF RFC and later on gets subject to some = legal issues. What is the situation for the RFC then?, should the codec be = demoted to optional in a new RFC that deprecates the old ? I don't have the answers, hope that some of the "grey-beards" can chime in = and give some guidance later on. Regards and happy holidays /Ingemar ________________________________ From: Justin Uberti [mailto:juberti@google.com] Sent: den 22 december 2010 17:15 To: Ingemar Johansson S Cc: dispatch@ietf.org; rtc-web@alvestrand.no; Markus.Isomaki@nokia.com Subject: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alves= trand-dispatch-rtcweb-protocols-00 Ingemar, RFC 3711 defines AES as the default encryption algorithm and HMAC-SHA1 as t= he default authentication algorithm for SRTP. As a result, those algorithms= are used by pretty much every application that uses SRTP, which makes inte= roperability much easier. I think a similar statement can be made regarding the selection of MTI vide= o codecs. There are various reasons why one might choose one codec versus a= nother. But if we are unable to pick at least one default/MTI codec (for ea= ch media type), interoperability and thereby adoption of this platform will= be much more challenging. --justin On Tue, Dec 21, 2010 at 11:44 PM, Ingemar Johansson S > wrote: Hi Not meaning to express any preference in any direction but more a question = to the more experiened IETFers. My impression here is that algorithms devised outside the IETF are rarely m= andated in IETF frameworks. Two examples that I can come up with are SRTP (RFC3711): Only specifies the framework for secure RTP but does not ma= ndate any encryption/authentication algorithms. Not sure if excryption algo= s are specified in separate RFC's FECFRAME (RFC6015): Specifies the framework for generic FEC, generic enough= to plug in any FEC algo, the actual FEC algos are specified in separate dr= afs (http://tools.ietf.org/wg/fecframe/) Perhaps there are similar examples in other IETF areas that can serve as gu= idance ?, you may want to ping the eriIetf list on this (I leave it up to y= ou) So to me it seems like there is preference to _not_ mandate algorithms (com= pression, fec, encryption) in IETF frameworks (I can imagine one specific r= eason to this). And... as I believe that RTC-Web will be some kind of frame= work I would say that this would apply here as well ?. Please feel free to bash my conclusion. /Ingemar ------------------------------------------- Message: 1 Date: Tue, 21 Dec 2010 21:38:42 +0000 From: > Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 To: >, > Cc: rtc-web@alvestrand.no, dispatch@ietf.org<= mailto:dispatch@ietf.org>, ted.ietf@gmail.com Message-ID: > Content-Type: text/plain; charset=3D"us-ascii" Hi Peter, all, About the video codec: Are there any arguments on why VP8 would not have IP= R issues? It is available as an open source implementation, but that does n= ot mean there are no IPR against it. My understanding is that the IPR situa= tion wrt. VP8 is still unclear and thus risky. The other issue with VP8 is,= as far as I know, the lack of a clear spec out of which independent intero= perable implementations can be created. So I don't at least buy the argument that we should choose VP8 as mandatory= to implement video codec because of IPR reasons. I'm working on a separate review on Harald's drafts (thanks for putting the= m together) and will come back to the codec issue there in more detail, but= just wanted to respond to Peter's point here. Regards, Markus From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of ex= t Peter Musgrave Sent: 17 December, 2010 13:48 To: Harald Alvestrand Cc: rtc-web@alvestrand.no; dispatch@ietf.org<= mailto:dispatch@ietf.org>; Ted Hardie Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-= dispatch-rtcweb-protocols-00 I'd also like to echo Alan's thanks for these drafts. The protocol doc is very clear. [If you read only one dispatch draft this C= hristmas, make it this one. ;-) ] One observation to the group. The mandatory to implement video CODEC is VP8= (presumably since it does not have IPR issues - which some other choices w= ould have). Regards, Peter Musgrave Nits Introduction s/veichle/vehicle/ Section 2 Para "Within each.." s/implementaiton/implementation/ Section 4 Para1 "such as" (something missing here?) Section 5 Para2 "There is no third mandatory to implement" ? Was there a mention of a third before. Not sure why this statement is the= re. On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: This is the overview document for the IETF-related RTC-WEB work. -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Date: Wed, 10 Nov 2010 03:31:05 -0800 (PST) From: IETF I-D Submission Tool >> To: harald@alvestrand.no> A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has= been successfully submitted by Harald Alvestrand and posted to the IETF re= pository. Filename: draft-alvestrand-dispatch-rtcweb-protocols Revision: 00 Title: Overview: Real Time Protocols for Brower-based Applications Creation_date: 2010-11-11 WG ID: Independent Submission Number_of_pages: 9 Abstract: This document gives an overview of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion. The IETF Secretariat. _______________________________________________ dispatch mailing list dispatch@ietf.org> https://www.ietf.org/mailman/listinfo/dispatch -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web --_000_DBB1DC060375D147AC43F310AD987DCC22B1CF239DESESSCMS0366e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Justin
 
In some sense you are very right but I make a slig= htly=20 different interpretation.
 
Quoting section 4 in RFC3711
"While there= are numerous=20 encryption and message authentication algorithms that can be used in SRTP, = below=20 we define default algorithms in order to avoid the complexity of specifying= the=20 encodings for the signaling of algorithm and parameter identifiers. The def= ined=20 algorithms have been chosen as they fulfill the goals listed in Section 2.= =20 Recommendations on how to extend SRTP with new transforms are given in Sect= ion=20 6."
I don't interpret this as mandatory to implement s= aid=20 algorithms, rather I see this as something needed to make the RFC complete.= The=20 encryption can be negotiated out of band so an implementer can avoid said=20 algorithms completely if he/she wants to.
Now I don't say that this is _the_ interpretation,= please=20 correct me if neecessary.
 
I don't intend to enter a heated debate about whic= h codecs=20 should be used.
My concern is more that it is not good to end up i= n a=20 situation where a mandatory codec is specified in an IETF RFC and= =20 later on gets subject to some legal issues. What is the situation for the R= FC=20 then?, should the codec be demoted to optional in a new RFC that deprecates= the=20 old ?
I don't have the answers, hope that some of the=20 "grey-beards" can chime in and give some guidance later on.
 
Regards and happy holidays
/Ingemar
 
 
 
 

From: Justin Uberti [mailto:juberti@goo= gle.com]=20
Sent: den 22 december 2010 17:15
To: Ingemar Johansson= =20 S
Cc: dispatch@ietf.org; rtc-web@alvestrand.no;=20 Markus.Isomaki@nokia.com
Subject: Re: [RTW] [dispatch] Fwd: New=20 Version Notification for=20 draft-alvestrand-dispatch-rtcweb-protocols-00

Ingemar,

RFC 3711 defines AES as the default encryption algorithm and HMAC-SHA1= as=20 the default authentication algorithm for SRTP. As a result, those algorithm= s are=20 used by pretty much every application that uses SRTP, which makes=20 interoperability much easier.

I think a similar statement can be made regarding the selection of MTI= =20 video codecs. There are various reasons why one might choose one codec vers= us=20 another. But if we are unable to pick at least one default/MTI codec (for e= ach=20 media type), interoperability and thereby adoption of this platform will be= much=20 more challenging.

--justin

On Tue, Dec 21, 2010 at 11:44 PM, Ingemar Johansso= n S=20 <ingemar.s.johansson@ericss= on.com>=20 wrote:
Hi

Not=20 meaning to express any preference in any direction but more a question to= the=20 more experiened IETFers.

My impression here is that algorithms dev= ised=20 outside the IETF are rarely mandated in IETF frameworks.

Two examp= les=20 that I can come up with are

SRTP (RFC3711): Only specifies the=20 framework for secure RTP but does not mandate any encryption/authenticati= on=20 algorithms. Not sure if excryption algos are specified in separate=20 RFC's

FECFRAME (RFC6015): Specifies the framework for generic FEC,= =20 generic enough to plug in any FEC algo, the actual FEC algos are specifie= d in=20 separate drafs (http://tools.ietf.org/wg/fecframe/)
Perhaps there = are=20 similar examples in other IETF areas that can serve as guidance ?, you ma= y=20 want to ping the eriIetf list on this (I leave it up to you)

So to= me=20 it seems like there is preference to _not_ mandate algorithms (compressio= n,=20 fec, encryption) in IETF frameworks (I can imagine one specific reason to= =20 this). And... as I believe that RTC-Web will be some kind of framework I = would=20 say that this would apply here as well ?.

Please feel free to bash= my=20 conclusion.

/Ingemar


----------------------------------= ---------
Message:=20 1
Date: Tue, 21 Dec 2010 21:38:42 +0000
From: <Markus.Isomaki@nokia.com>=
Subject: Re: [dispatch] Fwd: New Version Notification &nb= sp;=20 for
     =20  draft-alvestrand-dispatch-rtcweb-protocols-00
To: <peter.musgrave@magorcorp.com= >,=20 <harald@alvestrand.no>
Cc:=20 rtc-web@alvestrand.no, dispatch@ietf.org, ted.ietf@gmail.com
Message-ID:<= BR> =20      <DD8B10B86502AB488CB2D3DB4C546E3806DA99@008-AM1MPN1-003.mgdno= k.nokia.com>

Content-Type:=20 text/plain; charset=3D"us-ascii"

Hi Peter, all,

About the video codec: Are ther= e any=20 arguments on why VP8 would not have IPR issues? It is available as an ope= n=20 source implementation, but that does not mean there are no IPR against it= . My=20 understanding is that the IPR situation wrt. VP8 is still unclear and thu= s=20 risky. The other issue with VP8 is, as far as I know, the lack of a clear= spec=20 out of which independent interoperable implementations can be=20 created.

So I don't at least buy the argument that we should choos= e VP8=20 as mandatory to implement video codec because of IPR reasons.

I'm= =20 working on a separate review on Harald's drafts (thanks for putting them= =20 together) and will come back to the codec issue there in more detail, but= just=20 wanted to respond to Peter's point here.

Regards,
   = =20            Markus

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] = On=20 Behalf Of ext Peter Musgrave
Sent: 17 December, 2010 13:48
To: Hara= ld=20 Alvestrand
Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie
Su= bject:=20 Re: [dispatch] Fwd: New Version Notification for=20 draft-alvestrand-dispatch-rtcweb-protocols-00

I'd also like to ech= o=20 Alan's thanks for these drafts.

The protocol doc is very clear. [I= f you=20 read only one dispatch draft this Christmas, make it this one. ;-)=20  ]

One observation to the group. The mandatory to implement v= ideo=20 CODEC is VP8 (presumably since it does not have IPR issues - which some o= ther=20 choices would have).

Regards,

Peter=20 Musgrave


Nits
Introduction
s/veichle/vehicle/

Sec= tion=20 2 Para "Within each.."
s/implementaiton/implementation/

Section= 4=20 Para1
"such as" (something missing here?)

Section 5 Para2
"T= here=20 is no third mandatory to implement"
? Was there a mention of a third=20 before. Not sure why this statement is there.


On 2010-11-10, a= t=20 6:34 AM, Harald Alvestrand wrote:


This is the overview documen= t for=20 the IETF-related RTC-WEB work.

-------- Original Message=20 --------
Subject:

New Version Notification for=20 draft-alvestrand-dispatch-rtcweb-protocols-00

Date:

Wed, 10= Nov=20 2010 03:31:05 -0800 (PST)

From:

IETF I-D Submis= sion=20 Tool <idsubmission@ietf.org><ma= ilto:idsubmission@ietf.org>
To:

harald@alvestrand.no<mailto:<= A=20 href=3D"mailto:harald@alvestrand.no">harald@alvestrand.no>



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



Filename:    =20  draft-alvestrand-dispatch-rtcweb-protocols

Revision:  = =20    00

Title:         Overview: Real = Time=20 Protocols for Brower-based Applications

Creation_date:=20  2010-11-11

WG ID:         Independent=20 Submission

Number_of_pages: 9



Abstract:

This= =20 document gives an overview of a protocol suite intended for use

wi= th=20 real-time applications that can be deployed in browsers - "real

ti= me=20 communication on the Web".



It intends to serve as a starti= ng=20 and coordination point to make sure

all the parts that are needed = to=20 achieve this goal are findable, and

that the parts that belong in = the=20 Internet protocol suite are fully

specified and on the right=20 publication track.



This work is an attempt to synthesize t= he=20 input of many people, but

makes no claims to fully represent the v= iews=20 of any of them.  All

parts of the document should be regarded= as=20 open for discussion.







The IETF=20 Secretariat.






_________________________________= ______________
dispatch=20 mailing list
dispatch@ietf.org<mailto:dispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/dispatch
--------------=20 next part --------------
An HTML attachment was scrubbed...
URL: &l= t;http://www.ietf.org/mail-archive/web/dispatch/attachments= /20101221/46ec4317/attachment.htm>

--------------------------= ----
_______________________________________________
RTC-We= b=20 mailing list
RTC-Web@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtc-web
=

--_000_DBB1DC060375D147AC43F310AD987DCC22B1CF239DESESSCMS0366e_-- From harald@alvestrand.no Sat Dec 25 15:09:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7EB3A6892 for ; Sat, 25 Dec 2010 15:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQXkD5-TeR3W for ; Sat, 25 Dec 2010 15:09:21 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 319013A683C for ; Sat, 25 Dec 2010 15:09:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A5BB039E0FD; Sun, 26 Dec 2010 00:11:01 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TitcXf9+K+Nu; Sun, 26 Dec 2010 00:11:00 +0100 (CET) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id EF29339E082; Sun, 26 Dec 2010 00:10:56 +0100 (CET) Message-ID: <4D167A13.4070207@alvestrand.no> Date: Sun, 26 Dec 2010 00:11:15 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ingemar Johansson S References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090905020206000906070600" Cc: "rtc-web@alvestrand.no" , "dispatch@ietf.org" , "Markus.Isomaki@nokia.com" , Justin Uberti Subject: Re: [dispatch] [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2010 23:09:22 -0000 This is a multi-part message in MIME format. --------------090905020206000906070600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/23/10 10:44, Ingemar Johansson S wrote: > Hi Justin > In some sense you are very right but I make a slightly different > interpretation. > Quoting section 4 in RFC3711 > "While there are numerous encryption and message authentication > algorithms that can be used in SRTP, below we define default > algorithms in order to avoid the complexity of specifying the > encodings for the signaling of algorithm and parameter identifiers. > The defined algorithms have been chosen as they fulfill the goals > listed in Section 2. Recommendations on how to extend SRTP with new > transforms are given in Section 6." > I don't interpret this as mandatory to implement said algorithms, > rather I see this as something needed to make the RFC complete. The > encryption can be negotiated out of band so an implementer can avoid > said algorithms completely if he/she wants to. > Now I don't say that this is _the_ interpretation, please correct me > if neecessary. > I don't intend to enter a heated debate about which codecs should be > used. > My concern is more that it is not good to end up in a situation where > a mandatory codec is specified in an IETF RFC and later on gets > subject to some legal issues. What is the situation for the RFC then?, > should the codec be demoted to optional in a new RFC that deprecates > the old ? > I don't have the answers, hope that some of the "grey-beards" can > chime in and give some guidance later on. > Regards and happy holidays > /Ingemar > > ------------------------------------------------------------------------ > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* den 22 december 2010 17:15 > *To:* Ingemar Johansson S > *Cc:* dispatch@ietf.org; rtc-web@alvestrand.no; Markus.Isomaki@nokia.com > *Subject:* Re: [RTW] [dispatch] Fwd: New Version Notification for > draft-alvestrand-dispatch-rtcweb-protocols-00 > > Ingemar, > > RFC 3711 defines AES as the default encryption algorithm and HMAC-SHA1 > as the default authentication algorithm for SRTP. As a result, those > algorithms are used by pretty much every application that uses SRTP, > which makes interoperability much easier. Ingemar, I think you misinterpret RFC 3711 slightly. More important than the text you quote is the text in section 5 of RFC 3711: 5. Default and mandatory-to-implement Transforms The default transforms also are mandatory-to-implement transforms in SRTP. Of course, "mandatory-to-implement" does not imply "mandatory-to-use". Table 1 summarizes the pre-defined transforms. The default values below are valid for the pre-defined transforms. mandatory-to-impl. optional default encryption AES-CM, NULL AES-f8 AES-CM message integrity HMAC-SHA1 - HMAC-SHA1 key derivation (PRF) AES-CM - AES-CM Table 1: Mandatory-to-implement, optional and default transforms in SRTP and SRTCP. In other words, an SRTP implementation that does not implement AES-CM and HMAC-SHA1 is not a conformant SRTP implementation. > > I think a similar statement can be made regarding the selection of MTI > video codecs. There are various reasons why one might choose one codec > versus another. But if we are unable to pick at least one default/MTI > codec (for each media type), interoperability and thereby adoption of > this platform will be much more challenging. I completely agree with your reasoning here. Note that neither AES nor HMAC are IETF defined algorithms. It is indeed quite common to refer to non-IETF technologies in mandatory-to-implement statements (even if, as in the case of UTF-8, we sometimes choose to reference those specifications by writing an RFC that describes the link). Harald --------------090905020206000906070600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 12/23/10 10:44, Ingemar Johansson S wrote:
Hi Justin
 
In some sense you are very right but I make a slightly different interpretation.
 
Quoting section 4 in RFC3711
"While there are numerous encryption and message authentication algorithms that can be used in SRTP, below we define default algorithms in order to avoid the complexity of specifying the encodings for the signaling of algorithm and parameter identifiers. The defined algorithms have been chosen as they fulfill the goals listed in Section 2. Recommendations on how to extend SRTP with new transforms are given in Section 6."
I don't interpret this as mandatory to implement said algorithms, rather I see this as something needed to make the RFC complete. The encryption can be negotiated out of band so an implementer can avoid said algorithms completely if he/she wants to.
Now I don't say that this is _the_ interpretation, please correct me if neecessary.
 
I don't intend to enter a heated debate about which codecs should be used.
My concern is more that it is not good to end up in a situation where a mandatory codec is specified in an IETF RFC and later on gets subject to some legal issues. What is the situation for the RFC then?, should the codec be demoted to optional in a new RFC that deprecates the old ?
I don't have the answers, hope that some of the "grey-beards" can chime in and give some guidance later on.
 
Regards and happy holidays
/Ingemar
 
 
 
 

From: Justin Uberti [mailto:juberti@google.com]
Sent: den 22 december 2010 17:15
To: Ingemar Johansson S
Cc: dispatch@ietf.org; rtc-web@alvestrand.no; Markus.Isomaki@nokia.com
Subject: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

Ingemar,

RFC 3711 defines AES as the default encryption algorithm and HMAC-SHA1 as the default authentication algorithm for SRTP. As a result, those algorithms are used by pretty much every application that uses SRTP, which makes interoperability much easier.
Ingemar,

I think you misinterpret RFC 3711 slightly.

More important than the text you quote is the text in section 5 of RFC 3711:

5.  Default and mandatory-to-implement Transforms

   The default transforms also are mandatory-to-implement transforms in
   SRTP.  Of course, "mandatory-to-implement" does not imply
   "mandatory-to-use".  Table 1 summarizes the pre-defined transforms.
   The default values below are valid for the pre-defined transforms.

                         mandatory-to-impl.   optional     default

   encryption            AES-CM, NULL         AES-f8       AES-CM
   message integrity     HMAC-SHA1              -          HMAC-SHA1
   key derivation (PRF)  AES-CM                 -          AES-CM

   Table 1: Mandatory-to-implement, optional and default transforms in
   SRTP and SRTCP.

In other words, an SRTP implementation that does not implement AES-CM and HMAC-SHA1 is not
a conformant SRTP implementation.


I think a similar statement can be made regarding the selection of MTI video codecs. There are various reasons why one might choose one codec versus another. But if we are unable to pick at least one default/MTI codec (for each media type), interoperability and thereby adoption of this platform will be much more challenging.
I completely agree with your reasoning here.

Note that neither AES nor HMAC are IETF defined algorithms. It is indeed quite common to refer to non-IETF technologies in mandatory-to-implement statements (even if, as in the case of UTF-8, we sometimes choose to reference those specifications by writing an RFC that describes the link).

                         Harald

--------------090905020206000906070600-- From ingemar.s.johansson@ericsson.com Sun Dec 26 03:35:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1FF28C0E5 for ; Sun, 26 Dec 2010 03:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4-7GbDIJK5v for ; Sun, 26 Dec 2010 03:35:15 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 07FDC28C0DE for ; Sun, 26 Dec 2010 03:35:14 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-22-4d1728ee51a7 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D4.61.13987.EE8271D4; Sun, 26 Dec 2010 12:37:18 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.218]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Sun, 26 Dec 2010 12:37:18 +0100 From: Ingemar Johansson S To: Harald Alvestrand Date: Sun, 26 Dec 2010 12:37:17 +0100 Thread-Topic: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Thread-Index: AcukiQ10GDsPSjgVStydOEOow8wmCgAZlEfc Message-ID: References: , <4D167A13.4070207@alvestrand.no> In-Reply-To: <4D167A13.4070207@alvestrand.no> Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtc-web@alvestrand.no" , "dispatch@ietf.org" , "Markus.Isomaki@nokia.com" , Justin Uberti Subject: Re: [dispatch] [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2010 11:35:17 -0000 Hi I must admit that I am a real bad reader, can only blame it on Santa... :-( Tried to find some background info on AES-CTR and according to=20 http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/workshop1/papers/lipma= a-ctr.pdf it was devised already in 1979, this probably explains a lack of IPR disclo= sure for RFC3711 (at least I have not found any) Regards Ingemar =20 ________________________________________ Fr=E5n: Harald Alvestrand [harald@alvestrand.no] Skickat: den 26 december 2010 00:11 Till: Ingemar Johansson S Kopia: Justin Uberti; rtc-web@alvestrand.no; dispatch@ietf.org; Markus.Isom= aki@nokia.com =C4mne: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvest= rand-dispatch-rtcweb-protocols-00 On 12/23/10 10:44, Ingemar Johansson S wrote: Hi Justin In some sense you are very right but I make a slightly different interpreta= tion. Quoting section 4 in RFC3711 "While there are numerous encryption and message authentication algorithms = that can be used in SRTP, below we define default algorithms in order to av= oid the complexity of specifying the encodings for the signaling of algorit= hm and parameter identifiers. The defined algorithms have been chosen as th= ey fulfill the goals listed in Section 2. Recommendations on how to extend = SRTP with new transforms are given in Section 6." I don't interpret this as mandatory to implement said algorithms, rather I = see this as something needed to make the RFC complete. The encryption can b= e negotiated out of band so an implementer can avoid said algorithms comple= tely if he/she wants to. Now I don't say that this is _the_ interpretation, please correct me if nee= cessary. I don't intend to enter a heated debate about which codecs should be used. My concern is more that it is not good to end up in a situation where a man= datory codec is specified in an IETF RFC and later on gets subject to some = legal issues. What is the situation for the RFC then?, should the codec be = demoted to optional in a new RFC that deprecates the old ? I don't have the answers, hope that some of the "grey-beards" can chime in = and give some guidance later on. Regards and happy holidays /Ingemar ________________________________ From: Justin Uberti [mailto:juberti@google.com] Sent: den 22 december 2010 17:15 To: Ingemar Johansson S Cc: dispatch@ietf.org; rtc-web@alvestrand.no; Markus.Isomaki@nokia.com Subject: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alves= trand-dispatch-rtcweb-protocols-00 Ingemar, RFC 3711 defines AES as the default encryption algorithm and HMAC-SHA1 as t= he default authentication algorithm for SRTP. As a result, those algorithms= are used by pretty much every application that uses SRTP, which makes inte= roperability much easier. Ingemar, I think you misinterpret RFC 3711 slightly. More important than the text you quote is the text in section 5 of RFC 3711= : 5. Default and mandatory-to-implement Transforms The default transforms also are mandatory-to-implement transforms in SRTP. Of course, "mandatory-to-implement" does not imply "mandatory-to-use". Table 1 summarizes the pre-defined transforms. The default values below are valid for the pre-defined transforms. mandatory-to-impl. optional default encryption AES-CM, NULL AES-f8 AES-CM message integrity HMAC-SHA1 - HMAC-SHA1 key derivation (PRF) AES-CM - AES-CM Table 1: Mandatory-to-implement, optional and default transforms in SRTP and SRTCP. In other words, an SRTP implementation that does not implement AES-CM and H= MAC-SHA1 is not a conformant SRTP implementation. I think a similar statement can be made regarding the selection of MTI vide= o codecs. There are various reasons why one might choose one codec versus a= nother. But if we are unable to pick at least one default/MTI codec (for ea= ch media type), interoperability and thereby adoption of this platform will= be much more challenging. I completely agree with your reasoning here. Note that neither AES nor HMAC are IETF defined algorithms. It is indeed qu= ite common to refer to non-IETF technologies in mandatory-to-implement stat= ements (even if, as in the case of UTF-8, we sometimes choose to reference = those specifications by writing an RFC that describes the link). Harald From harald@alvestrand.no Sun Dec 26 04:00:19 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D4C28C0FF for ; Sun, 26 Dec 2010 04:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2jMRBxKOaIZ for ; Sun, 26 Dec 2010 04:00:17 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 8D4C028C0FB for ; Sun, 26 Dec 2010 04:00:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6396B39E087; Sun, 26 Dec 2010 13:01:58 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPB1YcRxUuds; Sun, 26 Dec 2010 13:01:57 +0100 (CET) Received: from [192.168.1.16] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 6926939E038; Sun, 26 Dec 2010 13:01:57 +0100 (CET) Message-ID: <4D173082.6060008@alvestrand.no> Date: Sun, 26 Dec 2010 13:09:38 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ingemar Johansson S References: , <4D167A13.4070207@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtc-web@alvestrand.no" , "dispatch@ietf.org" , "Markus.Isomaki@nokia.com" , Justin Uberti Subject: Re: [dispatch] [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2010 12:00:19 -0000 On 12/26/2010 12:37 PM, Ingemar Johansson S wrote: > Hi > > I must admit that I am a real bad reader, can only blame it on Santa... :-( > > Tried to find some background info on AES-CTR and according to > http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/workshop1/papers/lipmaa-ctr.pdf > it was devised already in 1979, this probably explains a lack of IPR disclosure for RFC3711 (at least I have not found any) I think a general IPR release was part of the requirements for Rijndael to enter into the NIST competition for the selection of the AES algorithm. If the US Government insists that something should be unencumbered, it's a little more likely to be.... > Regards > Ingemar > > ________________________________________ > Från: Harald Alvestrand [harald@alvestrand.no] > Skickat: den 26 december 2010 00:11 > Till: Ingemar Johansson S > Kopia: Justin Uberti; rtc-web@alvestrand.no; dispatch@ietf.org; Markus.Isomaki@nokia.com > Ämne: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 > > On 12/23/10 10:44, Ingemar Johansson S wrote: > Hi Justin > > In some sense you are very right but I make a slightly different interpretation. > > Quoting section 4 in RFC3711 > "While there are numerous encryption and message authentication algorithms that can be used in SRTP, below we define default algorithms in order to avoid the complexity of specifying the encodings for the signaling of algorithm and parameter identifiers. The defined algorithms have been chosen as they fulfill the goals listed in Section 2. Recommendations on how to extend SRTP with new transforms are given in Section 6." > I don't interpret this as mandatory to implement said algorithms, rather I see this as something needed to make the RFC complete. The encryption can be negotiated out of band so an implementer can avoid said algorithms completely if he/she wants to. > Now I don't say that this is _the_ interpretation, please correct me if neecessary. > > I don't intend to enter a heated debate about which codecs should be used. > My concern is more that it is not good to end up in a situation where a mandatory codec is specified in an IETF RFC and later on gets subject to some legal issues. What is the situation for the RFC then?, should the codec be demoted to optional in a new RFC that deprecates the old ? > I don't have the answers, hope that some of the "grey-beards" can chime in and give some guidance later on. > > Regards and happy holidays > /Ingemar > > > > > > ________________________________ > From: Justin Uberti [mailto:juberti@google.com] > Sent: den 22 december 2010 17:15 > To: Ingemar Johansson S > Cc: dispatch@ietf.org; rtc-web@alvestrand.no; Markus.Isomaki@nokia.com > Subject: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 > > Ingemar, > > RFC 3711 defines AES as the default encryption algorithm and HMAC-SHA1 as the default authentication algorithm for SRTP. As a result, those algorithms are used by pretty much every application that uses SRTP, which makes interoperability much easier. > Ingemar, > > I think you misinterpret RFC 3711 slightly. > > More important than the text you quote is the text in section 5 of RFC 3711: > > > 5. Default and mandatory-to-implement Transforms > > The default transforms also are mandatory-to-implement transforms in > SRTP. Of course, "mandatory-to-implement" does not imply > "mandatory-to-use". Table 1 summarizes the pre-defined transforms. > The default values below are valid for the pre-defined transforms. > > mandatory-to-impl. optional default > > encryption AES-CM, NULL AES-f8 AES-CM > message integrity HMAC-SHA1 - HMAC-SHA1 > key derivation (PRF) AES-CM - AES-CM > > Table 1: Mandatory-to-implement, optional and default transforms in > SRTP and SRTCP. > > In other words, an SRTP implementation that does not implement AES-CM and HMAC-SHA1 is not > a conformant SRTP implementation. > > > > I think a similar statement can be made regarding the selection of MTI video codecs. There are various reasons why one might choose one codec versus another. But if we are unable to pick at least one default/MTI codec (for each media type), interoperability and thereby adoption of this platform will be much more challenging. > I completely agree with your reasoning here. > > Note that neither AES nor HMAC are IETF defined algorithms. It is indeed quite common to refer to non-IETF technologies in mandatory-to-implement statements (even if, as in the case of UTF-8, we sometimes choose to reference those specifications by writing an RFC that describes the link). > > Harald > > From henry.sinnreich@gmail.com Sun Dec 26 18:10:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B7143A6835 for ; Sun, 26 Dec 2010 18:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnIu2ryOGouW for ; Sun, 26 Dec 2010 18:10:42 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id E333D3A6832 for ; Sun, 26 Dec 2010 18:10:41 -0800 (PST) Received: by vws7 with SMTP id 7so3505624vws.31 for ; Sun, 26 Dec 2010 18:12:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:mime-version :content-type:content-transfer-encoding; bh=AqzKu5+Kjb0rlcTLkvqzjknkd4YHO6KCbjlAk2LHnYQ=; b=CYLHDVHW8URSB3S/lg8KKntdjKh5FA6FON+Q6bSplKiyy6j5Z3F46/ptIOiO5cMPam iMLkOkKMqi5VfzrtW6is47JIZ/fOy393mySpRvTS9gda95hkc0eYvM6NqUYfOyA4nNAe f6MVCoZezvTk7fGK+va2TZFVn6V2rBLuP2/2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:mime-version:content-type:content-transfer-encoding; b=XHTb9KmNw9KaGXJqDhd962zGhlC575eSHJpBlciTSSwmEyLWv+1PeA8Bu5gLcC+90M 9P1Q/nYNoqERSayoJTIvyGgfGaBWqHnIHpMSIT11IdWY9DJMZCPJjsnyzUEvDW99JpjC eYYwo/UHHhAIKVX29IxWaEO6sJ/RPdgV/etUo= Received: by 10.220.75.8 with SMTP id w8mr3187661vcj.215.1293415964509; Sun, 26 Dec 2010 18:12:44 -0800 (PST) Received: from [10.0.1.4] (ool-457670fb.dyn.optonline.net [69.118.112.251]) by mx.google.com with ESMTPS id f17sm4245460vbv.6.2010.12.26.18.12.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 26 Dec 2010 18:12:43 -0800 (PST) User-Agent: Microsoft-Entourage/12.27.0.100913 Date: Sun, 26 Dec 2010 21:12:37 -0500 From: Heinrich Sinnreich To: David Singer , Message-ID: Thread-Topic: [dispatch] Codec standardization (Re: [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) Thread-Index: Acula4fhbloXYKpwBEa17VDwWqMKpw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Codec standardization (Re: [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2010 02:10:49 -0000 >I think we should consider the balance > between cost, risk, quality, and existing adoption, and it would be foolish to > omit cost-bearing codecs from that analysis, as H.264 is widely used already. I am not sure where this discussion is going, though it reminds us of the discussions when arguing about SIP vs. H.323 in the IETF. "Everybody" was shipping H.323 in overwhelming quantity, but somehow the IETF did not buy it. As an hopeless optimist; maybe H.264 will have the same fate since at least it's considerable IP baggage is so well known... It is hard to imagine the IETF and indeed the market will ignore the creativity of all the codec developers out there and the evolving technology that empowers them. Plain self interest should motivate embracing new IP-free a/v codecs for the RTC Web. They will arrive anyway one way or another. [Well deployed technology has a proven way to make it over the threshold into history :-)] Henry On 12/22/10 5:46 PM, "David Singer" wrote: > I should say that I am perfectly happy to have the discussion about whether, > and what, to mandate codec(s). If the placeholder is there to spark the > discussion, you succeeded! > > For me, significant IPR risk is worse than a payment -- free but risky is not > an improvement on costs-but-low-risk. But others may differ, of course. > > I do think we should be looking carefully at layered design. Ideally, we > define the missing technology bits -- HTML, Javascript/DOM, and so on; and > then, perhaps, we write an umbrella specification that uses those, and other > technology pieces, to achieve an interoperable end. But the pieces should > 'make sense' by themselves, and be usable with other assemblages, I think, if > the specs are to have 'legs' and survive over years. The pieces are ideally > stable standards/publications in their own right (and I agree, sometimes, > rarely, something is stable and well-known enough, such as ZIP or ID3 tags, > without being a 'standard'). > > I also agree that RF codecs are happening and are here to stay. Those of you > who know me from MPEG will have heard this before. They will exist, and they > will have a place. MPEG is working (slowly) on RF codecs as well. > > As to what MPEG-LA is doing, I am afraid I don't actually know. We'd have to > ask them, and they tend not to reply. The silence is strange, but I don't > think that mitigates the possibility that there is an IPR entanglement. > > Despite Henry's position (that mentioning VP8 results in no rat-holes and > flames, and that mentioning H.264 will) I think we should consider the balance > between cost, risk, quality, and existing adoption, and it would be foolish to > omit cost-bearing codecs from that analysis, as H.264 is widely used already. > > The link between open-source and royalty-free is not perfect; there are > quality open-source implementations of non-free codecs, for a start, and there > are companies who license proprietary systems royalty-free. Let's not confuse > the two, even if they often occur together. > > David Singer > Multimedia and Software Standards, Apple Inc. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From alan.b.johnston@gmail.com Mon Dec 27 07:09:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7233A680B for ; Mon, 27 Dec 2010 07:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.364 X-Spam-Level: X-Spam-Status: No, score=-104.364 tagged_above=-999 required=5 tests=[AWL=1.235, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkPhJ9ljSy4E for ; Mon, 27 Dec 2010 07:09:22 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id F24143A686D for ; Mon, 27 Dec 2010 07:09:21 -0800 (PST) Received: by bwz12 with SMTP id 12so9135989bwz.31 for ; Mon, 27 Dec 2010 07:11:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vUZCnS8umEkl8BWd93xrzZnQGP3EPj8L0PY2TiUIAoc=; b=AAxQVQrQY/vN/IDAZXnll8aGYM8QVZnKS4jGxjzJy+6wPwub+OE8kEfp3PHJhl/Svq OJ458+F9Fr07j858Mk/FUdIKWqm7ySDS8h1Dl9REhhnhivd9g2pgJEYCQe/XYZjIP2KL w4iN29baqOWfmis1QusZxaWOjTgwwnEta7k3g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lnubwFh7oSfmrCI/rnb/Ug353UyK1MEV66uWe/YsVGEwrOdGRu7rhIpUSo8E3XC5dX BTy2ndldM65X8zGcxZU5Vqr7yPHa41vriAWO8lfqvzjPJ+uXUyFeK+lAvqWMu5gYGkeX atP4T15HFUt4oJQszi6/prBFZNsgsFnJcCOVw= MIME-Version: 1.0 Received: by 10.204.51.11 with SMTP id b11mr3980506bkg.129.1293462684756; Mon, 27 Dec 2010 07:11:24 -0800 (PST) Received: by 10.204.232.15 with HTTP; Mon, 27 Dec 2010 07:11:24 -0800 (PST) In-Reply-To: <4D0F5E85.5030408@alvestrand.no> References: <4CDA833D.8080203@alvestrand.no> <4D0F5E85.5030408@alvestrand.no> Date: Mon, 27 Dec 2010 09:11:24 -0600 Message-ID: From: Alan Johnston To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2010 15:09:23 -0000 Harald, Thanks for the reply. I'm sure the work will get done in the right place. Clearly, Javascript is outside our expertise here at the IETF, but we have a lot of media knowledge to utilize. And as for the name, perhaps no one remembers the use of RTC by a small company based in Redmond a few years back. If so, and if there's no trademarks or other issue, then maybe we are good to use it. - Alan - On Mon, Dec 20, 2010 at 7:47 AM, Harald Alvestrand w= rote: > On 12/15/10 18:09, Alan Johnston wrote: >> >> Harald, >> >> Thanks for kicking off this work with your drafts. =A0I know a lot of us >> are greatly looking forward to starting this work after thinking and >> talking about it for a long time. >> >> My thinking is basically aligned with your draft. =A0However, I think we >> need a little more clarity on exactly what we are trying to do: >> exactly how do all the components talk to you each other using >> standard protocols or APIs? =A0I found your datagram session URI >> proposal in the other draft a little hard to understand - I think we >> will need good requirements before we can decide if this is the right >> mechanism. > > I think the API work will be handled in W3C, and described in the form of > Javascript - one central issue is that various components will have to se= nd > media to each other *without* going through the Javascript level - this i= s > AFAIK relatively new territory for all concerned. >> >> I also understand your arguments on connection management, which is >> really signaling. =A0I agree that it is possible for this to be a local >> matter between a web browser and a web server, and that establishing >> voice sessions from within a web domain can be handled without >> standards, and voice sessions between web domains could be signaled >> using existing standards such as SIP. >> >> However, I do think there is value in standardizing some kind of >> lightweight API for signaling between the browser and server. =A0 Some >> of us have been thinking about this for a while now: >> >> =A0 =A0 =A0http://tools.ietf.org/html//draft-sinnreich-sip-web-apis >> =A0 =A0 =A0http://tools.ietf.org/html/draft-peterson-sipcore-advprop >> >> The good news is that this work is completely orthogonal to the mainly >> media work you propose in your draft. But it does tie in nicely and >> helps provide a fully interoperable set of protocols/APIs, which >> ultimately is what the IETF is all about. =A0 I don't see any need for >> one effort to delay the other - in fact, both could potentially be >> done in separate working groups. > > Thanks for the pointers - will certainly read up on these! >> >> Finally, a comment on the name for the overall effort - I know, really >> important stuff... =A0The acronym RTC has baggage in our industry, and >> it might be nice avoid yet another three letter acronym ;-). =A0I was >> thinking about Web RTCom, short for Web Real Time Communications. > > Names are the ultimate timesink in discussion :-) - somewhat > tongue-in-cheek, I wonder if the best approach is if everyone with a > proposed name sends them to the BOF in Prague, we put them all in a hat, = and > then draw one at random :-) >> >> - Alan - >> >> >> >> On Wed, Nov 10, 2010 at 5:34 AM, Harald Alvestrand >> =A0wrote: >>> >>> This is the overview document for the IETF-related RTC-WEB work. >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for >>> draft-alvestrand-dispatch-rtcweb-protocols-00 >>> Date: Wed, 10 Nov 2010 03:31:05 -0800 (PST) >>> From: IETF I-D Submission Tool >>> To: harald@alvestrand.no >>> >>> A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt >>> has been successfully submitted by Harald Alvestrand and posted to the = IETF >>> repository. >>> >>> Filename: =A0 =A0 =A0 =A0draft-alvestrand-dispatch-rtcweb-protocols >>> Revision: =A0 =A0 =A0 =A000 >>> Title: =A0 =A0 =A0 =A0 =A0 Overview: Real Time Protocols for Brower-bas= ed >>> Applications >>> Creation_date: =A0 2010-11-11 >>> WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission >>> Number_of_pages: 9 >>> >>> Abstract: >>> This document gives an overview of a protocol suite intended for use >>> with real-time applications that can be deployed in browsers - "real >>> time communication on the Web". >>> >>> It intends to serve as a starting and coordination point to make sure >>> all the parts that are needed to achieve this goal are findable, and >>> that the parts that belong in the Internet protocol suite are fully >>> specified and on the right publication track. >>> >>> This work is an attempt to synthesize the input of many people, but >>> makes no claims to fully represent the views of any of them. =A0All >>> parts of the document should be regarded as open for discussion. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> > > From singer@apple.com Wed Dec 29 20:05:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75EC3A679C for ; Wed, 29 Dec 2010 20:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fC6LAlDcdPYC for ; Wed, 29 Dec 2010 20:05:53 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id EC5333A63D3 for ; Wed, 29 Dec 2010 20:05:53 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id BD395C326A30; Wed, 29 Dec 2010 20:07:33 -0800 (PST) X-AuditID: 11807134-b7cfdae000001831-a9-4d1c05859473 Received: from [17.153.101.36] (Unknown_Domain [17.153.101.36]) by relay14.apple.com (Apple SCV relay) with SMTP id 53.39.06193.5850C1D4; Wed, 29 Dec 2010 20:07:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David Singer In-Reply-To: Date: Wed, 29 Dec 2010 20:07:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6EE0B7DD-614E-4A9E-98D3-16434A8A65A7@apple.com> References: To: Heinrich Sinnreich X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: rtc-web@alvestrand.no, dispatch@ietf.org Subject: Re: [dispatch] Codec standardization (Re: [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 04:05:54 -0000 Heinrich, 'best' is not always IPR-cost-free. Sometimes it is, sometimes it = isn't. You seem unable to see any other possibility than your own, = alas. I could wish for 'fates' for any number of technologies, but I = don't: I choose them when they suit, and others when they don't. I = suggest we do the same. I have no objection to the development and deployment of new codecs, = with varying terms, quality, complexity, and so on. This is a varied = market that deserves varied tools. I do object to making decisions = based on only one criterion, however. On Dec 26, 2010, at 18:12 , Heinrich Sinnreich wrote: >> I think we should consider the balance >> between cost, risk, quality, and existing adoption, and it would be = foolish to >> omit cost-bearing codecs from that analysis, as H.264 is widely used = already. >=20 > I am not sure where this discussion is going, though it reminds us of = the > discussions when arguing about SIP vs. H.323 in the IETF. > "Everybody" was shipping H.323 in overwhelming quantity, but somehow = the > IETF did not buy it. >=20 > As an hopeless optimist; maybe H.264 will have the same fate since at = least > it's considerable IP baggage is so well known... >=20 > It is hard to imagine the IETF and indeed the market will ignore the > creativity of all the codec developers out there and the evolving = technology > that empowers them. Plain self interest should motivate embracing new > IP-free a/v codecs for the RTC Web. They will arrive anyway one way or > another.=20 >=20 > [Well deployed technology has a proven way to make it over the = threshold > into history :-)]=20 >=20 David Singer Multimedia and Software Standards, Apple Inc. From bernard_aboba@hotmail.com Wed Dec 29 22:07:18 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF0B3A6911 for ; Wed, 29 Dec 2010 22:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28JlNXspLYIH for ; Wed, 29 Dec 2010 22:07:16 -0800 (PST) Received: from blu0-omc1-s8.blu0.hotmail.com (blu0-omc1-s8.blu0.hotmail.com [65.55.116.19]) by core3.amsl.com (Postfix) with ESMTP id 05DDC3A6894 for ; Wed, 29 Dec 2010 22:07:15 -0800 (PST) Received: from BLU152-DS16 ([65.55.116.7]) by blu0-omc1-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Dec 2010 22:09:21 -0800 X-Originating-IP: [98.203.198.61] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'David Singer'" , "'Heinrich Sinnreich'" References: <6EE0B7DD-614E-4A9E-98D3-16434A8A65A7@apple.com> In-Reply-To: <6EE0B7DD-614E-4A9E-98D3-16434A8A65A7@apple.com> Date: Wed, 29 Dec 2010 22:09:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acun1ypRggSUevF3SImFEz7WnwD6ugAC/Jsg Content-Language: en-us X-OriginalArrivalTime: 30 Dec 2010 06:09:21.0267 (UTC) FILETIME=[19863C30:01CBA7E8] Cc: rtc-web@alvestrand.no, dispatch@ietf.org Subject: Re: [dispatch] [RTW] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 06:07:18 -0000 For video codecs, "self interest" may be influenced by a number of factors. For example, for a mobile applications developer, "self interest" may focus on aspects such as performance, battery life and maintenance costs. If a given codec is supported in the hardware or operating system of their target platform, then the developer may perceive it being low "cost" to them. For a chipset manufacturer, "self interest" may be determined by the demand for chipsets incorporating a given codec, as well as the associated licensing fees. Typically the goal is to maximize revenue minus cost, not just to minimize "cost". These concepts of "self interest" not necessarily align with each other, let alone with the "self interest" of users, who may primarily care about how many other users they can connect with. -----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of David Singer Sent: Wednesday, December 29, 2010 8:08 PM To: Heinrich Sinnreich Cc: rtc-web@alvestrand.no; dispatch@ietf.org Subject: Re: [RTW] [dispatch] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) Heinrich, 'best' is not always IPR-cost-free. Sometimes it is, sometimes it isn't. You seem unable to see any other possibility than your own, alas. I could wish for 'fates' for any number of technologies, but I don't: I choose them when they suit, and others when they don't. I suggest we do the same. I have no objection to the development and deployment of new codecs, with varying terms, quality, complexity, and so on. This is a varied market that deserves varied tools. I do object to making decisions based on only one criterion, however. On Dec 26, 2010, at 18:12 , Heinrich Sinnreich wrote: >> I think we should consider the balance >> between cost, risk, quality, and existing adoption, and it would be foolish to >> omit cost-bearing codecs from that analysis, as H.264 is widely used already. > > I am not sure where this discussion is going, though it reminds us of the > discussions when arguing about SIP vs. H.323 in the IETF. > "Everybody" was shipping H.323 in overwhelming quantity, but somehow the > IETF did not buy it. > > As an hopeless optimist; maybe H.264 will have the same fate since at least > it's considerable IP baggage is so well known... > > It is hard to imagine the IETF and indeed the market will ignore the > creativity of all the codec developers out there and the evolving technology > that empowers them. Plain self interest should motivate embracing new > IP-free a/v codecs for the RTC Web. They will arrive anyway one way or > another. > > [Well deployed technology has a proven way to make it over the threshold > into history :-)] > David Singer Multimedia and Software Standards, Apple Inc. _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web From Markus.Isomaki@nokia.com Thu Dec 30 07:50:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119053A6840 for ; Thu, 30 Dec 2010 07:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.788 X-Spam-Level: X-Spam-Status: No, score=-7.788 tagged_above=-999 required=5 tests=[AWL=2.811, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpYMIOI2z+tW for ; Thu, 30 Dec 2010 07:50:40 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 4B1823A6832 for ; Thu, 30 Dec 2010 07:50:38 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBUFqL6K023273; Thu, 30 Dec 2010 17:52:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Dec 2010 17:52:29 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 30 Dec 2010 16:52:29 +0100 Received: from 008-AM1MPN1-003.mgdnok.nokia.com ([169.254.3.121]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi; Thu, 30 Dec 2010 16:52:29 +0100 From: To: Thread-Topic: Comments on draft-alvestrand-dispatch-rtcweb-datagram Thread-Index: AQHLqDmPUiq6wSZOGkqn94inPkNwTQ== Date: Thu, 30 Dec 2010 15:52:26 +0000 Message-ID: References: <6EE0B7DD-614E-4A9E-98D3-16434A8A65A7@apple.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Dec 2010 15:52:29.0926 (UTC) FILETIME=[9063E860:01CBA839] X-Nokia-AV: Clean Cc: rtc-web@alvestrand.no, dispatch@ietf.org Subject: [dispatch] Comments on draft-alvestrand-dispatch-rtcweb-datagram X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 15:50:42 -0000 Hi,=20 A couple of questions and comments on draft-alvestrand-dispatch-rtcweb-data= gram-00: * Section 4 defines four channel types: UDP, TCP, TLS and DTLS. Is it expec= ted that all clients MUST support all of these? I suppose the reason why bo= th UDP and TCP are included is that depending on the types of middleboxes t= he peers are behind, they may get just one or the other working. I.e. first= try out UDP, if it does not work, attempt TCP. Is that correct? * Section 4.5 states that TURN and relaying are needed. How about things li= ke HTTP/TLS tunneling? In many cases that is the only way to get the transp= ort channel working. TURN may be helpful in some, hopefully increasing, amo= unt of cases, but that alone will still leave a lot of corporate users unse= rved. * Section 3 mentions that things like pseudoTCP can be run over the datagra= m transport. In case only UDP works end-to-end that seems useful. However, = if we can get a "native" TCP connection up, it seems natural to use that as= is rather than via some kind of generic datagram abstraction layer. I thin= k we probably should define both datagram and bytestream services separatel= y. Bytestream would be either TCP or pseudoTCP/UDP. If we only do datagram = service, leave the whole pseudoTCP reference out. * Section 6 defines a URI with a number of IP address:transport:port candid= ates. I'm not too clear on how that URI would be used. It looks to me as so= mething that is received as a result of gathering the candidates (with STUN= , TURN etc.) as the first step of ICE. If Jingle or SDP offer/answer or som= e proprietary protocol were used to pass the candidate information to the o= ther peer, that information would be encoded according to that particular p= rotocol. So is this specific URI just meant for local representation at the= API and not something that is passed over the network as such? What's the = need or benefit of making it a URI? Thanks, Markus From Markus.Isomaki@nokia.com Thu Dec 30 08:08:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D508C3A6830 for ; Thu, 30 Dec 2010 08:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.069 X-Spam-Level: X-Spam-Status: No, score=-8.069 tagged_above=-999 required=5 tests=[AWL=2.530, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bliimfc+U3hU for ; Thu, 30 Dec 2010 08:08:50 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id CE39A3A680F for ; Thu, 30 Dec 2010 08:08:49 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBUGApf2007212; Thu, 30 Dec 2010 18:10:52 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Dec 2010 18:10:46 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 30 Dec 2010 17:10:46 +0100 Received: from 008-AM1MPN1-003.mgdnok.nokia.com ([169.254.3.121]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi; Thu, 30 Dec 2010 17:10:46 +0100 From: To: Thread-Topic: Comments on draft-alvestrand-dispatch-rtcweb-protocols-00 Thread-Index: AQHLqDweVe9rVAFWQEuOIZeb7qO1eQ== Date: Thu, 30 Dec 2010 16:10:45 +0000 Message-ID: References: <6EE0B7DD-614E-4A9E-98D3-16434A8A65A7@apple.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Dec 2010 16:10:46.0966 (UTC) FILETIME=[1E46ED60:01CBA83C] X-Nokia-AV: Clean Cc: rtc-web@alvestrand.no, dispatch@ietf.org Subject: [dispatch] Comments on draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 16:08:50 -0000 Hi, A few comments and questions on rtcweb-protocols-00: In general I believe we need a framework document that describes how the va= rious protocol and API specs are used to build an interoperable "RTC-Web" i= mplementation. In my opinion that document should not be like RFC 5411 (Hit= chhiker's guide to SIP), which is merely listing of different SIP related s= tandards. Instead, the RTC-Web framework document should define what is the= minimum set that everyone needs to implement to get interop at a reasonabl= e level. (What that reasonable level is needs to be agreed upon, of course.= I assume it includes at least transport and NAT traversal for audio/video = streams.) I understand that the current document is not yet intended for that purpose= , but it is just trying to get discussion started. But if we pick this draf= t as a baseline going forward, it would be useful to make the use of langua= ge more consistent. At the moment some things are defined with "MUST" state= ments while others are more vague. I think the "MUST" statements are good a= nd everything that is really required by an implementation needs to be expr= essed that way. (It is naturally good to have some descriptive text around = the exact requirements, as long as the requirements are clear.) Section 4 defines data framing and security. I believe the challenging part= of data framing will be to ensure we get the video calls interoperable. I = don't have that much experience on the details, but I know that getting RTP= /AVPF stuff implemented and interoperable is not that trivial. Various grou= ps such as IMTC and UCIF have worked on interoperability profiles for video= calls. The easy approach might be just to mandate the basics (RTP/AVP), ge= t that well working across browsers and then extend based on that experienc= e. If those other groups come up with something useful and public, those pr= ofiles could be borrowed.=20 Section 6 is about connection management. That will be the really hard part= of this exercise. I do support the notion that at least initially we shoul= d focus on transport, framing and formats of media, and say that those can = be setup in proprietary ways (presumably the browser using HTTP or websocke= t as transport for the actual setup). For that the APIs would "only" need t= o support what is input/output to ICE/STUN/TURN and codec selection, while = the rest happens in Javascript within the application. But going forward I = think we do need to pick up either SIP/SDP or XMPP/Jingle as the baseline, = in order to make things easy to use.=20 Markus=20 From henry.sinnreich@gmail.com Thu Dec 30 09:00:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82EFF3A67D3 for ; Thu, 30 Dec 2010 09:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PV3V8gnSX9O2 for ; Thu, 30 Dec 2010 09:00:43 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id D99093A6403 for ; Thu, 30 Dec 2010 09:00:42 -0800 (PST) Received: by ywk9 with SMTP id 9so5067974ywk.31 for ; Thu, 30 Dec 2010 09:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=ETpJ2MfLB1oYlBOTBiHdDNMJE6lHxjc5aF5T7DzpIBw=; b=kYJGr7jzDvadHfDK3R/f/ybLWYTT1qPXC4Ff57O0tCn7ezXz51zuYiFu+WHLiClKgO 5SCWy83Zdfr0dd/DK+n86Wtgo10VjYNZL6Hlo/Rgnjtbc1KZkJdok8OfVujlW+RByeG1 rfCov15mMtB/poL40m34YFbTqmfK+5oKcMHVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=ZdamklVwY9LvHw0vrwMuj+NHN9E4O2pYvLrn/7xoTas2rIG+0UuBldLcPNWxameS4M DNRfB7szB4g9+mpIDyhNg3k+WrWIqiFVrrRDfdoAqR3pE7ppVCX15q2AqwkDgZM0E2Vv xU6NCME7aZsa7gD5iDTtXSfw1msLOEqktrIgM= Received: by 10.236.103.37 with SMTP id e25mr5459101yhg.25.1293728566117; Thu, 30 Dec 2010 09:02:46 -0800 (PST) Received: from [10.0.1.5] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id f13sm9140450yhf.33.2010.12.30.09.02.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Dec 2010 09:02:44 -0800 (PST) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 30 Dec 2010 11:02:42 -0600 From: Henry Sinnreich To: Bernard Aboba , 'David Singer' Message-ID: Thread-Topic: [RTW] [dispatch] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) Thread-Index: Acun1ypRggSUevF3SImFEz7WnwD6ugAC/JsgABgQj40= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: rtc-web@alvestrand.no, dispatch@ietf.org Subject: Re: [dispatch] [RTW] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 17:00:44 -0000 This should mark a good progress for the discussion ending this year and we hopefully can all agree: > These concepts of "self interest" not necessarily align with each other, let > alone with the > "self interest" of users, who may primarily care about how many other users > they can connect > with. The interests of users must be first and foremost in mind for defining a standard for the default video codec. It includes not passing the cost of licensing in perpetuity along to users. Given a choice for open source and/or free video codecs such as Theora and VP8, the IETF has several good options to choose from, also defining of a video codec from ground up. Thanks, Henry On 12/30/10 12:09 AM, "Bernard Aboba" wrote: > For video codecs, "self interest" may be influenced by a number of factors. > > For example, for a mobile applications developer, "self interest" may focus > on > aspects such as performance, battery life and maintenance costs. If a given > codec is > supported in the hardware or operating system of their target platform, then > the developer > may perceive it being low "cost" to them. > > For a chipset manufacturer, "self interest" may be determined by the demand > for chipsets > incorporating a given codec, as well as the associated licensing fees. > Typically the goal > is to maximize revenue minus cost, not just to minimize "cost". > > These concepts of "self interest" not necessarily align with each other, let > alone with the > "self interest" of users, who may primarily care about how many other users > they can connect > with. > > -----Original Message----- > From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] > On Behalf Of David Singer > Sent: Wednesday, December 29, 2010 8:08 PM > To: Heinrich Sinnreich > Cc: rtc-web@alvestrand.no; dispatch@ietf.org > Subject: Re: [RTW] [dispatch] Codec standardization (Re: Fwd: New Version > Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) > > Heinrich, > > 'best' is not always IPR-cost-free. Sometimes it is, sometimes it isn't. > You seem unable to see any other possibility than your own, alas. I could > wish for 'fates' for any number of technologies, but I don't: I choose them > when they suit, and others when they don't. I suggest we do the same. > > I have no objection to the development and deployment of new codecs, with > varying terms, quality, complexity, and so on. This is a varied market that > deserves varied tools. I do object to making decisions based on only one > criterion, however. > > > On Dec 26, 2010, at 18:12 , Heinrich Sinnreich wrote: > >>> I think we should consider the balance >>> between cost, risk, quality, and existing adoption, and it would be > foolish to >>> omit cost-bearing codecs from that analysis, as H.264 is widely used > already. >> >> I am not sure where this discussion is going, though it reminds us of the >> discussions when arguing about SIP vs. H.323 in the IETF. >> "Everybody" was shipping H.323 in overwhelming quantity, but somehow the >> IETF did not buy it. >> >> As an hopeless optimist; maybe H.264 will have the same fate since at > least >> it's considerable IP baggage is so well known... >> >> It is hard to imagine the IETF and indeed the market will ignore the >> creativity of all the codec developers out there and the evolving > technology >> that empowers them. Plain self interest should motivate embracing new >> IP-free a/v codecs for the RTC Web. They will arrive anyway one way or >> another. >> >> [Well deployed technology has a proven way to make it over the threshold >> into history :-)] >> > > David Singer > Multimedia and Software Standards, Apple Inc. > > _______________________________________________ > RTC-Web mailing list > RTC-Web@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web > From stephen.botzko@gmail.com Thu Dec 30 09:36:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E483A6813 for ; Thu, 30 Dec 2010 09:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.076 X-Spam-Level: X-Spam-Status: No, score=-3.076 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5RU0ANhkBGJ for ; Thu, 30 Dec 2010 09:36:47 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id EC0FC3A67AE for ; Thu, 30 Dec 2010 09:36:46 -0800 (PST) Received: by qwg5 with SMTP id 5so11826743qwg.31 for ; Thu, 30 Dec 2010 09:38:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=r3syZrwaNvUtS9IoZ2KsnEbkaU7g7Z4sma0c9Mb3jaE=; b=RUlUPPZi2lBSG1aXgnd3okIoupIj25vLE/mqyUIaQNuxGatAnsY7sW52Fc+WteWYdO 4HlwQz2NQD9Oazvv8giJm2HgZzVZoFiMBU01sp9ugiZaK2PPIDY58AQA4r0yEUETCY9E YSCCbEaVfcSqiOpOTLy0rtIyNG3bhP3ef1+EY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=m/TVABi+CdzHyaqzapM/GNSu3r2ieXoo0jP4pf3Y/+9Up3mQxZ3iZ+Dmr/67Kbfjnu 6PWpjmgrD9jGFWP7M97BNyN4OkUc1HtbvTgH4bpgHRwAwGTpsAueT3VFvgeJgz9L2xF/ nJ8bVyYRCSKxcAv/+SdRak6QTmLxkZTkRBW6c= MIME-Version: 1.0 Received: by 10.224.20.4 with SMTP id d4mr15309906qab.345.1293730732371; Thu, 30 Dec 2010 09:38:52 -0800 (PST) Received: by 10.220.128.30 with HTTP; Thu, 30 Dec 2010 09:38:52 -0800 (PST) In-Reply-To: References: Date: Thu, 30 Dec 2010 12:38:52 -0500 Message-ID: From: Stephen Botzko To: Henry Sinnreich Content-Type: multipart/alternative; boundary=0015175cda2cbcf0590498a428b6 Cc: Bernard Aboba , rtc-web@alvestrand.no, dispatch@ietf.org Subject: Re: [dispatch] [RTW] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 17:36:48 -0000 --0015175cda2cbcf0590498a428b6 Content-Type: text/plain; charset=ISO-8859-1 I'm with Bernard and David on this one. This is different from the audio case, as hardware acceleration is much more important for video, particularly for mobile. Stephen Botzko On Thu, Dec 30, 2010 at 12:02 PM, Henry Sinnreich wrote: > This should mark a good progress for the discussion ending this year and we > hopefully can all agree: > > > These concepts of "self interest" not necessarily align with each other, > let > > alone with the > > "self interest" of users, who may primarily care about how many other > users > > they can connect > > with. > > The interests of users must be first and foremost in mind for defining a > standard for the default video codec. > > It includes not passing the cost of licensing in perpetuity along to users. > > Given a choice for open source and/or free video codecs such as Theora and > VP8, the IETF has several good options to choose from, also defining of a > video codec from ground up. > > Thanks, > > Henry > > > On 12/30/10 12:09 AM, "Bernard Aboba" wrote: > > > For video codecs, "self interest" may be influenced by a number of > factors. > > > > For example, for a mobile applications developer, "self interest" may > focus > > on > > aspects such as performance, battery life and maintenance costs. If a > given > > codec is > > supported in the hardware or operating system of their target platform, > then > > the developer > > may perceive it being low "cost" to them. > > > > For a chipset manufacturer, "self interest" may be determined by the > demand > > for chipsets > > incorporating a given codec, as well as the associated licensing fees. > > Typically the goal > > is to maximize revenue minus cost, not just to minimize "cost". > > > > These concepts of "self interest" not necessarily align with each other, > let > > alone with the > > "self interest" of users, who may primarily care about how many other > users > > they can connect > > with. > > > > -----Original Message----- > > From: rtc-web-bounces@alvestrand.no [mailto: > rtc-web-bounces@alvestrand.no] > > On Behalf Of David Singer > > Sent: Wednesday, December 29, 2010 8:08 PM > > To: Heinrich Sinnreich > > Cc: rtc-web@alvestrand.no; dispatch@ietf.org > > Subject: Re: [RTW] [dispatch] Codec standardization (Re: Fwd: New Version > > Notification for draft-alvestrand-dispatch-rtcweb-protocols-00) > > > > Heinrich, > > > > 'best' is not always IPR-cost-free. Sometimes it is, sometimes it isn't. > > You seem unable to see any other possibility than your own, alas. I > could > > wish for 'fates' for any number of technologies, but I don't: I choose > them > > when they suit, and others when they don't. I suggest we do the same. > > > > I have no objection to the development and deployment of new codecs, with > > varying terms, quality, complexity, and so on. This is a varied market > that > > deserves varied tools. I do object to making decisions based on only one > > criterion, however. > > > > > > On Dec 26, 2010, at 18:12 , Heinrich Sinnreich wrote: > > > >>> I think we should consider the balance > >>> between cost, risk, quality, and existing adoption, and it would be > > foolish to > >>> omit cost-bearing codecs from that analysis, as H.264 is widely used > > already. > >> > >> I am not sure where this discussion is going, though it reminds us of > the > >> discussions when arguing about SIP vs. H.323 in the IETF. > >> "Everybody" was shipping H.323 in overwhelming quantity, but somehow the > >> IETF did not buy it. > >> > >> As an hopeless optimist; maybe H.264 will have the same fate since at > > least > >> it's considerable IP baggage is so well known... > >> > >> It is hard to imagine the IETF and indeed the market will ignore the > >> creativity of all the codec developers out there and the evolving > > technology > >> that empowers them. Plain self interest should motivate embracing new > >> IP-free a/v codecs for the RTC Web. They will arrive anyway one way or > >> another. > >> > >> [Well deployed technology has a proven way to make it over the threshold > >> into history :-)] > >> > > > > David Singer > > Multimedia and Software Standards, Apple Inc. > > > > _______________________________________________ > > RTC-Web mailing list > > RTC-Web@alvestrand.no > > http://www.alvestrand.no/mailman/listinfo/rtc-web > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0015175cda2cbcf0590498a428b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm with Bernard and David on this one.=A0

This is different fr= om the audio case, as hardware acceleration is much more important for vide= o, particularly for mobile.

Stephen Botzko

On Thu, Dec 30, 2010 at 12:02 PM, Henry Sinnreich <henry.sinnreich@gmail.com>= wrote:
This should mark a good progress for the discussion ending this year and we=
hopefully can all agree:

> These concepts of "self interest" not necessarily align with= each other, let
> alone with the
> "self interest" of users, who may primarily care about how m= any other users
> they can connect
> with.

The interests of users must be first and foremost in mind for definin= g a
standard for the default video codec.

It includes not passing the cost of licensing in perpetuity along to users.=

Given a choice for open source and/or free video codecs such as Theora and<= br> VP8, the IETF has several good options to choose from, also defining of a video codec from ground up.

Thanks,

Henry


On 12/30/10 12:09 AM, "Bernard Aboba" <bernard_aboba@hotmail.com> wrote:

> For video codecs, "self interest" may be influenced by a num= ber of factors.
>
> For example, for a mobile applications developer, "self interest&= quot; may focus
> on
> aspects such as performance, battery life and maintenance costs. =A0If= a given
> codec is
> supported in the hardware or operating system of their target platform= , then
> the developer
> may perceive it being low "cost" to them.
>
> For a chipset manufacturer, "self interest" may be determine= d by the demand
> for chipsets
> incorporating a given codec, as well as the associated licensing fees.=
> Typically the goal
> is to maximize revenue minus cost, not just to minimize "cost&quo= t;.
>
> These concepts of "self interest" not necessarily align with= each other, let
> alone with the
> "self interest" of users, who may primarily care about how m= any other users
> they can connect
> with.
>
> -----Original Message-----
> From: rtc-web-bounces= @alvestrand.no [mailto:rtc-web-bounces@alvestrand.no]
> On Behalf Of David Singer
> Sent: Wednesday, December 29, 2010 8:08 PM
> To: Heinrich Sinnreich
> Cc: rtc-web@alvestrand.no= ; dispatch@ietf.org
> Subject: Re: [RTW] [dispatch] Codec standardization (Re: Fwd: New Vers= ion
> Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)
>
> Heinrich,
>
> 'best' is not always IPR-cost-free. =A0Sometimes it is, someti= mes it isn't.
> You seem unable to see any other possibility than your own, alas. =A0I= could
> wish for 'fates' for any number of technologies, but I don'= ;t: I choose them
> when they suit, and others when they don't. =A0I suggest we do the= same.
>
> I have no objection to the development and deployment of new codecs, w= ith
> varying terms, quality, complexity, and so on. This is a varied market= that
> deserves varied tools. =A0I do object to making decisions based on onl= y one
> criterion, however.
>
>
> On Dec 26, 2010, at 18:12 , Heinrich Sinnreich wrote:
>
>>> I think we should consider the balance
>>> between cost, risk, quality, and existing adoption, and it wou= ld be
> foolish to
>>> omit cost-bearing codecs from that analysis, as H.264 is widel= y used
> already.
>>
>> I am not sure where this discussion is going, though it reminds us= of the
>> discussions when arguing about SIP vs. H.323 in the IETF.
>> "Everybody" was shipping H.323 in overwhelming quantity,= but somehow the
>> IETF did not buy it.
>>
>> As an hopeless optimist; maybe H.264 will have the same fate since= at
> least
>> it's considerable IP baggage is so well known...
>>
>> It is hard to imagine the IETF and indeed the market will ignore t= he
>> creativity of all the codec developers out there and the evolving<= br> > technology
>> that empowers them. Plain self interest should motivate embracing = new
>> IP-free a/v codecs for the RTC Web. They will arrive anyway one wa= y or
>> another.
>>
>> [Well deployed technology has a proven way to make it over the thr= eshold
>> into history :-)]
>>
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>


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

--0015175cda2cbcf0590498a428b6--