From alan.b.johnston@gmail.com Wed Jun 1 05:38:06 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE04BE0971 for ; Wed, 1 Jun 2011 05:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.561 X-Spam-Level: X-Spam-Status: No, score=-103.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiB4sMHn35U3 for ; Wed, 1 Jun 2011 05:38:06 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 31C63E0A1C for ; Wed, 1 Jun 2011 05:10:02 -0700 (PDT) Received: by yic13 with SMTP id 13so2961905yic.31 for ; Wed, 01 Jun 2011 05:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c5ZOIZM+JhdzZn3HnXnyhJetUUuaHJVAW3FEQnJ4XHE=; b=fb0xtT16lX2AX8PThFenQicg0Xza0RacO8RFIgeKwpafuH2IxwKqJpjGK5YaZaKrwt 0HD2y8IMPpEmkWBBTx4+7evyCeTjJv4ZPh+6mzrbmzuGX+RGqMSJWD7U8gQ87nGMzGCo qAXZsvQ1/ESLQeF42Qc9H3PBT6cw13iVdc6dA= 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=xtHvDU+T29IryoVEFs6cBtAxZvaWyiBltDNx2yRYporfX7lFfHR9L1Y2jN4qxDOMZz bjXdCUWqEeOcSwuF/9YGSihGPOitkrNmYzp4HTpA0fk+n0juMDTa3ZR69EHBtNFVjiLA 6+/B2Ej3mmbXQzLPuVu37xzdn9XJWf8slOppg= MIME-Version: 1.0 Received: by 10.150.174.18 with SMTP id w18mr5832186ybe.374.1306930201636; Wed, 01 Jun 2011 05:10:01 -0700 (PDT) Received: by 10.150.138.8 with HTTP; Wed, 1 Jun 2011 05:10:01 -0700 (PDT) In-Reply-To: References: <20110601031504.20944.62409.idtracker@ietfa.amsl.com> Date: Wed, 1 Jun 2011 07:10:01 -0500 Message-ID: From: Alan Johnston To: Justin Uberti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" , Phil Zimmermann Subject: Re: [rtcweb] Fwd: I-D Action: draft-johnston-rtcweb-media-privacy-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 12:38:06 -0000 Justin, Thanks for your comment. You are correct, the mapping of any offer/answer exchange will need to be mappable to SDP, so this is possible. - Alan - On Tue, May 31, 2011 at 10:41 PM, Justin Uberti wrote: > Interesting read. One comment - I believe the statement in this draft > "In the RTCWEB architecture, there is no standardization of the signaling > protocol possible, and hence this [SRTP SDES] approach can not be used" > is not completely accurate. While the syntax of the signaling protocol (e= .g. > HTTP, XMPP, SIP) is left up to the web application, we must have a clear > definition of the protocol semantics, as well as the format of session > descriptions (as understood by the browser), so that they can be mapped t= o > SDP / XMPP if desired. > Therefore there is no reason we cannot include SRTP keying information in > these session descriptions. > > On Tue, May 31, 2011 at 8:21 PM, Alan Johnston > wrote: >> >> All, >> >> Here is a new draft with some thoughts on media privacy in RTCWEB. =A0We >> discuss the challenge of providing media privacy for browser users >> when there is no standardization of the signaling protocol. =A0We also >> discuss the need to sometimes allow trusted Man in the Middle (MitM) >> servers to provide media services. We also discuss how ZRTP ("Media >> Path Key Agreement for Unicast Secure RTP" RFC 6189) meets these >> requirements. >> >> Comments most welcome. >> >> - Alan - >> >> >> ---------- Forwarded message ---------- >> From: =A0 >> Date: Tue, May 31, 2011 at 10:15 PM >> Subject: I-D Action: draft-johnston-rtcweb-media-privacy-00.txt >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : RTCWEB Media Privacy >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Alan Johnston >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Philip Zimmermann >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-johnston-rtcweb-media-pri= vacy-00.txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 7 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-05-31 >> >> =A0 RTCWEB is the joint effort between the IETF and the W3C to add real- >> =A0 time voice, video, and communication capabilities to browsers. =A0Th= is >> =A0 document looks at the requirements for media privacy and existing >> =A0 mechanisms. >> >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-johnston-rtcweb-media-privacy-= 00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> >> ftp://ftp.ietf.org/internet-drafts/draft-johnston-rtcweb-media-privacy-0= 0.txt >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > From john.lazzaro@gmail.com Thu Jun 2 11:56:48 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F06E088D for ; Thu, 2 Jun 2011 11:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsK3VB8SyLLZ for ; Thu, 2 Jun 2011 11:56:47 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A85CEE0888 for ; Thu, 2 Jun 2011 11:56:47 -0700 (PDT) Received: by gyf3 with SMTP id 3so593061gyf.31 for ; Thu, 02 Jun 2011 11:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=ds0jAe190jOoCbdoK9lwrqEbNo43/w3j3ClimxRseFE=; b=B4kmErk4p2nLQmCHs7A9g+zmY8jC0UyMJTXdjIMpwvPX6E7Ww1jTs6Hw0fwWTSrK6n n65mQ99tvbBKnK2hZ0jA1q9hCWGFn2N/7NeWxXmfXPKb/C4BzvGgNHNAfOX+Qu6sDvfM zhBadLlr8DRE+FoNryFXvCZEhh3Q/aUFH0QSQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=klq0QiWVl+EJTXetZ9BCndrmEgzvO4uWLdltn0wh/khMVzS79iHsnuSpnqeOIoIPca kPyRW8ccfRQkTtrGhs66DHGZj+t1RkrEF7ceGE/DWCvudwEuhKRRiBjYoOsSE8z/pfbl hYfTJ/Nc242PQYjEAT0BQ10+mlvy4KquWJBD4= MIME-Version: 1.0 Received: by 10.151.41.18 with SMTP id t18mr1020165ybj.192.1307041007124; Thu, 02 Jun 2011 11:56:47 -0700 (PDT) Received: by 10.151.79.7 with HTTP; Thu, 2 Jun 2011 11:56:46 -0700 (PDT) Date: Thu, 2 Jun 2011 11:56:46 -0700 Message-ID: From: John Lazzaro To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] rtcweb use cases for audio/rtp-midi X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 18:56:48 -0000 Hi everyone, Just a note to let everyone know I'm monitoring this list, in case there is interest in adding audio/rtp-midi to the list of supported payload formats for rtcweb. I can see a few reasons why audio/rtp-midi support may be a good idea: [1] There are now hundreds of iOS apps that use rtp-midi via Apple's Network MIDI protocol, to let iPads and iPhones serve as touch-screen musical instrument and mixing console controllers. One could imagine wanting platform-independent versions of these applications in web browsers. [2] Network musical performance sessions, as described in the introduction section to RFC 4695 (soon to be obsoleted by RFC 6295). [3] Both games and telephony have, over the years, found it useful to have a simple General MIDI or DLS synthesis engine around, to create low-bitrate music in lieu of streaming audio files. One could imagine web applications benefitting from this as well, and over-the-network MIDI control being a requirement. [4] Platforms such as ChromeOS, which only have a web browser, would benefit from having standardized real-time MIDI control as a web standard, even if network use is not of interest. In this use case, one would want to plug a MIDI keyboard into the ChromeOS device USB port, and use the keyboard to control a music synthesizer locally running as a web app -- the sort of infrastructure that would need to be around to make apps [1], [2], [3] above work best. -- That all said, its not clear to me that it makes sense for me to write an I-D describing this as a use case for the first-generation rtcweb. There are so many challenges to reaching consensus and interoperability for plain-vanilla audio-video teleconferencing, that I don't think adding "nice-to-haves" like MIDI to the manifest is prudent. So I was planning to just watch and wait. But, if anyone out there thinks waiting is not a good idea, feel free to speak up, and if there's sufficient interest I'll write up an I-D on the topic. Thanks, -- John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com From harald@alvestrand.no Sat Jun 4 22:55:47 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE8621F8499 for ; Sat, 4 Jun 2011 22:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mpCvJkLlFLT for ; Sat, 4 Jun 2011 22:55:47 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFF621F8498 for ; Sat, 4 Jun 2011 22:55:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AB62539E0F5 for ; Sun, 5 Jun 2011 07:54:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4n7lhCL4-fQ for ; Sun, 5 Jun 2011 07:54:47 +0200 (CEST) Received: from [192.168.2.18] (unknown [78.188.20.69]) by eikenes.alvestrand.no (Postfix) with ESMTPS id AF41D39E04C for ; Sun, 5 Jun 2011 07:54:47 +0200 (CEST) Message-ID: <4DEB1A63.9040909@alvestrand.no> Date: Sun, 05 Jun 2011 07:55:47 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] rtcweb use cases for audio/rtp-midi X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 05:55:48 -0000 This (midi in browsers) seems to be closely related to what the W3C "audio" group is doing. Are you in contact with them? Harald On 06/02/11 20:56, John Lazzaro wrote: > Hi everyone, > > Just a note to let everyone know I'm > monitoring this list, in case there is > interest in adding audio/rtp-midi to the > list of supported payload formats for rtcweb. > > I can see a few reasons why audio/rtp-midi > support may be a good idea: > > [1] There are now hundreds of iOS apps that > use rtp-midi via Apple's Network MIDI protocol, > to let iPads and iPhones serve as touch-screen > musical instrument and mixing console controllers. > One could imagine wanting platform-independent > versions of these applications in web browsers. > > [2] Network musical performance sessions, as > described in the introduction section to RFC 4695 > (soon to be obsoleted by RFC 6295). > > [3] Both games and telephony have, over the years, > found it useful to have a simple General MIDI or > DLS synthesis engine around, to create low-bitrate > music in lieu of streaming audio files. One could > imagine web applications benefitting from this as well, > and over-the-network MIDI control being a requirement. > > [4] Platforms such as ChromeOS, which only have > a web browser, would benefit from having standardized > real-time MIDI control as a web standard, even if > network use is not of interest. In this use case, > one would want to plug a MIDI keyboard into the > ChromeOS device USB port, and use the keyboard > to control a music synthesizer locally running as a > web app -- the sort of infrastructure that would need > to be around to make apps [1], [2], [3] above work best. > > -- > > That all said, its not clear to me that it makes sense > for me to write an I-D describing this as a use case > for the first-generation rtcweb. There are so many > challenges to reaching consensus and interoperability > for plain-vanilla audio-video teleconferencing, that I don't > think adding "nice-to-haves" like MIDI to the manifest > is prudent. So I was planning to just watch and wait. > > But, if anyone out there thinks waiting is not a good > idea, feel free to speak up, and if there's sufficient > interest I'll write up an I-D on the topic. Thanks, > From harald@alvestrand.no Sun Jun 5 01:31:50 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC2321F8475 for ; Sun, 5 Jun 2011 01:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDYDJ51mwe8p for ; Sun, 5 Jun 2011 01:31:50 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9E95321F8474 for ; Sun, 5 Jun 2011 01:31:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AAD7039E0F5 for ; Sun, 5 Jun 2011 10:30:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5iM02lFRMVS for ; Sun, 5 Jun 2011 10:30:52 +0200 (CEST) Received: from [192.168.1.16] (unknown [85.102.66.100]) by eikenes.alvestrand.no (Postfix) with ESMTPS id A64B339E04C for ; Sun, 5 Jun 2011 10:30:51 +0200 (CEST) Message-ID: <4DEB3EF7.5050309@alvestrand.no> Date: Sun, 05 Jun 2011 10:31:51 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------000603010305050308010704" Subject: [rtcweb] Fwd: I-D Action: draft-alvestrand-rtcweb-overview-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 08:31:50 -0000 This is a multi-part message in MIME format. --------------000603010305050308010704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is my contribution to the interim meeting on Wednesday, and what I'll expect to be discussing under the heading of "architecture". I will ask the chairs to adopt this as a working group document. Harald -------- Original Message -------- Subject: I-D Action: draft-alvestrand-rtcweb-overview-00.txt Date: Sat, 04 Jun 2011 23:15:16 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Overview: Real Time Protocols for Brower-based Applications Author(s) : Harald T. Alvestrand Filename : draft-alvestrand-rtcweb-overview-00.txt Pages : 14 Date : 2011-06-04 This document gives an overview and context 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, unless the RTCWEB chairs have declared consensus on an item. This document is a work item of the RTCWEB working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-alvestrand-rtcweb-overview-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-alvestrand-rtcweb-overview-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------000603010305050308010704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is my contribution to the interim meeting on Wednesday, and what I'll expect to be discussing under the heading of "architecture".

I will ask the chairs to adopt this as a working group document.

                      Harald

-------- Original Message --------
Subject: I-D Action: draft-alvestrand-rtcweb-overview-00.txt
Date: Sat, 04 Jun 2011 23:15:16 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Overview: Real Time Protocols for Brower-based Applications
	Author(s)       : Harald T. Alvestrand
	Filename        : draft-alvestrand-rtcweb-overview-00.txt
	Pages           : 14
	Date            : 2011-06-04

   This document gives an overview and context of a protocol suite
   intended for use with real-time applications that can be deployed in
   browsers - &quot;real time communication on the Web&quot;.

   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,
   unless the RTCWEB chairs have declared consensus on an item.

   This document is a work item of the RTCWEB working group.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-alvestrand-rtcweb-overview-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-alvestrand-rtcweb-overview-00.txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--------------000603010305050308010704-- From john.lazzaro@gmail.com Sun Jun 5 09:21:13 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF95121F84C5 for ; Sun, 5 Jun 2011 09:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgVCczkyvqz1 for ; Sun, 5 Jun 2011 09:21:12 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCD821F84CB for ; Sun, 5 Jun 2011 09:21:10 -0700 (PDT) Received: by ywp31 with SMTP id 31so1697499ywp.31 for ; Sun, 05 Jun 2011 09:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qfhyu+eIO0LEuoc6FZcvE8V43BE3zqgKGa+A9P5dxPo=; b=Fj6zPoB1t8kiedb5mIELRaoZVusqsDJfEPeNNQ3r8tvTNcvxgh/aZqRfGn44z3b1WI lGKlB1VNrD6nA69NrbEgZcwk3lfkgi+h9zVvBGK9UtUfl0LFtCLsNmlvlbrateNYMYgB +Ynv2uqf2NTtyrIZCa/JxqYtJLyPdeFALI804= 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=F9R2pyHPeIdWoJ/gBbJZCySRO8wIbP9YawFvi3ghjaxx97U/Qn39Ik+UKDHgMlFSBk +tvMIwhi1bkozwK9lJQQTFXj1MUYZlZGfHqm2GQqEALwTXGHQjK1KPo76HjlfEpKRmNS 43jyi1n/nLZqXEly2F8QuovrvbAV+vhYVBacw= MIME-Version: 1.0 Received: by 10.150.243.12 with SMTP id q12mr3512824ybh.78.1307290868007; Sun, 05 Jun 2011 09:21:08 -0700 (PDT) Received: by 10.151.79.7 with HTTP; Sun, 5 Jun 2011 09:21:07 -0700 (PDT) In-Reply-To: <4DEB1A63.9040909@alvestrand.no> References: <4DEB1A63.9040909@alvestrand.no> Date: Sun, 5 Jun 2011 09:21:07 -0700 Message-ID: From: John Lazzaro To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] rtcweb use cases for audio/rtp-midi X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 16:21:13 -0000 On Sat, Jun 4, 2011 at 10:55 PM, Harald Alvestrand wrote: > This (midi in browsers) seems to be closely related to what the W3C "audio" > group is doing. > Are you in contact with them? I've looked at their web pages a few times since they began, but don't tracked it closely. Here's how it relates to audio/rtp-midi. Basically, the session description parameters for audio/rtp-midi lets a session define the renderer (i.e. the way that MIDI should be turned into audio output in the browser) in a extensible way. And so, one could do a short standards-track extension RFC that describes how to say "Here is Javascript that embodies the rendering algorithm. Run it in the browser using the W3C audio group tools for sending audio samples to the client output". Or an equivalent for technologies like NaCl, for situations where Javascript is too slow. This approach is analogous to dispensing with the native voice codec for telephony, and instead send along the voice decoding algorithm in Javascript to be run in the browser. With the same advantages and disadvantages, to a first order. The alternative is to build MIDI renderers into the browsers, in the same way we build native voice codecs into browsers. The RTP MIDI RFC describes how to specify three standardized MIDI renderers, offering increasing levels of programmability and normative output: General MIDI, DLS2, and MPEG 4 Structured Audio. Alternatively, the mechanism allows for extensions to specify other renderers, be they standardized or proprietary, via standards-track extension RFCs. Note that everything I discussed above covers the [2], [3], and [4] use cases in my original post. The [1] use case involves the user on the client manipulating GUI elements (graphical depictions of piano keys, audio volume faders, etc) that are sent as MIDI commands over audio/rtp-midi to a device that the user wishes to control -- anything from a hardware music synthesizer, to a lighting panel, to a PC running emulations of some hardware device. In that case, there's no audio rendering specified. Most of the iOS apps that use RTP MIDI are of this type. -- John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com From csp@csperkins.org Mon Jun 6 01:29:40 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9732211E8093 for ; Mon, 6 Jun 2011 01:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXIXUNucP5MH for ; Mon, 6 Jun 2011 01:29:40 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id D01EA11E808C for ; Mon, 6 Jun 2011 01:29:39 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QTVBq-0006xG-ce for rtcweb@ietf.org; Mon, 06 Jun 2011 08:29:39 +0000 From: Colin Perkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Jun 2011 09:29:38 +0100 References: <20110605213219.10802.7467.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org Message-Id: <8B28FDC9-5A1E-43FA-92B3-85DA5022274A@csperkins.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Fwd: I-D Action: draft-perkins-rtcweb-rtp-usage-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 08:29:40 -0000 This is our contribution to the RTC-Web interim meeting. I'd also like = to ask the chairs to consider this as a working group document. Colin Begin forwarded message: > From: internet-drafts@ietf.org > Date: 5 June 2011 22:32:19 GMT+01:00 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-perkins-rtcweb-rtp-usage-01.txt > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : RTP Requirements for RTC-Web > Author(s) : Colin Perkins > Magnus Westerlund > Joerg Ott > Filename : draft-perkins-rtcweb-rtp-usage-01.txt > Pages : 19 > Date : 2011-06-05 >=20 > This memo discusses use of RTP in the context of the RTC-Web > activity. It discusses important features of RTP that need to be > considered by other parts of the RTC-Web framework, describes which > RTP profile to use in this environment, and outlines what RTP > extensions should be supported. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-perkins-rtcweb-rtp-usage-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-perkins-rtcweb-rtp-usage-01.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --=20 Colin Perkins http://csperkins.org/ From christer.holmberg@ericsson.com Mon Jun 6 01:32:58 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C4F11E80BC for ; Mon, 6 Jun 2011 01:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6nxIhn0bnST for ; Mon, 6 Jun 2011 01:32:58 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B70B711E80D2 for ; Mon, 6 Jun 2011 01:32:57 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-82-4dec90b88e54 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AE.F6.09774.8B09CED4; Mon, 6 Jun 2011 10:32:56 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 6 Jun 2011 10:32:55 +0200 From: Christer Holmberg To: Christer Holmberg , "hardie@ipinfusion.com" , "rtcweb@ietf.org" Date: Mon, 6 Jun 2011 10:32:54 +0200 Thread-Topic: [rtcweb] Contributions for the Interim meeting Thread-Index: AcwJ7uFnZuMR1nYOTAmSGUdSJsBizQFMomxgBUCzUHA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E2E5AFD@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E0F11D5@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E0F11D5@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 08:32:58 -0000 Hi, We haven't submitted a new version of the draft for the intermim meeting, b= ut the current version can be found at: http://tools.ietf.org/id/draft-holmberg-rtcweb-ucreqs-01.txt Regards, Christer=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 10. toukokuuta 2011 17:51 > To: hardie@ipinfusion.com; rtcweb@ietf.org > Subject: Re: [rtcweb] Contributions for the Interim meeting >=20 >=20 > Hi, >=20 > We are willing to continue the work on the use-case &=20 > requirements draft (draft-holmberg-rtcweb-ucreqs), if the=20 > group thinks thinks it's useful. >=20 > Regards, >=20 > Christer >=20 > =20 >=20 > > -----Original Message----- > > From: rtcweb-bounces@ietf.org > > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie > > Sent: 4. toukokuuta 2011 3:08 > > To: rtcweb@ietf.org > > Subject: [rtcweb] Contributions for the Interim meeting > >=20 > > As you will have seen from Cullen's announcement, we are now=20 > > officially a working group and starting to collect data on the=20 > > possible timing of an interim meeting. > >=20 > > For the interim meeting, we want to start work on the chartered=20 > > deliverables. If you are interested in being an editor for=20 > one of the=20 > > working group docs, the chairs would like you to prepare=20 > something for=20 > > the Interim as a draft-00 of your take. If you can, raise=20 > your hand=20 > > on the list to say you're doing so, so as to let others=20 > know to talk=20 > > to you about collaborating. If you are not able to attend=20 > any of the=20 > > times put forward for the interim, you can still volunteer=20 > to edit a=20 > > document--it just means you'll have to have the -00 done=20 > early enough=20 > > for the chairs to find a stuckee for feedback coming in at the=20 > > interim. > >=20 > > regards, > >=20 > > Ted, Cullen, and Magnus > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From jdrosen@jdrosen.net Mon Jun 6 10:27:49 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6841B11E818F for ; Mon, 6 Jun 2011 10:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDudzDr7O5I0 for ; Mon, 6 Jun 2011 10:27:48 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [69.174.48.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7D711E8174 for ; Mon, 6 Jun 2011 10:27:48 -0700 (PDT) Received: from pool-173-63-59-84.nwrknj.fios.verizon.net ([173.63.59.84] helo=[192.168.1.7]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QTdad-0000jR-GE for rtcweb@ietf.org; Mon, 06 Jun 2011 13:27:47 -0400 Message-ID: <4DED0E13.2030208@jdrosen.net> Date: Mon, 06 Jun 2011 13:27:47 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Subject: [rtcweb] Fwd: I-D Action: draft-kaufman-rtcweb-traversal-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 17:27:49 -0000 Hi folks, Matthew and I did a writeup on a proposed model for FW/NAT traversal, emphasizing browser minimalisim. Thanks, Jonathan R. -------- Original Message -------- Subject: I-D Action: draft-kaufman-rtcweb-traversal-00.txt Date: Mon, 06 Jun 2011 10:24:10 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT Traversal Requirements for RTCWEB Author(s) : Matthew Kaufman Jonathan Rosenberg Filename : draft-kaufman-rtcweb-traversal-00.txt Pages : 8 Date : 2011-06-06 This document describes a minimal set of requirements to enable NAT traversal (and satisfy one of the security requirements) for media channels within browser-based real-time communications (RTCWEB). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaufman-rtcweb-traversal-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-kaufman-rtcweb-traversal-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From cbran@cisco.com Mon Jun 6 10:47:11 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC65611E81B3 for ; Mon, 6 Jun 2011 10:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=2.601, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLLQTLRdtwMV for ; Mon, 6 Jun 2011 10:47:10 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id DDA6F11E808E for ; Mon, 6 Jun 2011 10:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cbran@cisco.com; l=5505; q=dns/txt; s=iport; t=1307382430; x=1308592030; h=date:subject:from:to:message-id:mime-version; bh=Vv59irjy5du1E7xgZsJT+x88nMn/WiYiGtxU/+ZpKJ4=; b=DmtAaYxLxdHYhL3ADobclnvhJQUS73bxEJI2TlOp40Wf5k6DAdsOn/pw 13izUrOm+j+Hc5v06aom7bIwLdszAqvF4Jrsz6nS4Lz3y20bTNehxoI0G 58PUL/gfeZM/MyWLUy4MjvyU4hn13d0jtsk3mDPV6Nnon5Pf4apUn8rkw 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJIR7U2rRDoI/2dsb2JhbABTglKiZG53qj+BHZ1yhiEEhnSKBYRRiwk X-IronPort-AV: E=Sophos;i="4.65,327,1304294400"; d="scan'208,217";a="371188093" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 06 Jun 2011 17:47:10 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p56HlANa022069 for ; Mon, 6 Jun 2011 17:47:10 GMT Received: from xmb-sjc-228.amer.cisco.com ([128.107.191.125]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 10:47:09 -0700 Received: from 10.21.88.42 ([10.21.88.42]) by xmb-sjc-228.amer.cisco.com ([128.107.191.125]) with Microsoft Exchange Server HTTP-DAV ; Mon, 6 Jun 2011 17:47:09 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Mon, 06 Jun 2011 10:47:07 -0700 From: cbran To: Message-ID: Thread-Topic: I-D Action: draft-cbran-rtcweb-protocols-00.=?ISO-8859-1?B?dHh0oA==?= Thread-Index: AcwkccC2QsC9HARl60aF70mCr7Zlnw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3390202027_29345251" X-OriginalArrivalTime: 06 Jun 2011 17:47:09.0615 (UTC) FILETIME=[C245A3F0:01CC2471] Subject: [rtcweb] =?iso-8859-1?q?Fwd=3A_I-D_Action=3A_draft-cbran-rtcweb-p?= =?iso-8859-1?q?rotocols-00=2E_txt=A0?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 17:47:12 -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_3390202027_29345251 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, Cullen and I did a write up on the protocol requirements. It more or less attempts to consolidate a lot of the work that has already been done to date. Regards, -Cary Bran -------- Original Message -------- From: internet-drafts@ietf.org=A0 To: i-d-announce@ietf.org=A0 Reply-to: internet-drafts@ietf.org=A0 Subject: I-D Action: draft-cbran-rtcweb-protocols-00.txt=A0 X-RSN: 1/0/935/37055/40429=A0 =A0 A New Internet-Draft is available from the on-line Internet-Drafts directories.=A0 =A0 Title : RTC-Web Communications Protocols=A0 Author(s) : Cary Bran=A0 Cullen Jennings=A0 Filename : draft-cbran-rtcweb-protocols-00.txt=A0 Pages : 21=A0 Date : 2011-06-05=A0 =A0 The real time communications web (RTC-Web) will enable applications=A0 such as web browsers to natively support real time interactive voice=A0 and video. This document outlines the communication protocols for=A0 realizing RTC-Web functionality within applications such as web=A0 browsers. In addition to communications protocols, this document=A0 proposes a set of application programming interface requirements for=A0 controlling the protocol stack.=A0 =A0 =A0 A URL for this Internet-Draft is:=A0 http://www.ietf.org/internet-drafts/draft-cbran-rtcweb-protocols-00.txt=A0 =A0 Internet-Drafts are also available by anonymous FTP at:=A0 ftp://ftp.ietf.org/internet-drafts/=A0 =A0 This Internet-Draft can be retrieved at:=A0 ftp://ftp.ietf.org/internet-drafts/draft-cbran-rtcweb-protocols-00.txt=A0 _______________________________________________=A0 I-D-Announce mailing list=A0 I-D-Announce@ietf.org=A0 https://www.ietf.org/mailman/listinfo/i-d-announce=A0 Internet-Draft directories: http://www.ietf.org/shadow.html=A0 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=A0 --B_3390202027_29345251 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Fwd: I-D Action: draft-cbran-rtcweb-protocols-00.txt=A0 Hi,

Cullen and I did a write up on the protocol requirements.  It more or = less attempts to consolidate a lot of the work that has already been done to= date.

Regards,

-Cary Bran



-------- Original Messag= e --------
From: internet-drafts@ietf.org=A0
To: i-d-announce@ietf.org=A0
Reply-to: internet-drafts@ietf.org=A0<= BR> Subject: I-D Action: draft-cbran-rtcweb-protocols-00.txt=A0
X-RSN: 1/0/935/37055/40429=A0
=A0
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.=A0
=A0
Title           : RTC-Web= Communications Protocols=A0
Author(s)       : Cary Bran=A0
 Cullen Jennings=A0
Filename        : draft-cbran-rtcweb-pro= tocols-00.txt=A0
Pages           : 21=A0
Date            : 20= 11-06-05=A0
=A0
 The real time communications web (RTC-Web) will enable applications=A0<= BR>  such as web browsers to natively support real time interactive voice=A0=
 and video.  This document outlines the communication protocols f= or=A0
 realizing RTC-Web functionality within applications such as web=A0
 browsers.  In addition to communications protocols, this documen= t=A0
 proposes a set of application programming interface requirements for=A0=
 controlling the protocol stack.=A0
=A0
=A0
A URL for this Internet-Draft is:=A0
http://www.ietf.org/internet-drafts/draft-cbran-rtcweb-protocols-00.t= xt=A0
=A0
Internet-Drafts are also available by anonymous FTP at:=A0
ftp://ftp.ietf.org/internet-d= rafts/=A0
=A0
This Internet-Draft can be retrieved at:=A0
ftp://ftp.ietf.org/internet-drafts/draft-cbran-rtcweb-protocols-00.txt= =A0
_______________________________________________=A0
I-D-Announce mailing list=A0
I-D-Announce@ietf.org=A0
https://www.ie= tf.org/mailman/listinfo/i-d-announce=A0
Internet-Draft directories: http:= //www.ietf.org/shadow.html=A0
or ftp://ftp.ietf.org/i= etf/1shadow-sites.txt=A0 --B_3390202027_29345251-- From fluffy@cisco.com Tue Jun 7 09:09:36 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFB811E8123 for ; Tue, 7 Jun 2011 09:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJ78YisGlcex for ; Tue, 7 Jun 2011 09:09:34 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1A75911E810C for ; Tue, 7 Jun 2011 09:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1275; q=dns/txt; s=iport; t=1307462972; x=1308672572; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=X7x07Pz/WBIs0otI6lMqCdJP/G6TcV29x5KUPJ0wJcE=; b=grJfExyEnbKsNPtYIJ/ljt9I8btVvdRWG7vqbjNfoK2IQPayv+RQUc6a UxeC1He3fM4I7nvRUfsYgcgHb8v/4816OlLwxSQiGabBDx/n7o0aZfUhj H9+BqjGiUN/vNwWQ/Ll0uATwybFQZhF7kxhW4H8GeqKHntronhmSBX10b o=; X-IronPort-AV: E=Sophos;i="4.65,333,1304294400"; d="scan'208";a="331956383" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2011 16:09:29 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p57G9SAN001969; Tue, 7 Jun 2011 16:09:28 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 10:09:28 -0600 Message-Id: <94E7AE83-80FF-47B9-93EE-8842FCF33B89@cisco.com> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Agenda for tomorrows virtual interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:09:36 -0000 Architecture: 30 minutes draft-alvestrand-rtcweb-overview (Harald covering all drafts - 15 min)=20= draft-cbran-rtcweb-protocols =20 draft-holmberg-rtcweb-ucreqs draft-rosenberg-rtcweb-framework discussion 15 min focus on identifying what are the big architecture decisions that are = needed more than actually debating what they choices we should make. Use Cases & Solution Requirements: 45 minutes draft-holmberg-rtcweb-ucreqs (Christer - 15 min)=20 discussion (30 min) Security: 30 minutes draft-rescorla-rtcweb-security (Rescorla 15 min ) discussion 15 min NAT Traversal: 30 minutes draft-kaufman-rtcweb-traversal (Kaufman 10 min) 20 min discussion RTP Usage: 30 Minutes draft-perkins-rtcweb-rtp-usage (Colin - 15 min )=20 15 min discussion ZRTP=20 draft-johnston-rtcweb-media-privacy (Alan J - 5 min) - focus on topic of are we going to have the "ZRTP or not" debate=20 5 min discussion Non audio/video data: 25 min frame issues (chairs 5 min ) - draft-holmberg-rtcweb-ucreqs=20 - draft-cbran-rtcweb-protocols discussion 20 min=20 * make sure we agree on requirements * are focused on unreliable data ? Any other business: 15 minutes Discussion of when next interim meeting is. 30 minutes reserved for other use From fluffy@cisco.com Tue Jun 7 09:11:55 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBC511E818F for ; Tue, 7 Jun 2011 09:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0jaZonCsQQN for ; Tue, 7 Jun 2011 09:11:54 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 797EE11E8198 for ; Tue, 7 Jun 2011 09:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2044; q=dns/txt; s=iport; t=1307463114; x=1308672714; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=X71JtZsvQI8HQLjP9UtFpdQ57g3IWFyi0MBYdW/K4aU=; b=LnG0hwoCXq3V57utC76tN/yteWv/hjL6e/eg5RtJs+Jq8HhMwJmoCy6t gwWzYtytPLjYe0YntwUcSRL4u8XdGC7CIgEupm5rC+z2+fCcsVjA7hccx zEf9gxSjZ/xd1Wg44TQJMmsaa/9zARvosDup2reUDaSaVGBWYkvG0TejI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0HAIxN7k2rRDoJ/2dsb2JhbAAnDxYDA5d3jih3iRChcIEdkFiNTAKDKAcGgmoEhniKEoRMixg X-IronPort-AV: E=Sophos;i="4.65,333,1304294400"; d="scan'208";a="461235477" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 07 Jun 2011 16:11:53 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p57GBqE1005307 for ; Tue, 7 Jun 2011 16:11:52 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 10:11:52 -0600 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Conference bridge info for tomorrows virtual interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:11:55 -0000 Conference bridge information is=20 Topic: RTC Web WG=20 Date: Wednesday, June 8, 2011=20 Time: 7:30 am, Pacific Daylight Time (San Francisco, GMT-07:00)=20 Meeting Number: 204 987 300=20 Meeting Password: ietf=20 ------------------------------------------------------=20 To start the online meeting=20 -------------------------------------------------------=20 1. Go to = https://cisco.webex.com/ciscosales/j.php?ED=3D166273742&UID=3D482186897&PW= =3DNMTAyNWI0Yzdl&RT=3DMiM0=20 2. Log in to your account.=20 3. Click "Start Now".=20 4. Follow the instructions that appear on your screen.=20 -------------------------------------------------------=20 To join the teleconference only=20 -------------------------------------------------------=20 0. Find a local phone number from = http://cisco.com/en/US/about/doing_business/conferencing/index.html=20 A few numbers are=20 San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330=20 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117=20 India: +91.80.4350.1111 Germany: +49.619.6773.9002=20 Japan: +81.3.5763.9394 China: +86.10.8515.5666=20 1. Dial into Cisco WebEx=20 2. Follow the prompts to enter the Meeting Number (l204 987 300) = followed by the # sign.=20 -------------------------------------------------------=20 For assistance=20 -------------------------------------------------------=20 1. Go to https://cisco.webex.com/ciscosales/mc=20 2. On the left navigation bar, click "Support".=20 To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 = https://cisco.webex.com/ciscosales/j.php?ED=3D166273742&UID=3D482186897&IC= S=3DMS&LD=3D1&RD=3D2&ST=3D1&SHA2=3DIGsAhT8DkosTrdfDP4EqSGFzCAm14Z1H9uq-AYQ= xgv0=3D=20 To check whether you have the appropriate players installed for UCF = (Universal Communications Format) rich media files, go to = https://cisco.webex.com/ciscosales/systemdiagnosis.php=20 If something goes really wrong, SMS my mobile phone at +1 408 421 9990 From likepeng@huawei.com Tue Jun 7 23:03:47 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E78B11E8070 for ; Tue, 7 Jun 2011 23:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEzvMi1xY9IM for ; Tue, 7 Jun 2011 23:03:46 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADE0228011 for ; Tue, 7 Jun 2011 23:03:46 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMG0055QJGJ2R@szxga04-in.huawei.com> for rtcweb@ietf.org; Wed, 08 Jun 2011 14:02:43 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMG00037JGJDD@szxga04-in.huawei.com> for rtcweb@ietf.org; Wed, 08 Jun 2011 14:02:43 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 08 Jun 2011 14:02:37 +0800 Received: from SZXEML506-MBX.china.huawei.com ([169.254.4.112]) by szxeml412-hub.china.huawei.com ([169.254.150.116]) with mapi id 14.01.0270.001; Wed, 08 Jun 2011 14:02:43 +0800 Date: Wed, 08 Jun 2011 06:02:42 +0000 From: Likepeng In-reply-to: X-Originating-IP: [10.70.109.110] To: Cullen Jennings , "rtcweb@ietf.org" Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F22B3145@szxeml506-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [rtcweb] Conference bridge info for tomorrows virtual interim meeting Thread-index: AQHMJS29+jOkLuvrx0WoXsXo76zaaZSy9q/Q X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [rtcweb] Conference bridge info for tomorrows virtual interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 06:03:47 -0000 Hi Cullen, Can you do us a favor to send a link for the audio record after the conference call? It is quite late for me to join this call. I remember that last time for CoRE, Cullen has sent a link for the record of the conference call. And also I see the record for the RTC-Web F2F meeting, it is quite good. Thanks, Kind Regards Kepeng -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Wednesday, June 08, 2011 12:12 AM To: rtcweb@ietf.org Subject: [rtcweb] Conference bridge info for tomorrows virtual interim meeting Conference bridge information is Topic: RTC Web WG Date: Wednesday, June 8, 2011 Time: 7:30 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 204 987 300 Meeting Password: ietf ------------------------------------------------------ To start the online meeting ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=166273742&UID=482186897&PW=NMTAyNWI0Yzdl&RT=MiM0 2. Log in to your account. 3. Click "Start Now". 4. Follow the instructions that appear on your screen. ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 0. Find a local phone number from http://cisco.com/en/US/about/doing_business/conferencing/index.html A few numbers are San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 1. Dial into Cisco WebEx 2. Follow the prompts to enter the Meeting Number (l204 987 300) followed by the # sign. ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click "Support". To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://cisco.webex.com/ciscosales/j.php?ED=166273742&UID=482186897&ICS=MS&LD=1&RD=2&ST=1&SHA2=IGsAhT8DkosTrdfDP4EqSGFzCAm14Z1H9uq-AYQxgv0= To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://cisco.webex.com/ciscosales/systemdiagnosis.php If something goes really wrong, SMS my mobile phone at +1 408 421 9990 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Wed Jun 8 06:34:14 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98C311E80C5 for ; Wed, 8 Jun 2011 06:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XN1-CXkm3oxz for ; Wed, 8 Jun 2011 06:34:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 1E10011E80BB for ; Wed, 8 Jun 2011 06:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=193; q=dns/txt; s=iport; t=1307540054; x=1308749654; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=dfRjeIFdNV64bMWC5DPjGaiWxse1Tnv+fAmDK3Ebdks=; b=Y/8PyIeI3YBE3FUysWFJFYTNS945SLB1si/EYuBda+t5f6WV0uVQed08 05A/9hsYl9CIja790mAHGrdN7bUIfCjqYZErF9gpJlHCEQQZgmYyWg+7d TYZrsrjx0+PhTdoprdIiUzori5Tby77tuWLviCfO++8Xyh5BKmOpC0/Bc A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcHAPZ4702rRDoI/2dsb2JhbABTmASOLXeoSoEdngCGIwSGf4ochE2LHQ X-IronPort-AV: E=Sophos;i="4.65,338,1304294400"; d="scan'208";a="710183482" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 08 Jun 2011 13:34:13 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p58DXrNR026677 for ; Wed, 8 Jun 2011 13:34:13 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 8 Jun 2011 07:34:15 -0600 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Presentations for meeting today X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 13:34:15 -0000 I have been uploading them to the wiki page at http://trac.tools.ietf.org/wg/rtcweb/trac/wiki Scroll to the bottom of that web page and you can find them. Still missing a few ... From igor.faynberg@alcatel-lucent.com Fri Jun 10 15:01:31 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7788211E81D0 for ; Fri, 10 Jun 2011 15:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTMPF+vB-taV for ; Fri, 10 Jun 2011 15:01:29 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id BAE8111E81CD for ; Fri, 10 Jun 2011 15:01:25 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p5AM1OmY024094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 10 Jun 2011 17:01:25 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5AM1OCq029629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Jun 2011 17:01:24 -0500 Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5AM1NXC017463 for ; Fri, 10 Jun 2011 17:01:24 -0500 (CDT) Message-ID: <4DF29433.2080503@alcatel-lucent.com> Date: Fri, 10 Jun 2011 18:01:23 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [rtcweb] How do we implement SIP event subscription in RTCweb? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 22:01:31 -0000 A question. When SIP is implemented in an application within the present RTCweb architecture, how exactly could we use WebSockets for SUBSCRIBE/NOTIFY? It appears to me that the only way to achieve that is to open a persistent connection. Am I right? If so, is it not a problem, given the potential duration of such connections and potential tie-up of network resources? If not, how else could that be done? With many thanks, Igor From juberti@google.com Fri Jun 10 15:29:50 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D84E228003 for ; Fri, 10 Jun 2011 15:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.31 X-Spam-Level: X-Spam-Status: No, score=-104.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYmiClWUiaVi for ; Fri, 10 Jun 2011 15:29:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC2521F85CE for ; Fri, 10 Jun 2011 15:29:49 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p5AMTm2X031765 for ; Fri, 10 Jun 2011 15:29:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307744988; bh=yqFNH0yjY1RqcQp1tJKPwQLZULs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=k8zOq6atXM0Li+DLf9o6noOvIi3LqQq/l1OeTfMSstYRhuH4Wg2odRmo3oQoSHJkH xUSzEAbMHiWiH+c1OVwGg== Received: from iym7 (iym7.prod.google.com [10.241.52.7]) by hpaq13.eem.corp.google.com with ESMTP id p5AMTjLN031485 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 10 Jun 2011 15:29:46 -0700 Received: by iym7 with SMTP id 7so3036064iym.10 for ; Fri, 10 Jun 2011 15:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cstJNIDQSPFgn738JVdAPBHIpLZxya6s+6IyjvctwvY=; b=ZjmKJIwkB7l6F8md/CZDu6fYX7Fm5i2HuOiSpKiIEE083lcsWhBFOfUzJXcKya+GXO syipvNNvZJ+FLDlEuiiA== 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=g37gelzKH4CJioEMIUZ/y4FWN8kkCDi7ZCmUhMDkiYUZX+F8W9TirNaBfxr7a4kaq1 3npLqolaRonY/kEqFK9g== Received: by 10.231.111.209 with SMTP id t17mr2858127ibp.54.1307744985495; Fri, 10 Jun 2011 15:29:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.16.76 with HTTP; Fri, 10 Jun 2011 15:29:24 -0700 (PDT) In-Reply-To: <4DF29433.2080503@alcatel-lucent.com> References: <4DF29433.2080503@alcatel-lucent.com> From: Justin Uberti Date: Fri, 10 Jun 2011 15:29:24 -0700 Message-ID: To: igor.faynberg@alcatel-lucent.com Content-Type: multipart/alternative; boundary=0016e649c74c51394504a5631b45 X-System-Of-Record: true Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How do we implement SIP event subscription in RTCweb? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 22:29:50 -0000 --0016e649c74c51394504a5631b45 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 10, 2011 at 3:01 PM, Igor Faynberg < igor.faynberg@alcatel-lucent.com> wrote: > A question. > > When SIP is implemented in an application within the present RTCweb > architecture, how exactly could we use WebSockets for SUBSCRIBE/NOTIFY? > > It appears to me that the only way to achieve that is to open a persistent > connection. Am I right? > Yes, that is correct. This is how asynchronous web applications work today. > If so, is it not a problem, given the potential duration of such > connections and potential tie-up of network resources? > An unused TCP/WebSockets connection consumes very few resources. > If not, how else could that be done? > > With many thanks, > > Igor > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --0016e649c74c51394504a5631b45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 10, 2011 at 3:01 PM, Igor Fa= ynberg <igor.faynberg@alcatel-lucent.com> wrote:
A question.

When SIP is implemented in an application within the present RTCweb archite= cture, how exactly could we use WebSockets for SUBSCRIBE/NOTIFY?

It appears to me that the only way to achieve that is to open a persistent = connection. =C2=A0Am I right?

Yes, tha= t is correct. This is how asynchronous web applications work today.
=C2=A0
If so, is it not a problem, given the potential duration of such connection= s and potential tie-up of network resources?

An unused TCP/WebSockets connection consumes very few resources.


If not, how else could that be done?

With many thanks,

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

--0016e649c74c51394504a5631b45-- From Ranjit.Avasarala@Polycom.com Sat Jun 11 02:09:48 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5298011E808F for ; Sat, 11 Jun 2011 02:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+D1lmfQGRgH for ; Sat, 11 Jun 2011 02:09:47 -0700 (PDT) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 530E311E8086 for ; Sat, 11 Jun 2011 02:09:46 -0700 (PDT) Received: from Hkgmboxprd01.polycom.com ([fe80::7d4e:b35f:33e1:6ae3]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Sat, 11 Jun 2011 17:09:45 +0800 From: "Avasarala, Ranjit" To: "igor.faynberg@alcatel-lucent.com" , "rtcweb@ietf.org" Date: Sat, 11 Jun 2011 17:09:41 +0800 Thread-Topic: [rtcweb] How do we implement SIP event subscription in RTCweb? Thread-Index: AcwnuzL55swlb1JZSV+LMoWY1VY3qQAW/YOQ Message-ID: <9F9278CB1892FB48BF35CB5CC3992478A5325210E7@HKGMBOXPRD01.polycom.com> References: <4DF29433.2080503@alcatel-lucent.com> In-Reply-To: <4DF29433.2080503@alcatel-lucent.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: [rtcweb] How do we implement SIP event subscription in RTCweb? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 09:09:48 -0000 Hi Any idea how the initial SIP signaling would take place between an RTC web = application and SIP server? Regards Ranjit -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Igor Faynberg Sent: Saturday, June 11, 2011 3:31 AM To: rtcweb@ietf.org Subject: [rtcweb] How do we implement SIP event subscription in RTCweb? A question. When SIP is implemented in an application within the present RTCweb=20 architecture, how exactly could we use WebSockets for SUBSCRIBE/NOTIFY? It appears to me that the only way to achieve that is to open a=20 persistent connection. Am I right?=20 If so, is it not a problem, given the potential duration of such=20 connections and potential tie-up of network resources? If not, how else could that be done? With many thanks, Igor _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Sat Jun 11 13:43:11 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A131F0C49 for ; Sat, 11 Jun 2011 13:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj7BgrGCLutl for ; Sat, 11 Jun 2011 13:43:10 -0700 (PDT) Received: from blu0-omc3-s20.blu0.hotmail.com (blu0-omc3-s20.blu0.hotmail.com [65.55.116.95]) by ietfa.amsl.com (Postfix) with ESMTP id 397121F0C43 for ; Sat, 11 Jun 2011 13:43:10 -0700 (PDT) Received: from BLU152-W6 ([65.55.116.74]) by blu0-omc3-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 Jun 2011 13:43:09 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_d0bdc94c-8c8c-4c19-9c95-08a276807331_" X-Originating-IP: [72.11.69.66] From: Bernard Aboba To: Date: Sat, 11 Jun 2011 13:43:08 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jun 2011 20:43:09.0751 (UTC) FILETIME=[2CAB4470:01CC2878] Subject: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 20:43:11 -0000 --_d0bdc94c-8c8c-4c19-9c95-08a276807331_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-kaufman-rtcweb-traversal Overall=2C a very good document.=20 Comments below: Section 2.2. Hampers Innovation One of the benefits of ICE is that it allows local implementation flexibility in the way candidates are gathered=2C offered and prioritized. However=2C once ICE is baked into the browser=2C it is no longer possible for that innovation to take place - or at least=2C it leaves the hands of the voice application providers. To date=2C there has been variability in this aspect of implementation=2C with different providers tuning it to tweak their needs and deployments. [BA] It might be pointed out this flexibility has already proven useful to enable support for HTTP failover as well as in implementations of ICE supporting IPV6. Given the wide variety of IPv6 deployments in=20 progress=2C consideration experimentation and tweaking has been required=20 to handle the wide variety of conditions that can be experienced (e.g. IPv6 tunnels of various flavors=2C network devices or services=20 with partial or no IPv6 support=2C missing IPv6 routes=2C NAT 64=2C etc.).= =20 2.3. Unneccesary Cost in some Cases There is a broad array of use cases for VoIP. It is used for everything from consumer Internet services (like Skype) to small business phone systems. Though clearly global consumer Internet services require the kind of traversal technology provided by full ICE=2C it is not needed in other cases. One such use case is=2C in fact= =2C enterprise telephony=2C where users make calls within the confines of their corporate network=2C and remote access is supported through VPN. Today=2C VoIP endpoints in these environments do not generally use ICE. [BA] ICE has in fact proven quite popular in enterprise deployments=20 involving remote users (e.g. mobile devices)=2C so I'd reword the last sentence to say "For example=2C in an enterprise deployment where users make calls primarily within a corporate network without deployed=20 NATs=2C VoIP endpoints will not require ICE."=20 3. Proposed Model For security purposes=2C the browser will refuse to send=2C or accept=2C media to or from a peer to which a STUN transaction has not completed successfully. This ensures that the browser cannot be used as a DoS tool to launch a voice hammer attack. [BA] This condition is necessary but not sufficient. For example=2C it would not make sense for the browser to authorize media to be sent to an endpoint which completed a STUN transaction without ICE extensions. If this were allowed=2C then it would be possible to DoS a STUN server.=20 With this model=2C there is now a great deal of flexibility in how NAT traversal can be done. Some of the models which can now be supported are: ICE in Javascript: A full ICE implementation is possible in Javascript itself. Because the implementation resides in Javasript=2C it is trivially changed at any time. Server-Based ICE: A full ICE implementation can execute in the server=2C using remote-control commands to inform the browser to send STUN transactions=2C and passing the results from the browser back to the server. In essence - MGCP for ICE. STUN-Only: For deployments where the peer is always publically reachable from clients - such as enterprises or PSTN termination services - the Javascript can do a single STUN transaction to create a permission in the browser=2C and then proceed to send media. Non-ICE: Protocols similar to ICE=2C but not otherwise compliant=2C can also be implemented. Negotiation of which NAT traversal mechanism is needed=2C is done by the application outside of the browser. [BA] There are some interoperability implications to these approaches that need to be explored. For example=2C the ICE Javascript approach should enable interoperability between different browsers attached to the same service. However=2C it is not clear to me that this will necessarily work for=20 inter-service communication (e.g. the clients could have=20 incompatible ICE Javascript libraries).=20 4.4. Receipt of Response Upon receipt of a valid STUN transaction response from the responding client=2C the initiating client MUST call a callback function that delivers the attribute/value pairs received in the response=2C one of which is the reflexive address. The response MUST be ignored if the receivedSocketAddress does not match the socket address to which the matching transaction ID was sent=2C as per ICE 7.1.3.2. Upon receipt of a valid response the client also adds the now-verified address to the Transmit Whitelist=2C a list of socket addresses to which sending of media is now permissible. =20 [BA] Does it really make sense to add the verified address of a responding client to the transmit whitelist=2C even if the nominated flag is not set in the response? = --_d0bdc94c-8c8c-4c19-9c95-08a276807331_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-kaufman-rtcweb-traversal

Overall=2C a very good docu= ment.

Comments below:

Section 2.2. =3B Hampers Innovatio= n

 =3B =3B One of the benefits of ICE is that it allows loca= l implementation
 =3B =3B flexibility in the way candidates are = gathered=2C offered and
 =3B =3B prioritized. =3B However=2C= once ICE is baked into the browser=2C it is no
 =3B =3B longer = possible for that innovation to take place - or at least=2C it
 =3B&= nbsp=3B leaves the hands of the voice application providers. =3B To dat= e=2C there
 =3B =3B has been variability in this aspect of imple= mentation=2C with different
 =3B =3B providers tuning it to twea= k their needs and deployments.

[BA] It might be pointed out this fle= xibility has already proven useful
to enable support for HTTP failover a= s well as in implementations of
ICE supporting IPV6. =3B Given the w= ide variety of IPv6 deployments in
progress=2C consideration experiment= ation and tweaking has been required
to handle the wide variety of cond= itions that can be experienced
(e.g. IPv6 tunnels of various flavors=2C = network devices or services
with partial or no IPv6 support=2C =3B = missing IPv6 routes=2C NAT 64=2C etc.).

2.3. =3B Unneccesary Co= st in some Cases

 =3B =3B There is a broad array of use case= s for VoIP. =3B It is used for
 =3B =3B everything from cons= umer Internet services (like Skype) to small
 =3B =3B business p= hone systems. =3B Though clearly global consumer Internet
 =3B&n= bsp=3B services require the kind of traversal technology provided by full =3B =3B ICE=2C it is not needed in other cases. =3B One such= use case is=2C in fact=2C
 =3B =3B enterprise telephony=2C wher= e users make calls within the confines of
 =3B =3B their corpora= te network=2C and remote access is supported through VPN.
 =3B = =3B Today=2C VoIP endpoints in these environments do not generally use ICE.=

[BA] ICE has in fact proven quite popular in enterprise deployments=
involving remote users (e.g. mobile devices)=2C so I'd reword the
l= ast sentence to say "For example=2C in an enterprise deployment where
us= ers make calls primarily within a corporate network without deployed
NA= Ts=2C VoIP endpoints will not require ICE."

3. =3B Proposed Mod= el

 =3B =3B For security purposes=2C the browser will refuse= to send=2C or accept=2C
 =3B =3B media to or from a peer to whi= ch a STUN transaction has not completed
 =3B =3B successfully.&n= bsp=3B This ensures that the browser cannot be used as a DoS
 =3B&nb= sp=3B tool to launch a voice hammer attack.

[BA] This condition is n= ecessary but not sufficient. =3B For example=2C it
would not make se= nse for the browser to authorize media to be sent to
an endpoint which c= ompleted a STUN transaction without ICE extensions.
If this were allowed= =2C then it would be possible to DoS a STUN server.

 =3B = =3B With this model=2C there is now a great deal of flexibility in how NAT<= br> =3B =3B traversal can be done. =3B Some of the models which= can now be supported
 =3B =3B are:

 =3B =3B ICE = in Javascript: =3B A full ICE implementation is possible in
 =3B=  =3B =3B =3B =3B Javascript itself. =3B Because the imp= lementation resides in
 =3B =3B =3B =3B =3B Javasrip= t=2C it is trivially changed at any time.

 =3B =3B Server-Ba= sed ICE: =3B A full ICE implementation can execute in the
 =3B&n= bsp=3B =3B =3B =3B server=2C using remote-control commands to i= nform the browser to
 =3B =3B =3B =3B =3B send STUN = transactions=2C and passing the results from the browser
 =3B = =3B =3B =3B =3B back to the server. =3B In essence - MGCP f= or ICE.

 =3B =3B STUN-Only: =3B For deployments where th= e peer is always publically
 =3B =3B =3B =3B =3B rea= chable from clients - such as enterprises or PSTN termination
 =3B&n= bsp=3B =3B =3B =3B services - the Javascript can do a single ST= UN transaction to
 =3B =3B =3B =3B =3B create a perm= ission in the browser=2C and then proceed to send
 =3B =3B = =3B =3B =3B media.

 =3B =3B Non-ICE: =3B Protoco= ls similar to ICE=2C but not otherwise compliant=2C can
 =3B =3B=  =3B =3B =3B also be implemented. =3B Negotiation of which = NAT traversal mechanism
 =3B =3B =3B =3B =3B is need= ed=2C is done by the application outside of the browser.

[BA] There = are some interoperability implications to these
approaches that need to = be explored. =3B For example=2C the ICE
Javascript approach should e= nable interoperability
between different browsers attached to the same s= ervice. =3B However=2C
it is not clear to me that this will necessar= ily work for
inter-service communication (e.g. the clients could have <= br>incompatible ICE Javascript libraries).

4.4. =3B Receipt of = Response

 =3B =3B Upon receipt of a valid STUN transaction r= esponse from the responding
 =3B =3B client=2C the initiating cl= ient MUST call a callback function that
 =3B =3B delivers the at= tribute/value pairs received in the response=2C one of
 =3B =3B = which is the reflexive address. =3B The response MUST be ignored if the=
 =3B =3B receivedSocketAddress does not match the socket addres= s to which the
 =3B =3B matching transaction ID was sent=2C as p= er ICE 7.1.3.2. =3B Upon receipt
 =3B =3B of a valid respons= e the client also adds the now-verified address to
 =3B =3B the = Transmit Whitelist=2C a list of socket addresses to which sending
 = =3B =3B of media is now permissible.  =3B

[BA] Does it reall= y make sense to add the verified address of a responding
client to the t= ransmit whitelist=2C even if the nominated flag is not
set in the respon= se?

= --_d0bdc94c-8c8c-4c19-9c95-08a276807331_-- From matthew.kaufman@skype.net Sat Jun 11 13:50:38 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860121F0C49 for ; Sat, 11 Jun 2011 13:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUfY5gggk2mi for ; Sat, 11 Jun 2011 13:50:37 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4611F0C43 for ; Sat, 11 Jun 2011 13:50:37 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id E8C0A170B; Sat, 11 Jun 2011 22:50:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :content-transfer-encoding:from:content-type:message-id:date:cc :to:mime-version; s=mx; bh=RPFRq/stDolICxXBvoLtPcF7X0Y=; b=tcG0m r7pEdGHDOKlvOTe900F9prfnms9ckuf8qhsdeNgyXgcSpDJmUdHBWY4oODhd9QSH b0ShAlQAr3TNEvzBIbB4f0rCElTgoPCWG8/YmXGwecvgLW4RA6N0zq00boPw5zrg nL+FtEA5nxvgoxP42Cjk2EPJUJoJ321Lgr1GpI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject :content-transfer-encoding:from:content-type:message-id:date:cc :to:mime-version; q=dns; s=mx; b=d70LFyGmeu1FDKqQNcgYm8/QVaFbkNR XaaHcxCuRTfKHbKS3wz8B1rG3uO0pS/rGW1RI3TAdqYOzAWfC41iWDdxSQy+hiBr AMgAfVQwgTMeiWnmc7+eReYHbFziutg9/XYrNp5Um46XJGGWhdwL9wti48f3CJsw l5nez9RR56hI= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id E3FFE7F6; Sat, 11 Jun 2011 22:50:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id BC0071672682; Sat, 11 Jun 2011 22:50:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNZclTzToTmi; Sat, 11 Jun 2011 22:50:33 +0200 (CEST) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id EC94C350759C; Sat, 11 Jun 2011 22:50:33 +0200 (CEST) Content-Transfer-Encoding: 7bit From: Matthew Kaufman Content-Type: multipart/alternative; boundary=Apple-Mail-63-953173769 Message-Id: <9CBFB024-BDBD-4E2E-AEF0-400965C4E0BB@skype.net> Date: Sat, 11 Jun 2011 22:50:33 +0200 (CEST) To: Bernard Aboba Mime-Version: 1.0 X-Mailer: Zimbra 6.0.9_GA_2686 (MobileSync - Apple-iPhone3C1/803.148) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 20:50:38 -0000 --Apple-Mail-63-953173769 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 11, 2011, at 1:43 PM, Bernard Aboba wrot= e: >=20 > [BA] This condition is necessary but not sufficient. For example, it > would not make sense for the browser to authorize media to be sent to > an endpoint which completed a STUN transaction without ICE extensions. > If this were allowed, then it would be possible to DoS a STUN server.=20 >=20 This is only true of STUN servers that don't require credentials. If those really exist then yes, requiring at least one reasonable extension= makes sense. >=20 >=20 > [BA] Does it really make sense to add the verified address of a respondin= g > client to the transmit whitelist, even if the nominated flag is not > set in the response? Quite possibly yes, especially for mobility cases, but see above that sone = extension or flag might indeed be needed before adding. Thanks for the comments, will review more thoroughly when the plane I'm sit= ting on lands. Matthew Kaufman --Apple-Mail-63-953173769 Content-Transfer-Encoding: base64 Content-Type: text/html; charset=utf-8 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+T24g SnVuIDExLCAyMDExLCBhdCAxOjQzIFBNLCBCZXJuYXJkIEFib2JhICZsdDs8YSBocmVmPSJtYWls dG86YmVybmFyZF9hYm9iYUBob3RtYWlsLmNvbSI+YmVybmFyZF9hYm9iYUBob3RtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxicj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgY29sb3I9IiMw MDIzQTMiPjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBjb2xvcj0iIzAwMDAwMCI+PGJy PjwvZm9udD48L2ZvbnQ+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48YnI+W0JB XSBUaGlzIGNvbmRpdGlvbiBpcyBuZWNlc3NhcnkgYnV0IG5vdCBzdWZmaWNpZW50LiZuYnNwOyBG b3IgZXhhbXBsZSwgaXQ8YnI+d291bGQgbm90IG1ha2Ugc2Vuc2UgZm9yIHRoZSBicm93c2VyIHRv IGF1dGhvcml6ZSBtZWRpYSB0byBiZSBzZW50IHRvPGJyPmFuIGVuZHBvaW50IHdoaWNoIGNvbXBs ZXRlZCBhIFNUVU4gdHJhbnNhY3Rpb24gd2l0aG91dCBJQ0UgZXh0ZW5zaW9ucy48YnI+SWYgdGhp cyB3ZXJlIGFsbG93ZWQsIHRoZW4gaXQgd291bGQgYmUgcG9zc2libGUgdG8gRG9TIGEgU1RVTiBz ZXJ2ZXIuIDxicj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PlRoaXMgaXMg b25seSB0cnVlIG9mIFNUVU4gc2VydmVycyB0aGF0IGRvbid0IHJlcXVpcmUgY3JlZGVudGlhbHMu PGRpdj48YnI+PC9kaXY+PGRpdj5JZiB0aG9zZSByZWFsbHkgZXhpc3QgdGhlbiB5ZXMsIHJlcXVp cmluZyBhdCBsZWFzdCBvbmUgcmVhc29uYWJsZSBleHRlbnNpb24gbWFrZXMgc2Vuc2UuPC9kaXY+ PGRpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2Pjxicj48YnI+W0JBXSBEb2VzIGl0IHJl YWxseSBtYWtlIHNlbnNlIHRvIGFkZCB0aGUgdmVyaWZpZWQgYWRkcmVzcyBvZiBhIHJlc3BvbmRp bmc8YnI+Y2xpZW50IHRvIHRoZSB0cmFuc21pdCB3aGl0ZWxpc3QsIGV2ZW4gaWYgdGhlIG5vbWlu YXRlZCBmbGFnIGlzIG5vdDxicj5zZXQgaW4gdGhlIHJlc3BvbnNlPzxicj48L2Rpdj48L2Jsb2Nr cXVvdGU+PGRpdj48YnI+PC9kaXY+UXVpdGUgcG9zc2libHkgeWVzLCBlc3BlY2lhbGx5IGZvciBt b2JpbGl0eSBjYXNlcywgYnV0IHNlZSBhYm92ZSB0aGF0IHNvbmUgZXh0ZW5zaW9uIG9yIGZsYWcg bWlnaHQgaW5kZWVkIGJlIG5lZWRlZCBiZWZvcmUgYWRkaW5nLjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+VGhhbmtzIGZvciB0aGUgY29tbWVudHMsIHdpbGwgcmV2aWV3IG1vcmUgdGhvcm91Z2hs eSB3aGVuIHRoZSBwbGFuZSBJJ20gc2l0dGluZyBvbiBsYW5kcy48L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2Pk1hdHRoZXcgS2F1Zm1hbjwvZGl2PjwvYm9keT48L2h0bWw+ --Apple-Mail-63-953173769-- From harald@alvestrand.no Sat Jun 11 14:23:08 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD94B1F0C49 for ; Sat, 11 Jun 2011 14:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+SLB-Morl5W for ; Sat, 11 Jun 2011 14:23:08 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C78251F0C3A for ; Sat, 11 Jun 2011 14:23:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4359C39E0FD; Sat, 11 Jun 2011 23:22:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQeAdCIfNkpq; Sat, 11 Jun 2011 23:22:08 +0200 (CEST) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C696139E0BF; Sat, 11 Jun 2011 23:22:08 +0200 (CEST) Message-ID: <4DF3DCB8.9090805@alvestrand.no> Date: Sat, 11 Jun 2011 23:23:04 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090607000706010609080805" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 21:23:09 -0000 This is a multi-part message in MIME format. --------------090607000706010609080805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard, at last week's call, the question was raised on whether it's actually possible to implement ICE in javascript according to the described model - the Javascript event loop has certain problems with precise timing. The upshoot seemed to be that we'd like to see a demonstration that it's possible to create an ICE-interoperable implementation using Javascript as described before attempting to go further down this path. Some other comments below. On 06/11/2011 10:43 PM, Bernard Aboba wrote: > Review of draft-kaufman-rtcweb-traversal > > Overall, a very good document. > > Comments below: > > Section 2.2. Hampers Innovation > > One of the benefits of ICE is that it allows local implementation > flexibility in the way candidates are gathered, offered and > prioritized. However, once ICE is baked into the browser, it is no > longer possible for that innovation to take place - or at least, it > leaves the hands of the voice application providers. To date, there > has been variability in this aspect of implementation, with different > providers tuning it to tweak their needs and deployments. > > [BA] It might be pointed out this flexibility has already proven useful > to enable support for HTTP failover as well as in implementations of > ICE supporting IPV6. Given the wide variety of IPv6 deployments in > progress, consideration experimentation and tweaking has been required > to handle the wide variety of conditions that can be experienced > (e.g. IPv6 tunnels of various flavors, network devices or services > with partial or no IPv6 support, missing IPv6 routes, NAT 64, etc.). This is good information, and it seems reasonable that it should lead to a rework of ICE based on this experience. Is it written up anywhere you can share? > ICE in Javascript: A full ICE implementation is possible in > Javascript itself. Because the implementation resides in > Javasript, it is trivially changed at any time. > > Server-Based ICE: A full ICE implementation can execute in the > server, using remote-control commands to inform the browser to > send STUN transactions, and passing the results from the browser > back to the server. In essence - MGCP for ICE. > > STUN-Only: For deployments where the peer is always publically > reachable from clients - such as enterprises or PSTN termination > services - the Javascript can do a single STUN transaction to > create a permission in the browser, and then proceed to send > media. > > Non-ICE: Protocols similar to ICE, but not otherwise compliant, can > also be implemented. Negotiation of which NAT traversal mechanism > is needed, is done by the application outside of the browser. > > [BA] There are some interoperability implications to these > approaches that need to be explored. For example, the ICE > Javascript approach should enable interoperability > between different browsers attached to the same service. However, > it is not clear to me that this will necessarily work for > inter-service communication (e.g. the clients could have > incompatible ICE Javascript libraries). If both javascript libraries implement ICE, they should by definition be interoperable - I am more worried about the case where one application supports ICE and another application supports some ICE-like mechanism. --------------090607000706010609080805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard,

at last week's call, the question was raised on whether it's actually possible to implement ICE in javascript according to the described model - the Javascript event loop has certain problems with precise timing.

The upshoot seemed to be that we'd like to see a demonstration that it's possible to create an ICE-interoperable implementation using Javascript as described before attempting to go further down this path.

Some other comments below.

On 06/11/2011 10:43 PM, Bernard Aboba wrote:
Review of draft-kaufman-rtcweb-traversal

Overall, a very good document.

Comments below:

Section 2.2.  Hampers Innovation

   One of the benefits of ICE is that it allows local implementation
   flexibility in the way candidates are gathered, offered and
   prioritized.  However, once ICE is baked into the browser, it is no
   longer possible for that innovation to take place - or at least, it
   leaves the hands of the voice application providers.  To date, there
   has been variability in this aspect of implementation, with different
   providers tuning it to tweak their needs and deployments.

[BA] It might be pointed out this flexibility has already proven useful
to enable support for HTTP failover as well as in implementations of
ICE supporting IPV6.  Given the wide variety of IPv6 deployments in
progress, consideration experimentation and tweaking has been required
to handle the wide variety of conditions that can be experienced
(e.g. IPv6 tunnels of various flavors, network devices or services
with partial or no IPv6 support,  missing IPv6 routes, NAT 64, etc.).

This is good information, and it seems reasonable that it should lead to a rework of ICE based on this experience. Is it written up anywhere you can share?

   ICE in Javascript:  A full ICE implementation is possible in
      Javascript itself.  Because the implementation resides in
      Javasript, it is trivially changed at any time.

   Server-Based ICE:  A full ICE implementation can execute in the
      server, using remote-control commands to inform the browser to
      send STUN transactions, and passing the results from the browser
      back to the server.  In essence - MGCP for ICE.

   STUN-Only:  For deployments where the peer is always publically
      reachable from clients - such as enterprises or PSTN termination
      services - the Javascript can do a single STUN transaction to
      create a permission in the browser, and then proceed to send
      media.

   Non-ICE:  Protocols similar to ICE, but not otherwise compliant, can
      also be implemented.  Negotiation of which NAT traversal mechanism
      is needed, is done by the application outside of the browser.

[BA] There are some interoperability implications to these
approaches that need to be explored.  For example, the ICE
Javascript approach should enable interoperability
between different browsers attached to the same service.  However,
it is not clear to me that this will necessarily work for
inter-service communication (e.g. the clients could have
incompatible ICE Javascript libraries).

If both javascript libraries implement ICE, they should by definition be interoperable - I am more worried about the case where one application supports ICE and another application supports some ICE-like mechanism.


--------------090607000706010609080805-- From bernard_aboba@hotmail.com Sat Jun 11 14:40:22 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9E11F0C49 for ; Sat, 11 Jun 2011 14:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3kSRW5X6Zwm for ; Sat, 11 Jun 2011 14:40:21 -0700 (PDT) Received: from blu0-omc3-s1.blu0.hotmail.com (blu0-omc3-s1.blu0.hotmail.com [65.55.116.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7361D1F0C3A for ; Sat, 11 Jun 2011 14:40:21 -0700 (PDT) Received: from BLU152-W44 ([65.55.116.74]) by blu0-omc3-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 Jun 2011 14:40:21 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_ae8a1e60-1663-4a6e-9328-1e3370732de4_" X-Originating-IP: [72.11.69.66] From: Bernard Aboba To: Date: Sat, 11 Jun 2011 14:40:20 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jun 2011 21:40:21.0260 (UTC) FILETIME=[2A01FCC0:01CC2880] Subject: [rtcweb] Review of draft-rescorla-rtcweb-security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 21:40:22 -0000 --_ae8a1e60-1663-4a6e-9328-1e3370732de4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-rescorla-rtcweb-security Overall=2C a reasonable -00 that needs expanded coverage in a number of are= as before it can be considered for adoption as a WG document.=20 Comments below:=20 The Real-Time Communications on the Web (RTC-Web) working group is tasked with standardizing protocols for real-time communications between Web browsers. The two major use cases for RTC-Web technology are real-time audio and/or video calls and direct data transfer. [BA] Today=2C Web-based realtime communications technology is widely deployed (albeit proprietary)=2C and one of the major use cases is Web conferencing (e.g. WebEx). So this is probably deserving of consideration although this may not be convenient given the discussion that follows.=20 More subtly=2C if the exposed APIs allow the server to instruct the browser to send arbitrary content=2C then they can be used to bypass firewalls or mount denial of service attacks. Any successful system will need to be resistant to this and other attacks. [BA] This would include things like denial of service attacks on public service answering points (PSAPs).=20 Conventionally=2C we refer to either WEB ATTACKERS=2C who are able to induce you to visit their sites but do not control the network=2C and NETWORK ATTACKERS=2C who are able to control your network. Network attackers correspond to the [RFC3552] "Internet Threat Model". In general=2C it is desirable to build a system which is secure against both kinds of attackers=2C but realistically many sites do not run HTTPS [RFC2818] and so our ability to defend against network attackers is necessarily somewhat limited. Most of the rest of this section is devoted to web attackers=2C with the assumption that protection against network attackers is provided by running HTTPS. [BA] I'd suggest that the issue of "privacy leakage" also be mentioned=2C e= ven though this is a much nastier problem that is largely outside the scope of the RTCWEB WG: http://www.w3.org/2011/track-privacy/slides/wills.pdf The issue of privacy may also be relevant in other contexts such as the potential creation of a Javascript API to return the interface addresse= s (e.g. for use by ICE). My take is that the document should take a position on th= is (e.g. that such an extension would be OK or not).=20 3.3. Bypassing SOP: CORS=2C WebSockets=2C and consent to communicate While SOP serves an important security function=2C it also makes it inconvenient to write certain classes of applications. In particular=2C mash-ups=2C in which a script from origin A uses resources from origin B=2C can only be achieved via a certain amount of hackery. The W3C Cross-Origin Resource Sharing (CORS) spec [CORS] is a response to this demand. =20 [BA] It probably should be noted that there are other ways around the same ORIGIN policy that are widely used today. These include Javascript libraries as well as general-purpose=20 BOSH connection managers. 4.1. Access to Local Devices Arguably=2C origin is not fine-grained enough. Consider the situation where Alice visits a site and authorizes it to make a single call. If consent is expressed solely in terms of origin=2C then at any future visit to that site (including one induced via mash-up or ad network)=2C the site can bug Alice's computer. While in principle Alice could grant and then revoke the privilege=2C in practice privileges accumulate=3B if we are concerned about this attack=2C something else is needed. There are a number of potential countermeasures to this sort of issue. [BA] Not only can they bug Alice's computer=2C but the site could also do other things like making a bogus emergency call.=20 4.2.2. Masking Once consent is verified=2C there still is some concern about misinterpretation attacks as described by Huang et al.[huang-w2sp]. As long as communication is limited to UDP=2C then this risk is probably limited=2C thus masking is not required for UDP. =20 [BA] Are you saying that the browser should be able to send arbitrary UDP traffic once "consent" is granted? =20 4.2.3. Backward Compatibility A requirement to use ICE limits compatibility with legacy non-ICE clients. It seems unsafe to completely remove the requirement for some check=2C but it might be possible to merely require a one-sided check where the legacy client was a STUN responder. It's unclear whether that is in fact simpler than doing ICE-Lite. [BA] This section needs to be expanded to provide more in depth discussion of backward compatibility issues and potential approaches=2C which might include: a. RTCP-based approaches (e.g. no ICE). =20 b. STUN without ICE extensions Since each of these approaches has weaknesses=2C it would be useful to make clear what attacks can be launched against them and what mitigating measures might be available=2C along with a discussion of their effectiveness and an overall recommendation. 4.3. Communications Security Technology for providing this service (for instance=2C DTLS [RFC4347] and DTLS-SRTP [RFC5763]) is well understood. However=2C we must examine this technology to the RTC-Web context=2C where the threat model is somewhat different. [BA] As suggested in draft-johnston-rtcweb-media-privacy=2C the threat model is not the only potential issue in the RTCWEB context -- there is also the problem of dependency on (non-standardized) signaling.=20 = --_ae8a1e60-1663-4a6e-9328-1e3370732de4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-rescorla-rtcweb-security

Overall=2C a reasonable -00= that needs expanded coverage in a number of areas before it
can be cons= idered for adoption as a WG document.

Comments below:

 = =3B =3B The Real-Time Communications on the Web (RTC-Web) working group= is
 =3B =3B tasked with standardizing protocols for real-time c= ommunications
 =3B =3B between Web browsers. =3B The two maj= or use cases for RTC-Web technology
 =3B =3B are real-time audio= and/or video calls and direct data transfer.

[BA] Today=2C Web-base= d realtime communications technology is widely
deployed (albeit propriet= ary)=2C and one of the major use cases is
Web conferencing (e.g. WebEx).=  =3B So this is probably deserving
of consideration although this ma= y not be convenient given the
discussion that follows.


 = =3B =3B More subtly=2C if the
 =3B =3B exposed APIs allow th= e server to instruct the browser to send
 =3B =3B arbitrary cont= ent=2C then they can be used to bypass firewalls or mount
 =3B = =3B denial of service attacks. =3B Any successful system will need to b= e
 =3B =3B resistant to this and other attacks.

[BA] This= would include things like denial of service attacks on
public service a= nswering points (PSAPs).

 =3B =3B Conventionally=2C we refe= r to either WEB ATTACKERS=2C who are able to
 =3B =3B induce you= to visit their sites but do not control the network=2C and
 =3B&nbs= p=3B NETWORK ATTACKERS=2C who are able to control your network. =3B Net= work
 =3B =3B attackers correspond to the [RFC3552] "Internet Th= reat Model". =3B In
 =3B =3B general=2C it is desirable to b= uild a system which is secure against
 =3B =3B both kinds of att= ackers=2C but realistically many sites do not run
 =3B =3B HTTPS= [RFC2818] and so our ability to defend against network
 =3B =3B= attackers is necessarily somewhat limited. =3B Most of the rest of thi= s
 =3B =3B section is devoted to web attackers=2C with the assum= ption that
 =3B =3B protection against network attackers is prov= ided by running HTTPS.

[BA] I'd suggest that the issue of "privacy l= eakage" also be mentioned=2C even
though this is a much nastier problem = that is largely outside the scope of
the RTCWEB WG:
http://www.w3.org= /2011/track-privacy/slides/wills.pdf

The issue of privacy may also b= e relevant in other contexts such as
the potential creation of a Javascr= ipt API to return the interface addresses (e.g.
for use by ICE). =3B= My take is that the document should take a position on this
(e.g. that = such an extension would be OK or not).

3.3. =3B Bypassing SOP: = CORS=2C WebSockets=2C and consent to communicate

 =3B =3B Wh= ile SOP serves an important security function=2C it also makes it
 = =3B =3B inconvenient to write certain classes of applications. =3B = In
 =3B =3B particular=2C mash-ups=2C in which a script from ori= gin A uses resources
 =3B =3B from origin B=2C can only be achie= ved via a certain amount of hackery.
 =3B =3B The W3C Cross-Orig= in Resource Sharing (CORS) spec [CORS] is a
 =3B =3B response to= this demand. =3B

[BA] It probably should be noted that there a= re other ways around
the same ORIGIN policy that are widely used today.&= nbsp=3B These
include Javascript libraries as well as general-purpose BOSH connection managers.

4.1. =3B Access to Local Devices
=
 =3B =3B Arguably=2C origin is not fine-grained enough. =3B= Consider the situation
 =3B =3B where Alice visits a site and a= uthorizes it to make a single call.
 =3B =3B If consent is expre= ssed solely in terms of origin=2C then at any future
 =3B =3B vi= sit to that site (including one induced via mash-up or ad network)=2C
&n= bsp=3B =3B the site can bug Alice's computer. =3B While in principl= e Alice could
 =3B =3B grant and then revoke the privilege=2C in= practice privileges
 =3B =3B accumulate=3B if we are concerned = about this attack=2C something else is
 =3B =3B needed. =3B = There are a number of potential countermeasures to this sort
 =3B&nb= sp=3B of issue.

[BA] Not only can they bug Alice's computer=2C but t= he site could also
do other things like making a bogus emergency call. <= br>
4.2.2. =3B Masking

 =3B =3B Once consent is verif= ied=2C there still is some concern about
 =3B =3B misinterpretat= ion attacks as described by Huang et al.[huang-w2sp].
 =3B =3B A= s long as communication is limited to UDP=2C then this risk is
 =3B&= nbsp=3B probably limited=2C thus masking is not required for UDP. =3B <= br>
[BA] Are you saying that the browser should be able to send arbitrar= y
UDP traffic once "consent" is granted? =3B

4.2.3. =3B = Backward Compatibility

 =3B =3B A requirement to use ICE lim= its compatibility with legacy non-ICE
 =3B =3B clients. =3B = It seems unsafe to completely remove the requirement for
 =3B = =3B some check=2C but it might be possible to merely require a one-sided =3B =3B check where the legacy client was a STUN responder. = =3B It's unclear
 =3B =3B whether that is in fact simpler than d= oing ICE-Lite.

[BA] This section needs to be expanded to provide mor= e in depth
discussion of backward compatibility issues and potential app= roaches=2C
which might include:

a. RTCP-based approaches (e.g. no= ICE). =3B
b. STUN without ICE extensions

Since each of thes= e approaches has weaknesses=2C it would be useful to
make clear what att= acks can be launched against them and what
mitigating measures might be = available=2C along with a discussion
of their effectiveness and an overa= ll recommendation.

4.3. =3B Communications Security

 = =3B =3B Technology for providing this
 =3B =3B service (for = instance=2C DTLS [RFC4347] and DTLS-SRTP [RFC5763]) is
 =3B =3B = well understood. =3B However=2C we must examine this technology to the<= br> =3B =3B RTC-Web context=2C where the threat model is somewhat d= ifferent.

[BA] As suggested in draft-johnston-rtcweb-media-privacy= =2C the threat
model is not the only potential issue in the RTCWEB conte= xt -- there
is also the problem of dependency on (non-standardized) sign= aling.





= --_ae8a1e60-1663-4a6e-9328-1e3370732de4_-- From bernard_aboba@hotmail.com Sat Jun 11 15:09:30 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1905521F8437 for ; Sat, 11 Jun 2011 15:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LV9pzFS+2LZQ for ; Sat, 11 Jun 2011 15:09:29 -0700 (PDT) Received: from blu0-omc1-s23.blu0.hotmail.com (blu0-omc1-s23.blu0.hotmail.com [65.55.116.34]) by ietfa.amsl.com (Postfix) with ESMTP id BEF4E21F8436 for ; Sat, 11 Jun 2011 15:09:28 -0700 (PDT) Received: from BLU152-W63 ([65.55.116.9]) by blu0-omc1-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 Jun 2011 15:09:28 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_51b0a978-7c3e-4e7e-9951-e8bdb41cb409_" X-Originating-IP: [72.11.69.66] From: Bernard Aboba To: Date: Sat, 11 Jun 2011 15:09:27 -0700 Importance: Normal In-Reply-To: <4DF3DCB8.9090805@alvestrand.no> References: , <4DF3DCB8.9090805@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jun 2011 22:09:28.0440 (UTC) FILETIME=[3B687F80:01CC2884] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 22:09:30 -0000 --_51b0a978-7c3e-4e7e-9951-e8bdb41cb409_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable These kind of "performance" arguments tend to fall victim to improvements i= n technology=2C so even if they can be demonstrated to be true at a given p= oint in time=2C the argument may prove invalid years or even months down th= e road. =20 In this particular case=2C there have been some major improvements in Javas= cript performance in recent browser releases=2C and it is quite possible th= at those improvements may continue. =20 So even if such a demonstration were to "fail" on current releases=2C the = target is not today's browser (which after all=2C doesn't support RTCWEB at= all)=2C but rather future releases that do (and may also incorporate Javas= cript performance improvements).=20 To my mind=2C the real question isn't performance=2C it is interoperability= . The "monolithic" approach to ICE brings with it the potential for inter= operability problems between different browsers operating on the same servi= ce. Mathew's approach of Javascript implementation in ICE addresses that i= ssue=2C but I'm concerned about the implications for cross-service interope= rability. =20 Date: Sat=2C 11 Jun 2011 23:23:04 +0200 From: harald@alvestrand.no To: bernard_aboba@hotmail.com CC: rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal =20 =20 =20 =20 Bernard=2C =20 at last week's call=2C the question was raised on whether it's actually possible to implement ICE in javascript according to the described model - the Javascript event loop has certain problems with precise timing. =20 The upshoot seemed to be that we'd like to see a demonstration that it's possible to create an ICE-interoperable implementation using Javascript as described before attempting to go further down this path. =20 Some other comments below. =20 On 06/11/2011 10:43 PM=2C Bernard Aboba wrote: =20 =20 Review of draft-kaufman-rtcweb-traversal =20 Overall=2C a very good document.=20 =20 Comments below: =20 Section 2.2. Hampers Innovation =20 One of the benefits of ICE is that it allows local implementation flexibility in the way candidates are gathered=2C offered and prioritized. However=2C once ICE is baked into the browser=2C it is no longer possible for that innovation to take place - or at least=2C it leaves the hands of the voice application providers. To date=2C there has been variability in this aspect of implementation=2C with different providers tuning it to tweak their needs and deployments. =20 [BA] It might be pointed out this flexibility has already proven useful to enable support for HTTP failover as well as in implementations of ICE supporting IPV6. Given the wide variety of IPv6 deployments in=20 progress=2C consideration experimentation and tweaking has been required=20 to handle the wide variety of conditions that can be experienced (e.g. IPv6 tunnels of various flavors=2C network devices or services =20 with partial or no IPv6 support=2C missing IPv6 routes=2C NAT 64=2C etc.).=20 =20 =20 This is good information=2C and it seems reasonable that it should lead to a rework of ICE based on this experience. Is it written up anywhere you can share? =20 ICE in Javascript: A full ICE implementation is possible in Javascript itself. Because the implementation resides in Javasript=2C it is trivially changed at any time. =20 Server-Based ICE: A full ICE implementation can execute in the server=2C using remote-control commands to inform the browser to send STUN transactions=2C and passing the results from the browser back to the server. In essence - MGCP for ICE. =20 STUN-Only: For deployments where the peer is always publically reachable from clients - such as enterprises or PSTN termination services - the Javascript can do a single STUN transaction to create a permission in the browser=2C and then proceed to send media. =20 Non-ICE: Protocols similar to ICE=2C but not otherwise compliant=2C can also be implemented. Negotiation of which NAT traversal mechanism is needed=2C is done by the application outside of the browser. =20 [BA] There are some interoperability implications to these approaches that need to be explored. For example=2C the ICE Javascript approach should enable interoperability between different browsers attached to the same service. However=2C it is not clear to me that this will necessarily work for=20 inter-service communication (e.g. the clients could have=20 incompatible ICE Javascript libraries).=20 =20 =20 If both javascript libraries implement ICE=2C they should by definition be interoperable - I am more worried about the case where one application supports ICE and another application supports some ICE-like mechanism. =20 =20 = --_51b0a978-7c3e-4e7e-9951-e8bdb41cb409_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable These kind of "performance" arguments tend to fall victim to improvements i= n technology=2C so even if they can be demonstrated to be true at a given p= oint in time=2C the argument may prove invalid years or even months down th= e road. =3B =3B

In this particular case=2C there have been = some major improvements in Javascript performance in recent browser release= s=2C and it is quite possible that those improvements may continue. =3B=

So even if such a demonstration were to "fail" on current releases= =2C =3B the target is not today's browser (which after all=2C doesn't s= upport RTCWEB at all)=2C but rather future releases that do (and may also i= ncorporate Javascript performance improvements).

To my mind=2C the = real question isn't performance=2C it is interoperability. =3B =3B = The "monolithic" approach to ICE brings with it the potential for interoper= ability problems between different browsers operating on the same service.&= nbsp=3B Mathew's approach of Javascript implementation in ICE addresses tha= t issue=2C but I'm concerned about the implications for cross-service inter= operability. =3B

Date: Sat=2C 11 Jun 20= 11 23:23:04 +0200
From: harald@alvestrand.no
To: bernard_aboba@hotmai= l.com
CC: rtcweb@ietf.org
Subject: Re: [rtcweb] Review of draft-kaufm= an-rtcweb-traversal

=20 =20 =20 =20 Bernard=2C

at last week's call=2C the question was raised on whether it's actually possible to implement ICE in javascript according to the described model - the Javascript event loop has certain problems with precise timing.

The upshoot seemed to be that we'd like to see a demonstration that it's possible to create an ICE-interoperable implementation using Javascript as described before attempting to go further down this path.

Some other comments below.

On 06/11/2011 10:43 PM=2C Bernard Aboba wrote:
Review of draft-kaufman-rtcweb-traversal

Overall=2C a very good document.

Comments below:

Section 2.2. =3B Hampers Innovation

 =3B =3B One of the benefits of ICE is that it allows local implementation
 =3B =3B flexibility in the way candidates are gathered=2C of= fered and
 =3B =3B prioritized. =3B However=2C once ICE is baked in= to the browser=2C it is no
 =3B =3B longer possible for that innovation to take place - = or at least=2C it
 =3B =3B leaves the hands of the voice application providers.=  =3B To date=2C there
 =3B =3B has been variability in this aspect of implementatio= n=2C with different
 =3B =3B providers tuning it to tweak their needs and deploym= ents.

[BA] It might be pointed out this flexibility has already proven useful
to enable support for HTTP failover as well as in implementations of
ICE supporting IPV6. =3B Given the wide variety of IPv6 deploymen= ts in
progress=2C consideration experimentation and tweaking has been required
to handle the wide variety of conditions that can be experienced
(e.g. IPv6 tunnels of various flavors=2C network devices or services
with partial or no IPv6 support=2C =3B missing IPv6 routes=2C NAT= 64=2C etc.).

This is good information=2C and it seems reasonable that it should lead to a rework of ICE based on this experience. Is it written up anywhere you can share?

&nb= sp=3B =3B ICE in Javascript: =3B A full ICE implementation is possible in
 =3B =3B =3B =3B =3B Javascript itself. =3B B= ecause the implementation resides in
 =3B =3B =3B =3B =3B Javasript=2C it is trivially= changed at any time.

 =3B =3B Server-Based ICE: =3B A full ICE implementation = can execute in the
 =3B =3B =3B =3B =3B server=2C using remote-contr= ol commands to inform the browser to
 =3B =3B =3B =3B =3B send STUN transactions=2C an= d passing the results from the browser
 =3B =3B =3B =3B =3B back to the server. =3B = In essence - MGCP for ICE.

 =3B =3B STUN-Only: =3B For deployments where the peer is= always publically
 =3B =3B =3B =3B =3B reachable from clients - suc= h as enterprises or PSTN termination
 =3B =3B =3B =3B =3B services - the Javascript ca= n do a single STUN transaction to
 =3B =3B =3B =3B =3B create a permission in the b= rowser=2C and then proceed to send
 =3B =3B =3B =3B =3B media.

 =3B =3B Non-ICE: =3B Protocols similar to ICE=2C but not= otherwise compliant=2C can
 =3B =3B =3B =3B =3B also be implemented. =3B= Negotiation of which NAT traversal mechanism
 =3B =3B =3B =3B =3B is needed=2C is done by the = application outside of the browser.

[BA] There are some interoperability implications to these
approaches that need to be explored. =3B For example=2C the ICE Javascript approach should enable interoperability
between different browsers attached to the same service. =3B Howe= ver=2C
it is not clear to me that this will necessarily work for
inter-service communication (e.g. the clients could have
incompatible ICE Javascript libraries).

If both javascript libraries implement ICE=2C they should by definition be interoperable - I am more worried about the case where one application supports ICE and another application supports some ICE-like mechanism.


= --_51b0a978-7c3e-4e7e-9951-e8bdb41cb409_-- From dzonatas@gmail.com Sat Jun 11 16:14:08 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5599C11E8097 for ; Sat, 11 Jun 2011 16:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=-2.613, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC+wAtxF3JTI for ; Sat, 11 Jun 2011 16:14:07 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 487CC11E807C for ; Sat, 11 Jun 2011 16:14:07 -0700 (PDT) Received: by pxi20 with SMTP id 20so2670331pxi.27 for ; Sat, 11 Jun 2011 16:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZCtilal8ka7+gE8GCuhqSkh0UPENZdBdlc3eBpQ/oZQ=; b=RwYmpwApZSsTS5tthrfwCKHGx6f5KCotJodi2bIi3yoacc3Nt1K/y33ie4dJ7dH6pP xasbuUQG+j/0JYnXlgyR96EnAPDaGG0O8E2PvuQatf7QiAGOSL3Dold1sA5IyB7B2KkX o6uIlUK7uraXFUhJnWszINI3Ml0OsnzS6mqxI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Y9gcWJdmT8tkh218vTSEBLr1k07u2Knzye6yI4yxGViIDUl/ZNPeiyhyHHU8aKU7Th 0iWgSOLQxRE02wrSU1WP5P95lxsY/WpX4cl0PeUxc0GagkwBjyHV6NP4z6QRZuQskVLc /n6mGngxwCmDi8z8m6Q15jt1hu/wDwaqh5hnk= Received: by 10.68.29.229 with SMTP id n5mr1701717pbh.176.1307834045686; Sat, 11 Jun 2011 16:14:05 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id y2sm3424850pbi.19.2011.06.11.16.14.04 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Jun 2011 16:14:04 -0700 (PDT) Message-ID: <4DF3F672.8090709@gmail.com> Date: Sat, 11 Jun 2011 16:12:50 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4DF3DCB8.9090805@alvestrand.no> In-Reply-To: <4DF3DCB8.9090805@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 23:14:08 -0000 +1 "a demonstration that it's possible to create an ICE-interoperable implementation using Javascript" Especially if the media is intentionally legal size document (or legal size video...). On 06/11/2011 02:23 PM, Harald Alvestrand wrote: > Bernard, > > at last week's call, the question was raised on whether it's actually > possible to implement ICE in javascript according to the described > model - the Javascript event loop has certain problems with precise > timing. > > The upshoot seemed to be that we'd like to see a demonstration that > it's possible to create an ICE-interoperable implementation using > Javascript as described before attempting to go further down this path. > > Some other comments below. > > On 06/11/2011 10:43 PM, Bernard Aboba wrote: >> Review of draft-kaufman-rtcweb-traversal >> >> Overall, a very good document. >> >> Comments below: >> >> Section 2.2. Hampers Innovation >> >> One of the benefits of ICE is that it allows local implementation >> flexibility in the way candidates are gathered, offered and >> prioritized. However, once ICE is baked into the browser, it is no >> longer possible for that innovation to take place - or at least, it >> leaves the hands of the voice application providers. To date, there >> has been variability in this aspect of implementation, with different >> providers tuning it to tweak their needs and deployments. >> >> [BA] It might be pointed out this flexibility has already proven useful >> to enable support for HTTP failover as well as in implementations of >> ICE supporting IPV6. Given the wide variety of IPv6 deployments in >> progress, consideration experimentation and tweaking has been required >> to handle the wide variety of conditions that can be experienced >> (e.g. IPv6 tunnels of various flavors, network devices or services >> with partial or no IPv6 support, missing IPv6 routes, NAT 64, etc.). > > This is good information, and it seems reasonable that it should lead > to a rework of ICE based on this experience. Is it written up anywhere > you can share? > >> ICE in Javascript: A full ICE implementation is possible in >> Javascript itself. Because the implementation resides in >> Javasript, it is trivially changed at any time. >> >> Server-Based ICE: A full ICE implementation can execute in the >> server, using remote-control commands to inform the browser to >> send STUN transactions, and passing the results from the browser >> back to the server. In essence - MGCP for ICE. >> >> STUN-Only: For deployments where the peer is always publically >> reachable from clients - such as enterprises or PSTN termination >> services - the Javascript can do a single STUN transaction to >> create a permission in the browser, and then proceed to send >> media. >> >> Non-ICE: Protocols similar to ICE, but not otherwise compliant, can >> also be implemented. Negotiation of which NAT traversal mechanism >> is needed, is done by the application outside of the browser. >> >> [BA] There are some interoperability implications to these >> approaches that need to be explored. For example, the ICE >> Javascript approach should enable interoperability >> between different browsers attached to the same service. However, >> it is not clear to me that this will necessarily work for >> inter-service communication (e.g. the clients could have >> incompatible ICE Javascript libraries). > > If both javascript libraries implement ICE, they should by definition > be interoperable - I am more worried about the case where one > application supports ICE and another application supports some > ICE-like mechanism. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From harald@alvestrand.no Sat Jun 11 22:55:47 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1107621F848C for ; Sat, 11 Jun 2011 22:55:47 -0700 (PDT) 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, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3S7OFRRlunM for ; Sat, 11 Jun 2011 22:55:46 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 93A2F21F848E for ; Sat, 11 Jun 2011 22:55:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 111DC39E0BC; Sun, 12 Jun 2011 07:54:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvX9XThhORMB; Sun, 12 Jun 2011 07:54:42 +0200 (CEST) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 9BEA239E074; Sun, 12 Jun 2011 07:54:42 +0200 (CEST) Message-ID: <4DF454DA.8030300@alvestrand.no> Date: Sun, 12 Jun 2011 07:55:38 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bernard Aboba References: , <4DF3DCB8.9090805@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080106080206060403010608" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 05:55:47 -0000 This is a multi-part message in MIME format. --------------080106080206060403010608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/12/2011 12:09 AM, Bernard Aboba wrote: > These kind of "performance" arguments tend to fall victim to > improvements in technology, so even if they can be demonstrated to be > true at a given point in time, the argument may prove invalid years or > even months down the road. > > In this particular case, there have been some major improvements in > Javascript performance in recent browser releases, and it is quite > possible that those improvements may continue. Actually my worry is more the javascript model than absolute performance. My tests with current browsers indicate that the timer resolutions for timed events are on the order of magnitude of 10-50 msec, depending on browser, and the single-threaded model of the Javascript event queue means that response to timers depends on nothing else happening in that Javascript context. While I'm not a Javascript expert, I haven't had any reassurance that we can get around this from Javascript experts I've asked. > > So even if such a demonstration were to "fail" on current releases, > the target is not today's browser (which after all, doesn't support > RTCWEB at all), but rather future releases that do (and may also > incorporate Javascript performance improvements). We might be taking on a bit much if we, in addition to specifying RTCWEB protocols, also take on rewriting the Javascript runtime model. If all it takes is performance tweaking, I might be more optimistic; a demo running ICE at half the speed/timing precision needed would probably convince me it could be done. > > To my mind, the real question isn't performance, it is > interoperability. The "monolithic" approach to ICE brings with it > the potential for interoperability problems between different browsers > operating on the same service. Mathew's approach of Javascript > implementation in ICE addresses that issue, but I'm concerned about > the implications for cross-service interoperability. One of my implementor colleagues claims (in another context) that a main difference between an embedded-in-browser implementation and a Javascript one is that the browser one has less than 10 significant implementations that have to interoperate, while the Javascript one will have an essentially unbounded number of implementations ("millions of web pages"). His conclusion was that for the things we need to get right in order to have interoperability (for the case we were discussing, which was not ICE), it's better to have them embedded in the browser than to depend on Javascript. > > ------------------------------------------------------------------------ > Date: Sat, 11 Jun 2011 23:23:04 +0200 > From: harald@alvestrand.no > To: bernard_aboba@hotmail.com > CC: rtcweb@ietf.org > Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal > > Bernard, > > at last week's call, the question was raised on whether it's actually > possible to implement ICE in javascript according to the described > model - the Javascript event loop has certain problems with precise > timing. > > The upshoot seemed to be that we'd like to see a demonstration that > it's possible to create an ICE-interoperable implementation using > Javascript as described before attempting to go further down this path. > > Some other comments below. > > On 06/11/2011 10:43 PM, Bernard Aboba wrote: > > Review of draft-kaufman-rtcweb-traversal > > Overall, a very good document. > > Comments below: > > Section 2.2. Hampers Innovation > > One of the benefits of ICE is that it allows local implementation > flexibility in the way candidates are gathered, offered and > prioritized. However, once ICE is baked into the browser, it is no > longer possible for that innovation to take place - or at least, it > leaves the hands of the voice application providers. To date, > there > has been variability in this aspect of implementation, with > different > providers tuning it to tweak their needs and deployments. > > [BA] It might be pointed out this flexibility has already proven > useful > to enable support for HTTP failover as well as in implementations of > ICE supporting IPV6. Given the wide variety of IPv6 deployments in > progress, consideration experimentation and tweaking has been > required > to handle the wide variety of conditions that can be experienced > (e.g. IPv6 tunnels of various flavors, network devices or services > with partial or no IPv6 support, missing IPv6 routes, NAT 64, etc.). > > > This is good information, and it seems reasonable that it should lead > to a rework of ICE based on this experience. Is it written up anywhere > you can share? > > ICE in Javascript: A full ICE implementation is possible in > Javascript itself. Because the implementation resides in > Javasript, it is trivially changed at any time. > > Server-Based ICE: A full ICE implementation can execute in the > server, using remote-control commands to inform the browser to > send STUN transactions, and passing the results from the browser > back to the server. In essence - MGCP for ICE. > > STUN-Only: For deployments where the peer is always publically > reachable from clients - such as enterprises or PSTN termination > services - the Javascript can do a single STUN transaction to > create a permission in the browser, and then proceed to send > media. > > Non-ICE: Protocols similar to ICE, but not otherwise > compliant, can > also be implemented. Negotiation of which NAT traversal > mechanism > is needed, is done by the application outside of the browser. > > [BA] There are some interoperability implications to these > approaches that need to be explored. For example, the ICE > Javascript approach should enable interoperability > between different browsers attached to the same service. However, > it is not clear to me that this will necessarily work for > inter-service communication (e.g. the clients could have > incompatible ICE Javascript libraries). > > > If both javascript libraries implement ICE, they should by definition > be interoperable - I am more worried about the case where one > application supports ICE and another application supports some > ICE-like mechanism. > > --------------080106080206060403010608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/12/2011 12:09 AM, Bernard Aboba wrote:
These kind of "performance" arguments tend to fall victim to improvements in technology, so even if they can be demonstrated to be true at a given point in time, the argument may prove invalid years or even months down the road.  

In this particular case, there have been some major improvements in Javascript performance in recent browser releases, and it is quite possible that those improvements may continue. 
Actually my worry is more the javascript model than absolute performance. My tests with current browsers indicate that the timer resolutions for timed events are on the order of magnitude of 10-50 msec, depending on browser, and the single-threaded model of the Javascript event queue means that response to timers depends on nothing else happening in that Javascript context. While I'm not a Javascript expert, I haven't had any reassurance that we can get around this from Javascript experts I've asked.

So even if such a demonstration were to "fail" on current releases,  the target is not today's browser (which after all, doesn't support RTCWEB at all), but rather future releases that do (and may also incorporate Javascript performance improvements).
We might be taking on a bit much if we, in addition to specifying RTCWEB protocols, also take on rewriting the Javascript runtime model.
If all it takes is performance tweaking, I might be more optimistic; a demo running ICE at half the speed/timing precision needed would probably convince me it could be done.

To my mind, the real question isn't performance, it is interoperability.   The "monolithic" approach to ICE brings with it the potential for interoperability problems between different browsers operating on the same service.  Mathew's approach of Javascript implementation in ICE addresses that issue, but I'm concerned about the implications for cross-service interoperability. 
One of my implementor colleagues claims (in another context) that a main difference between an embedded-in-browser implementation and a Javascript one is that the browser one has less than 10 significant implementations that have to interoperate, while the Javascript one will have an essentially unbounded number of implementations ("millions of web pages"). His conclusion was that for the things we need to get right in order to have interoperability (for the case we were discussing, which was not ICE), it's better to have them embedded in the browser than to depend on Javascript.

Date: Sat, 11 Jun 2011 23:23:04 +0200
From: harald@alvestrand.no
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org
Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal

Bernard,

at last week's call, the question was raised on whether it's actually possible to implement ICE in javascript according to the described model - the Javascript event loop has certain problems with precise timing.

The upshoot seemed to be that we'd like to see a demonstration that it's possible to create an ICE-interoperable implementation using Javascript as described before attempting to go further down this path.

Some other comments below.

On 06/11/2011 10:43 PM, Bernard Aboba wrote:
Review of draft-kaufman-rtcweb-traversal

Overall, a very good document.

Comments below:

Section 2.2.  Hampers Innovation

   One of the benefits of ICE is that it allows local implementation
   flexibility in the way candidates are gathered, offered and
   prioritized.  However, once ICE is baked into the browser, it is no
   longer possible for that innovation to take place - or at least, it
   leaves the hands of the voice application providers.  To date, there
   has been variability in this aspect of implementation, with different
   providers tuning it to tweak their needs and deployments.

[BA] It might be pointed out this flexibility has already proven useful
to enable support for HTTP failover as well as in implementations of
ICE supporting IPV6.  Given the wide variety of IPv6 deployments in
progress, consideration experimentation and tweaking has been required
to handle the wide variety of conditions that can be experienced
(e.g. IPv6 tunnels of various flavors, network devices or services
with partial or no IPv6 support,  missing IPv6 routes, NAT 64, etc.).

This is good information, and it seems reasonable that it should lead to a rework of ICE based on this experience. Is it written up anywhere you can share?

   ICE in Javascript:  A full ICE implementation is possible in
      Javascript itself.  Because the implementation resides in
      Javasript, it is trivially changed at any time.

   Server-Based ICE:  A full ICE implementation can execute in the
      server, using remote-control commands to inform the browser to
      send STUN transactions, and passing the results from the browser
      back to the server.  In essence - MGCP for ICE.

   STUN-Only:  For deployments where the peer is always publically
      reachable from clients - such as enterprises or PSTN termination
      services - the Javascript can do a single STUN transaction to
      create a permission in the browser, and then proceed to send
      media.

   Non-ICE:  Protocols similar to ICE, but not otherwise compliant, can
      also be implemented.  Negotiation of which NAT traversal mechanism
      is needed, is done by the application outside of the browser.

[BA] There are some interoperability implications to these
approaches that need to be explored.  For example, the ICE
Javascript approach should enable interoperability
between different browsers attached to the same service.  However,
it is not clear to me that this will necessarily work for
inter-service communication (e.g. the clients could have
incompatible ICE Javascript libraries).

If both javascript libraries implement ICE, they should by definition be interoperable - I am more worried about the case where one application supports ICE and another application supports some ICE-like mechanism.



--------------080106080206060403010608-- From matthew.kaufman@skype.net Sun Jun 12 02:05:46 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4970811E807F for ; Sun, 12 Jun 2011 02:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiBkSnrhryp8 for ; Sun, 12 Jun 2011 02:05:45 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 0218D11E8078 for ; Sun, 12 Jun 2011 02:05:44 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id B6055170F; Sun, 12 Jun 2011 11:05:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=mx; bh=9vR8rQNdJ+2sZZSRzL82MABId2g=; b=rH76qvF BJw+M7d5sBP778U6H+ACAB5J/iMx2IgpeBE18GMZbOjp39uAPrR8p+xaLIHEEppX 15scYvTNlw/WNNsMEf7/3RPe+U7SSAviWoYRBNIWfXhPE5uD9RbKXiRtud3vPgN0 v+26DYbcHz7X1Ois8b9TCw/jeatU0Pikcv7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to; q=dns; s=mx; b=TCeK9+1i87tOFPGPXxykyyPYx3GKvL4Ndit7w+syYNQgqjLr MCdVBJLAM+ijiqXfQnJz9So4FWBQO6x9I9ZJFS7B+rdZJ9/dfl2zcwPQAtAMc91n rzvrzQ3X074iFnYDY1ristD06N1KaXpt9FjAah855V8L5oR1FFUfM2XgCdE= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id B12D57F6; Sun, 12 Jun 2011 11:05:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 889C0350769D; Sun, 12 Jun 2011 11:05:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMojAjMW5Ilq; Sun, 12 Jun 2011 11:05:41 +0200 (CEST) Received: from [172.30.29.186] (unknown [80.187.211.13]) by zimbra.skype.net (Postfix) with ESMTPSA id D97E23507673; Sun, 12 Jun 2011 11:05:40 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-34-997331796 From: Matthew Kaufman In-Reply-To: <4DF454DA.8030300@alvestrand.no> Date: Sun, 12 Jun 2011 11:05:29 +0200 Message-Id: <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> References: , <4DF3DCB8.9090805@alvestrand.no> <4DF454DA.8030300@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1082) Cc: Bernard Aboba , rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 09:05:46 -0000 --Apple-Mail-34-997331796 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 12, 2011, at 7:55 AM, Harald Alvestrand wrote: > On 06/12/2011 12:09 AM, Bernard Aboba wrote: >>=20 >> These kind of "performance" arguments tend to fall victim to = improvements in technology, so even if they can be demonstrated to be = true at a given point in time, the argument may prove invalid years or = even months down the road. =20 >>=20 >> In this particular case, there have been some major improvements in = Javascript performance in recent browser releases, and it is quite = possible that those improvements may continue. =20 > Actually my worry is more the javascript model than absolute = performance. My tests with current browsers indicate that the timer = resolutions for timed events are on the order of magnitude of 10-50 = msec, depending on browser, and the single-threaded model of the = Javascript event queue means that response to timers depends on nothing = else happening in that Javascript context. While I'm not a Javascript = expert, I haven't had any reassurance that we can get around this from = Javascript experts I've asked. The resolution of waking up for a timer on WinNT is 30 msec and only 15 = msec on WinXP and ICE works just fine there. I am not at all convinced that for our use cases we need anything better = than ~100 msec, so your 50 msec is already twice as good. >>=20 >> So even if such a demonstration were to "fail" on current releases, = the target is not today's browser (which after all, doesn't support = RTCWEB at all), but rather future releases that do (and may also = incorporate Javascript performance improvements).=20 > We might be taking on a bit much if we, in addition to specifying = RTCWEB protocols, also take on rewriting the Javascript runtime model. > If all it takes is performance tweaking, I might be more optimistic; a = demo running ICE at half the speed/timing precision needed would = probably convince me it could be done. See above. >>=20 >> To my mind, the real question isn't performance, it is = interoperability. The "monolithic" approach to ICE brings with it the = potential for interoperability problems between different browsers = operating on the same service. Mathew's approach of Javascript = implementation in ICE addresses that issue, but I'm concerned about the = implications for cross-service interoperability. =20 > One of my implementor colleagues claims (in another context) that a = main difference between an embedded-in-browser implementation and a = Javascript one is that the browser one has less than 10 significant = implementations that have to interoperate, while the Javascript one will = have an essentially unbounded number of implementations ("millions of = web pages"). His conclusion was that for the things we need to get right = in order to have interoperability (for the case we were discussing, = which was not ICE), it's better to have them embedded in the browser = than to depend on Javascript. This is actually the only good argument I've heard... that if the = "right" implementation is baked into browsers then it will "just work". = On the other hand, we have numerous examples of things that are baked = into browsers that would be much more useful/flexible if they weren't... = or at the very least offered both options. (And the future flexibility = requirements around IPv6 are certainly a hint of why we might need this, = in addition to service providers with non-standard needs.) What about having a full ICE implementation *and* the ability to run it = "manually" under Javascript control? (The example that keeps coming to mind is the difference between = progressive playback of HTTP video (as is in Flash Player and most HTML5 = video tag implementation) vs. adaptive HTTP streaming (which, in Flash = Player was architected as low-level ActionScript primitives plus = reference code, and which has already done several things that weren't = originally imagined when the APIs were first added)) Matthew Kaufman= --Apple-Mail-34-997331796 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 06/12/2011 12:09 AM, Bernard Aboba wrote:
These kind of "performance" arguments tend to fall victim to improvements in technology, so even if they can be demonstrated to be true at a given point in time, the argument may prove invalid years or even months down the road.  

In this particular case, there have been some major improvements in Javascript performance in recent browser releases, and it is quite possible that those improvements may continue. 
Actually my worry is more the javascript model than absolute performance. My tests with current browsers indicate that the timer resolutions for timed events are on the order of magnitude of 10-50 msec, depending on browser, and the single-threaded model of the Javascript event queue means that response to timers depends on nothing else happening in that Javascript context. While I'm not a Javascript expert, I haven't had any reassurance that we can get around this from Javascript experts I've = asked.

The resolution of waking up = for a timer on WinNT is 30 msec and only 15 msec on WinXP and ICE works = just fine there.

I am not at all convinced that = for our use cases we need anything better than ~100 msec, so your 50 = msec is already twice as good.


So even if such a demonstration were to "fail" on current releases,  the target is not today's browser (which after = all, doesn't support RTCWEB at all), but rather future releases that do (and may also incorporate Javascript performance improvements). =
We might be taking on a bit much if we, in addition to specifying RTCWEB protocols, also take on rewriting the Javascript runtime model.
If all it takes is performance tweaking, I might be more optimistic; a demo running ICE at half the speed/timing precision needed would probably convince me it could be = done.

See = above.


To my mind, the real question isn't performance, it is interoperability.   The "monolithic" approach to ICE = brings with it the potential for interoperability problems between different browsers operating on the same service.  Mathew's approach of Javascript implementation in ICE addresses that issue, but I'm concerned about the implications for cross-service interoperability. 
One of my implementor colleagues claims (in another context) that a main difference between an embedded-in-browser implementation and a Javascript one is that the browser one has less than 10 significant implementations that have to interoperate, while the Javascript one will have an essentially unbounded number of implementations ("millions of web pages"). His conclusion was that for the things we need to get right in order to have interoperability (for the case we were discussing, which was not ICE), it's better to have them embedded in the browser than to depend on = Javascript.

This is actually = the only good argument I've heard... that if the "right" implementation = is baked into browsers then it will "just work". On the other hand, we = have numerous examples of things that are baked into browsers that would = be much more useful/flexible if they weren't... or at the very least = offered both options. (And the future flexibility requirements around = IPv6 are certainly a hint of why we might need this, in addition to = service providers with non-standard = needs.)

What about having a full ICE = implementation *and* the ability to run it "manually" under Javascript = control?

(The example that keeps coming to mind = is the difference between progressive playback of HTTP video (as is in = Flash Player and most HTML5 video tag implementation) vs. adaptive HTTP = streaming (which, in Flash Player was architected as low-level = ActionScript primitives plus reference code, and which has already done = several things that weren't originally imagined when the APIs were first = added))

Matthew = Kaufman
= --Apple-Mail-34-997331796-- From tim@phonefromhere.com Sun Jun 12 02:36:44 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B6B11E807F for ; Sun, 12 Jun 2011 02:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nxy8LsXe4k1z for ; Sun, 12 Jun 2011 02:36:43 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 82D5B11E8078 for ; Sun, 12 Jun 2011 02:36:43 -0700 (PDT) Received: from [192.168.0.21] (87-194-8-115.bethere.co.uk [87.194.8.115]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id B054537A8FC; Sun, 12 Jun 2011 10:46:31 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> Date: Sun, 12 Jun 2011 10:36:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <4DF3DCB8.9090805@alvestrand.no> <4DF454DA.8030300@alvestrand.no> <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> To: Matthew Kaufman X-Mailer: Apple Mail (2.1084) Cc: Bernard Aboba , rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 09:36:44 -0000 On 12 Jun 2011, at 10:05, Matthew Kaufman wrote: >=20 > On Jun 12, 2011, at 7:55 AM, Harald Alvestrand wrote: >=20 >> On 06/12/2011 12:09 AM, Bernard Aboba wrote: >>>=20 >>>=20 >=20 >>> To my mind, the real question isn't performance, it is = interoperability. The "monolithic" approach to ICE brings with it the = potential for interoperability problems between different browsers = operating on the same service. Mathew's approach of Javascript = implementation in ICE addresses that issue, but I'm concerned about the = implications for cross-service interoperability. =20 >> One of my implementor colleagues claims (in another context) that a = main difference between an embedded-in-browser implementation and a = Javascript one is that the browser one has less than 10 significant = implementations that have to interoperate, while the Javascript one will = have an essentially unbounded number of implementations ("millions of = web pages"). His conclusion was that for the things we need to get right = in order to have interoperability (for the case we were discussing, = which was not ICE), it's better to have them embedded in the browser = than to depend on Javascript. >=20 > This is actually the only good argument I've heard... that if the = "right" implementation is baked into browsers then it will "just work". = On the other hand, we have numerous examples of things that are baked = into browsers that would be much more useful/flexible if they weren't... = or at the very least offered both options. (And the future flexibility = requirements around IPv6 are certainly a hint of why we might need this, = in addition to service providers with non-standard needs.) Maybe I've missed something, but to my mind there is no need for the = javascript ICE's to interoperate with each other. All the users of = XYZ-webconference service will load _exactly_the_same_ javascript - so = for them to talk peer-to-peer the XYZ-ICE-lite implementation only has = to interoperate with itself. Are there important use-cases where we expect to have a visitor on = XYZ.com web-page calling to ABC.com ? If we do then a baked in ICE=20 may be needed. Tim.= From harald@alvestrand.no Sun Jun 12 02:58:05 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0CC21F848B for ; Sun, 12 Jun 2011 02:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.362 X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkCTQBxJS5Cg for ; Sun, 12 Jun 2011 02:58:04 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8236E21F8486 for ; Sun, 12 Jun 2011 02:58:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D8EAB39E0BC; Sun, 12 Jun 2011 11:57:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jP3Yx6ilq2vV; Sun, 12 Jun 2011 11:57:04 +0200 (CEST) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id A86BF39E074; Sun, 12 Jun 2011 11:57:03 +0200 (CEST) Message-ID: <4DF48DA7.6080002@alvestrand.no> Date: Sun, 12 Jun 2011 11:57:59 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Matthew Kaufman References: , <4DF3DCB8.9090805@alvestrand.no> <4DF454DA.8030300@alvestrand.no> <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> In-Reply-To: <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> Content-Type: multipart/alternative; boundary="------------020800090504010509030308" Cc: Bernard Aboba , rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 09:58:05 -0000 This is a multi-part message in MIME format. --------------020800090504010509030308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/12/2011 11:05 AM, Matthew Kaufman wrote: > > On Jun 12, 2011, at 7:55 AM, Harald Alvestrand wrote: > >> On 06/12/2011 12:09 AM, Bernard Aboba wrote: >>> These kind of "performance" arguments tend to fall victim to >>> improvements in technology, so even if they can be demonstrated to >>> be true at a given point in time, the argument may prove invalid >>> years or even months down the road. >>> >>> In this particular case, there have been some major improvements in >>> Javascript performance in recent browser releases, and it is quite >>> possible that those improvements may continue. >> Actually my worry is more the javascript model than absolute >> performance. My tests with current browsers indicate that the timer >> resolutions for timed events are on the order of magnitude of 10-50 >> msec, depending on browser, and the single-threaded model of the >> Javascript event queue means that response to timers depends on >> nothing else happening in that Javascript context. While I'm not a >> Javascript expert, I haven't had any reassurance that we can get >> around this from Javascript experts I've asked. > > The resolution of waking up for a timer on WinNT is 30 msec and only > 15 msec on WinXP and ICE works just fine there. > > I am not at all convinced that for our use cases we need anything > better than ~100 msec, so your 50 msec is already twice as good. The shortest timer in RFC 5245 (as far as I can see) is Ta (section 16.1), which has a lower bound of 20 msec; however, this is a lower bound on transmission intervals, so it's possible that an implementation that fires only every 100 msec would be perfectly interoperable with an application that fires every 20 msec. Testing will show.... > >>> >>> So even if such a demonstration were to "fail" on current releases, >>> the target is not today's browser (which after all, doesn't support >>> RTCWEB at all), but rather future releases that do (and may also >>> incorporate Javascript performance improvements). >> We might be taking on a bit much if we, in addition to specifying >> RTCWEB protocols, also take on rewriting the Javascript runtime model. >> If all it takes is performance tweaking, I might be more optimistic; >> a demo running ICE at half the speed/timing precision needed would >> probably convince me it could be done. > > See above. > >>> >>> To my mind, the real question isn't performance, it is >>> interoperability. The "monolithic" approach to ICE brings with it >>> the potential for interoperability problems between different >>> browsers operating on the same service. Mathew's approach of >>> Javascript implementation in ICE addresses that issue, but I'm >>> concerned about the implications for cross-service interoperability. >> One of my implementor colleagues claims (in another context) that a >> main difference between an embedded-in-browser implementation and a >> Javascript one is that the browser one has less than 10 significant >> implementations that have to interoperate, while the Javascript one >> will have an essentially unbounded number of implementations >> ("millions of web pages"). His conclusion was that for the things we >> need to get right in order to have interoperability (for the case we >> were discussing, which was not ICE), it's better to have them >> embedded in the browser than to depend on Javascript. > > This is actually the only good argument I've heard... that if the > "right" implementation is baked into browsers then it will "just > work". On the other hand, we have numerous examples of things that are > baked into browsers that would be much more useful/flexible if they > weren't... or at the very least offered both options. (And the future > flexibility requirements around IPv6 are certainly a hint of why we > might need this, in addition to service providers with non-standard > needs.) > > What about having a full ICE implementation *and* the ability to run > it "manually" under Javascript control? I'd be happy to have a spec that allows us to run an "under the covers" fully compatible ICE implementation in the "normal case" (like what's currently implemented in Google's libjingle/WebRTC code), and have an extension (or another API spec) that allows "manual" driving of the STUN machinery, which we can agree on once it's proved viable. I'd be very unhappy at this point to have only a spec that required a partly-Javascript ICE implementation. But that's my preferences. > > (The example that keeps coming to mind is the difference between > progressive playback of HTTP video (as is in Flash Player and most > HTML5 video tag implementation) vs. adaptive HTTP streaming (which, in > Flash Player was architected as low-level ActionScript primitives plus > reference code, and which has already done several things that weren't > originally imagined when the APIs were first added)) > > Matthew Kaufman --------------020800090504010509030308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/12/2011 11:05 AM, Matthew Kaufman wrote:

On Jun 12, 2011, at 7:55 AM, Harald Alvestrand wrote:

On 06/12/2011 12:09 AM, Bernard Aboba wrote:
These kind of "performance" arguments tend to fall victim to improvements in technology, so even if they can be demonstrated to be true at a given point in time, the argument may prove invalid years or even months down the road.  

In this particular case, there have been some major improvements in Javascript performance in recent browser releases, and it is quite possible that those improvements may continue. 
Actually my worry is more the javascript model than absolute performance. My tests with current browsers indicate that the timer resolutions for timed events are on the order of magnitude of 10-50 msec, depending on browser, and the single-threaded model of the Javascript event queue means that response to timers depends on nothing else happening in that Javascript context. While I'm not a Javascript expert, I haven't had any reassurance that we can get around this from Javascript experts I've asked.

The resolution of waking up for a timer on WinNT is 30 msec and only 15 msec on WinXP and ICE works just fine there.

I am not at all convinced that for our use cases we need anything better than ~100 msec, so your 50 msec is already twice as good.
The shortest timer in RFC 5245 (as far as I can see) is Ta (section 16.1), which has a lower bound of 20 msec; however, this is a lower bound on transmission intervals, so it's possible that an implementation that fires only every 100 msec would be perfectly interoperable with an application that fires every 20 msec.

Testing will show....



So even if such a demonstration were to "fail" on current releases,  the target is not today's browser (which after all, doesn't support RTCWEB at all), but rather future releases that do (and may also incorporate Javascript performance improvements).
We might be taking on a bit much if we, in addition to specifying RTCWEB protocols, also take on rewriting the Javascript runtime model.
If all it takes is performance tweaking, I might be more optimistic; a demo running ICE at half the speed/timing precision needed would probably convince me it could be done.

See above.


To my mind, the real question isn't performance, it is interoperability.   The "monolithic" approach to ICE brings with it the potential for interoperability problems between different browsers operating on the same service.  Mathew's approach of Javascript implementation in ICE addresses that issue, but I'm concerned about the implications for cross-service interoperability. 
One of my implementor colleagues claims (in another context) that a main difference between an embedded-in-browser implementation and a Javascript one is that the browser one has less than 10 significant implementations that have to interoperate, while the Javascript one will have an essentially unbounded number of implementations ("millions of web pages"). His conclusion was that for the things we need to get right in order to have interoperability (for the case we were discussing, which was not ICE), it's better to have them embedded in the browser than to depend on Javascript.

This is actually the only good argument I've heard... that if the "right" implementation is baked into browsers then it will "just work". On the other hand, we have numerous examples of things that are baked into browsers that would be much more useful/flexible if they weren't... or at the very least offered both options. (And the future flexibility requirements around IPv6 are certainly a hint of why we might need this, in addition to service providers with non-standard needs.)

What about having a full ICE implementation *and* the ability to run it "manually" under Javascript control?
I'd be happy to have a spec that allows us to run an "under the covers" fully compatible ICE implementation in the "normal case" (like what's currently implemented in Google's libjingle/WebRTC code), and have an extension (or another API spec) that allows "manual" driving of the STUN machinery, which we can agree on once it's proved viable. I'd be very unhappy at this point to have only a spec that required a partly-Javascript ICE implementation.

But that's my preferences.

(The example that keeps coming to mind is the difference between progressive playback of HTTP video (as is in Flash Player and most HTML5 video tag implementation) vs. adaptive HTTP streaming (which, in Flash Player was architected as low-level ActionScript primitives plus reference code, and which has already done several things that weren't originally imagined when the APIs were first added))

Matthew Kaufman

--------------020800090504010509030308-- From emil@sip-communicator.org Sun Jun 12 03:02:49 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8292F21F84A9 for ; Sun, 12 Jun 2011 03:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBBYZBnyRiPB for ; Sun, 12 Jun 2011 03:02:48 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A49121F84A8 for ; Sun, 12 Jun 2011 03:02:48 -0700 (PDT) Received: by wwa36 with SMTP id 36so2658572wwa.13 for ; Sun, 12 Jun 2011 03:02:47 -0700 (PDT) Received: by 10.227.20.67 with SMTP id e3mr3916393wbb.100.1307872967244; Sun, 12 Jun 2011 03:02:47 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id ge4sm3375101wbb.30.2011.06.12.03.02.44 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Jun 2011 03:02:46 -0700 (PDT) Message-ID: <4DF48EC4.6050800@jitsi.org> Date: Sun, 12 Jun 2011 12:02:44 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Tim Panton References: , <4DF3DCB8.9090805@alvestrand.no> <4DF454DA.8030300@alvestrand.no> <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bernard Aboba , rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 10:02:49 -0000 =D0=9D=D0=B0 12.06.11 11:36, Tim Panton =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0= =B0: > Maybe I've missed something, but to my mind there is no need for the > javascript ICE's to interoperate with each other. All the users of > XYZ-webconference service will load _exactly_the_same_ javascript - > so for them to talk peer-to-peer the XYZ-ICE-lite implementation only > has to interoperate with itself. >=20 > Are there important use-cases where we expect to have a visitor on > XYZ.com web-page calling to ABC.com ? If we do then a baked in ICE=20 > may be needed. Unless we are planning on promoting a skype-like model where the entire world is stuck with the same provider and where PSTN is the only way to have some sort of interop ... then I'd say that inter-domain calls are the only use case that we have to consider. The Gmail web client is a great example for how things could work. A bunch of clients out there, connected to random XMPP services, can talk to users connected on Gmail and this is great for both Gmail users and those who'd prefer to stick with those other clients. Emil From matthew.kaufman@skype.net Sun Jun 12 03:25:05 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5292D11E807F for ; Sun, 12 Jun 2011 03:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvz2rDxmsDqh for ; Sun, 12 Jun 2011 03:25:04 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5A06911E8070 for ; Sun, 12 Jun 2011 03:25:04 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id EB347CF; Sun, 12 Jun 2011 12:25:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mx; bh=x0 cYrJzpel7N5xeQ0Ko4qS6k2yo=; b=C5xIXRdCBq9thOK5c2XVAYogV7338INFA8 sUOQRJGh6Y19syH2bbCgkz7AlYlgQCoGhuhXBXZs4VQBpe1/r6DBtbhKwq8fKnEu fsXooDo+L0oYvQsW3HLWgvHbTHb0SDUhHi6273oInYX3sKP+SvXGFTzyfaVys8s7 sFMBrygtw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=mx; b=mkedvbF7TC8fMwHu+tWDUK omOJdACqKBwxDgeZnJFigkE/mvHNm5HqiWFWLMKsZqzFvjq90zS2zIxBGEpbAwQO CbAgQXd0FJ6r4nUM2Udxcqb5+od8fDG1CBfR7cuwTQKxZCYAnrRZJ1UxNb34SqgF CSK3H0Vd1Amd13vD08TOc= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id DEDF07F6; Sun, 12 Jun 2011 12:25:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id AF99D350778A; Sun, 12 Jun 2011 12:25:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgb9sRoL2C7j; Sun, 12 Jun 2011 12:25:01 +0200 (CEST) Received: from [172.30.29.167] (unknown [80.187.158.105]) by zimbra.skype.net (Postfix) with ESMTPSA id 88599350769D; Sun, 12 Jun 2011 12:25:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: Date: Sun, 12 Jun 2011 12:24:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E82A919-1B30-41A3-AF4C-E1D77AABECE5@skype.net> References: , <4DF3DCB8.9090805@alvestrand.no> <4DF454DA.8030300@alvestrand.no> <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> To: Tim Panton X-Mailer: Apple Mail (2.1082) Cc: Bernard Aboba , rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 10:25:05 -0000 On Jun 12, 2011, at 11:36 AM, Tim Panton wrote: >=20 > On 12 Jun 2011, at 10:05, Matthew Kaufman wrote: >=20 >>=20 >> On Jun 12, 2011, at 7:55 AM, Harald Alvestrand wrote: >>=20 >>> On 06/12/2011 12:09 AM, Bernard Aboba wrote: >>>>=20 >>>>=20 >>=20 >>>> To my mind, the real question isn't performance, it is = interoperability. The "monolithic" approach to ICE brings with it the = potential for interoperability problems between different browsers = operating on the same service. Mathew's approach of Javascript = implementation in ICE addresses that issue, but I'm concerned about the = implications for cross-service interoperability. =20 >>> One of my implementor colleagues claims (in another context) that a = main difference between an embedded-in-browser implementation and a = Javascript one is that the browser one has less than 10 significant = implementations that have to interoperate, while the Javascript one will = have an essentially unbounded number of implementations ("millions of = web pages"). His conclusion was that for the things we need to get right = in order to have interoperability (for the case we were discussing, = which was not ICE), it's better to have them embedded in the browser = than to depend on Javascript. >>=20 >> This is actually the only good argument I've heard... that if the = "right" implementation is baked into browsers then it will "just work". = On the other hand, we have numerous examples of things that are baked = into browsers that would be much more useful/flexible if they weren't... = or at the very least offered both options. (And the future flexibility = requirements around IPv6 are certainly a hint of why we might need this, = in addition to service providers with non-standard needs.) >=20 > Maybe I've missed something, but to my mind there is no need for the = javascript ICE's to interoperate with each other. All the users of = XYZ-webconference service will load _exactly_the_same_ javascript - so = for them to talk peer-to-peer the XYZ-ICE-lite implementation only has = to interoperate with itself. Definitely true. >=20 > Are there important use-cases where we expect to have a visitor on = XYZ.com web-page calling to ABC.com ? If we do then a baked in ICE=20 > may be needed. >=20 Not the case. One can build a perfectly interoperable ICE using = Javascript, or a combination of Javascript calls and server-side ICE = logic. But when XYZ.com is calling itself it might be able to either save some = of the steps, or do an even better job of NAT/firewall traversal by = using more techniques than were baked in. Matthew Kaufman From emil@sip-communicator.org Sun Jun 12 03:31:06 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5A311E807F for ; Sun, 12 Jun 2011 03:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOrfap80Z1qq for ; Sun, 12 Jun 2011 03:31:06 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF9BC11E8070 for ; Sun, 12 Jun 2011 03:31:05 -0700 (PDT) Received: by wwa36 with SMTP id 36so2666206wwa.13 for ; Sun, 12 Jun 2011 03:31:05 -0700 (PDT) Received: by 10.217.0.9 with SMTP id k9mr1039576wes.76.1307874664781; Sun, 12 Jun 2011 03:31:04 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id r20sm2295866wec.31.2011.06.12.03.31.03 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Jun 2011 03:31:03 -0700 (PDT) Message-ID: <4DF49566.2020709@jitsi.org> Date: Sun, 12 Jun 2011 12:31:02 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Harald Alvestrand References: , <4DF3DCB8.9090805@alvestrand.no> <4DF454DA.8030300@alvestrand.no> <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> <4DF48DA7.6080002@alvestrand.no> In-Reply-To: <4DF48DA7.6080002@alvestrand.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bernard Aboba , rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 10:31:06 -0000 =D0=9D=D0=B0 12.06.11 11:57, Harald Alvestrand =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: > I'd be happy to have a spec that allows us to run an "under the covers"= > fully compatible ICE implementation in the "normal case" (like what's > currently implemented in Google's libjingle/WebRTC code), and have an > extension (or another API spec) that allows "manual" driving of the STU= N > machinery, which we can agree on once it's proved viable. I'd be very > unhappy at this point to have only a spec that required a > partly-Javascript ICE implementation. +1 Besides, unless I've missed something, most of the arguments against an in-browser ICE implementation, like being able to use port-prediction, IPv6 tweaks, etc. are about the way an application would harvest candidat= es. If we agree on that then wouldn't it make sense to make that part extensible by applications (i.e. javascript), and have the rest handled by the browser? In other words, the browser could come with a set of default harvesters (i.e. host, stun, turn) and allow applications to provide additional ones. Connectivity checks, which are arguably where 90% of the ICE complexity is can be handled by the browser which would also worry timing and such. We've followed a similar model in ice4j.org and it has proven to be rather practical. Emil From tim@phonefromhere.com Sun Jun 12 04:21:57 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87DE11E80E1 for ; Sun, 12 Jun 2011 04:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBITAhlQeTLM for ; Sun, 12 Jun 2011 04:21:56 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id C03F611E8070 for ; Sun, 12 Jun 2011 04:21:56 -0700 (PDT) Received: from [192.168.0.21] (87-194-8-115.bethere.co.uk [87.194.8.115]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 1713137A8FC; Sun, 12 Jun 2011 12:31:44 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Tim Panton In-Reply-To: <4DF48EC4.6050800@jitsi.org> Date: Sun, 12 Jun 2011 12:21:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <4DF3DCB8.9090805@alvestrand.no> <4DF454DA.8030300@alvestrand.no> <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> <4DF48EC4.6050800@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 11:21:57 -0000 On 12 Jun 2011, at 11:02, Emil Ivov wrote: > =D0=9D=D0=B0 12.06.11 11:36, Tim Panton =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0= =B0: >> Maybe I've missed something, but to my mind there is no need for the >> javascript ICE's to interoperate with each other. All the users of >> XYZ-webconference service will load _exactly_the_same_ javascript - >> so for them to talk peer-to-peer the XYZ-ICE-lite implementation only >> has to interoperate with itself. >>=20 >> Are there important use-cases where we expect to have a visitor on >> XYZ.com web-page calling to ABC.com ? If we do then a baked in ICE=20 >> may be needed. >=20 > Unless we are planning on promoting a skype-like model where the = entire > world is stuck with the same provider and where PSTN is the only way = to > have some sort of interop ... then I'd say that inter-domain calls are > the only use case that we have to consider. >=20 Ok, we have explicit non-requirements that cross web site signalling=20 and auth are compatible (We push these issues up to the web service), = but we propose=20 to mandate that the ICE is identical ? I'm not clear why. Lets say in my hypothetical case of an XYZ.com page viewer talking to = an ABC.com viewer=20 both XYZ and ABC decide to support gtalk. Their web pages will have to = include an gtalk=20 compatible auth component to get the user's gtalk identity. It will also = have to include a gtalk compatible signalling layer. But we are balking at loading a suitable = ICE implementation? I still don't see a case where the site supplying an ICE implementation = is a problem, given that it already has to supply the signalling and auth code. Tim.= From ekr@rtfm.com Sun Jun 12 07:44:23 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BB811E80B2 for ; Sun, 12 Jun 2011 07:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8E3Dbg0fFDs for ; Sun, 12 Jun 2011 07:44:22 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD7211E80AB for ; Sun, 12 Jun 2011 07:44:22 -0700 (PDT) Received: by wwa36 with SMTP id 36so2734198wwa.13 for ; Sun, 12 Jun 2011 07:44:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.239.68 with SMTP id b46mr4105670wer.38.1307889861308; Sun, 12 Jun 2011 07:44:21 -0700 (PDT) Received: by 10.216.158.68 with HTTP; Sun, 12 Jun 2011 07:44:21 -0700 (PDT) In-Reply-To: <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> References: <4DF3DCB8.9090805@alvestrand.no> <4DF454DA.8030300@alvestrand.no> <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> Date: Sun, 12 Jun 2011 07:44:21 -0700 Message-ID: From: Eric Rescorla To: Matthew Kaufman Content-Type: text/plain; charset=ISO-8859-1 Cc: Bernard Aboba , rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 14:44:23 -0000 On Sun, Jun 12, 2011 at 2:05 AM, Matthew Kaufman wrote: > > On Jun 12, 2011, at 7:55 AM, Harald Alvestrand wrote: > > On 06/12/2011 12:09 AM, Bernard Aboba wrote: > > These kind of "performance" arguments tend to fall victim to improvements in > technology, so even if they can be demonstrated to be true at a given point > in time, the argument may prove invalid years or even months down the > road. > > In this particular case, there have been some major improvements in > Javascript performance in recent browser releases, and it is quite possible > that those improvements may continue. > > Actually my worry is more the javascript model than absolute performance. My > tests with current browsers indicate that the timer resolutions for timed > events are on the order of magnitude of 10-50 msec, depending on browser, > and the single-threaded model of the Javascript event queue means that > response to timers depends on nothing else happening in that Javascript > context. While I'm not a Javascript expert, I haven't had any reassurance > that we can get around this from Javascript experts I've asked. > > The resolution of waking up for a timer on WinNT is 30 msec and only 15 msec > on WinXP and ICE works just fine there. > I am not at all convinced that for our use cases we need anything better > than ~100 msec, so your 50 msec is already twice as good. Remember that JS is single-threaded, so other parts of the app can easily starve you for much longer than this if they are carelessly written. That's why I'd like to see a demonstration in a site that is actually doing substantial other JS action. -Ekr From stefan.lk.hakansson@ericsson.com Sun Jun 12 07:52:33 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1F811E80E8 for ; Sun, 12 Jun 2011 07:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqGwbc+FoREq for ; Sun, 12 Jun 2011 07:52:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 499B011E80BE for ; Sun, 12 Jun 2011 07:52:32 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f2-4df4d2ae4ff8 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8F.12.20773.EA2D4FD4; Sun, 12 Jun 2011 16:52:31 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.208]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Sun, 12 Jun 2011 16:52:30 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Eric Rescorla , Matthew Kaufman Date: Sun, 12 Jun 2011 16:52:26 +0200 Thread-Topic: [rtcweb] Review of draft-kaufman-rtcweb-traversal Thread-Index: AcwpDzpk55tELAsTRCCBxarFSFHbawAANyww Message-ID: References: <4DF3DCB8.9090805@alvestrand.no> <4DF454DA.8030300@alvestrand.no> <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Bernard Aboba , "rtcweb@ietf.org" Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 14:52:33 -0000 =20 >> Actually my worry is more the javascript model than absolute=20 >performance. My >> tests with current browsers indicate that the timer=20 >resolutions for timed >> events are on the order of magnitude of 10-50 msec,=20 >depending on browser, >> and the single-threaded model of the Javascript event queue=20 >means that >> response to timers depends on nothing else happening in that=20 >Javascript >> context. While I'm not a Javascript expert, I haven't had=20 >any reassurance >> that we can get around this from Javascript experts I've asked. >> >> The resolution of waking up for a timer on WinNT is 30 msec=20 >and only 15 msec >> on WinXP and ICE works just fine there. >> I am not at all convinced that for our use cases we need=20 >anything better >> than ~100 msec, so your 50 msec is already twice as good. > >Remember that JS is single-threaded, so other parts of the app=20 >can easily >starve you for much longer than this if they are carelessly=20 >written. That's >why I'd like to see a demonstration in a site that is actually=20 >doing substantial >other JS action. And on a device at the lower end of the performance spectrum. --Stefan > >-Ekr >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb >= From harald@alvestrand.no Sun Jun 12 08:45:41 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C70311E80A9 for ; Sun, 12 Jun 2011 08:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.336 X-Spam-Level: X-Spam-Status: No, score=-102.336 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vty-QHjDKHFb for ; Sun, 12 Jun 2011 08:45:40 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 22D3211E80AC for ; Sun, 12 Jun 2011 08:45:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AFCEB39E0BC; Sun, 12 Jun 2011 17:44:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxvrPyYJAUUB; Sun, 12 Jun 2011 17:44:39 +0200 (CEST) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id BAB3439E074; Sun, 12 Jun 2011 17:44:39 +0200 (CEST) Message-ID: <4DF4DF1F.9060101@alvestrand.no> Date: Sun, 12 Jun 2011 17:45:35 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Tim Panton References: , <4DF3DCB8.9090805@alvestrand.no> <4DF454DA.8030300@alvestrand.no> <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 15:45:41 -0000 On 06/12/2011 11:36 AM, Tim Panton wrote: > On 12 Jun 2011, at 10:05, Matthew Kaufman wrote: > >> On Jun 12, 2011, at 7:55 AM, Harald Alvestrand wrote: >> >>> On 06/12/2011 12:09 AM, Bernard Aboba wrote: >>>> >>>> To my mind, the real question isn't performance, it is interoperability. The "monolithic" approach to ICE brings with it the potential for interoperability problems between different browsers operating on the same service. Mathew's approach of Javascript implementation in ICE addresses that issue, but I'm concerned about the implications for cross-service interoperability. >>> One of my implementor colleagues claims (in another context) that a main difference between an embedded-in-browser implementation and a Javascript one is that the browser one has less than 10 significant implementations that have to interoperate, while the Javascript one will have an essentially unbounded number of implementations ("millions of web pages"). His conclusion was that for the things we need to get right in order to have interoperability (for the case we were discussing, which was not ICE), it's better to have them embedded in the browser than to depend on Javascript. >> This is actually the only good argument I've heard... that if the "right" implementation is baked into browsers then it will "just work". On the other hand, we have numerous examples of things that are baked into browsers that would be much more useful/flexible if they weren't... or at the very least offered both options. (And the future flexibility requirements around IPv6 are certainly a hint of why we might need this, in addition to service providers with non-standard needs.) > Maybe I've missed something, but to my mind there is no need for the javascript ICE's to interoperate with each other. All the users of XYZ-webconference service will load _exactly_the_same_ javascript - so for them to talk peer-to-peer the XYZ-ICE-lite implementation only has to interoperate with itself. > > Are there important use-cases where we expect to have a visitor on XYZ.com web-page calling to ABC.com ? If we do then a baked in ICE > may be needed. We've spent a number of messages touting scenarios where one application running in one browser would use a webserver to set up a media path to a different application running in another browser, possibly via gateways in the signalling path. Basically all but the first scenario from Jonathan Rosenberg's presentation in Prague fall into this category (the one I copied my illustrations from in the presentation from last Tuesday). Hm... in draft-holmberg-rtcweb-ucreqs, only the last scenario (telephony interoperation) describes this need, and that scenario could also be handled with a media transcoder. We may need to add some scenarios to that document if we want to make sure we capture the other scenarios in the requirements. Harald From randell1@jesup.org Sun Jun 12 09:04:28 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5321C11E80ED for ; Sun, 12 Jun 2011 09:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYLiVF+pap8X for ; Sun, 12 Jun 2011 09:04:27 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id C9DAB11E80A1 for ; Sun, 12 Jun 2011 09:04:27 -0700 (PDT) Received: from pool-71-185-223-77.phlapa.fios.verizon.net ([71.185.223.77] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QVn9H-0003kk-68 for rtcweb@ietf.org; Sun, 12 Jun 2011 11:04:27 -0500 Message-ID: <4DF4E307.7030609@jesup.org> Date: Sun, 12 Jun 2011 12:02:15 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: [rtcweb] Response to old message about CNAMEs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 16:04:28 -0000 Magnus wrote: >> David Singer skrev 2011-04-18 20:10: >> >> If I am doing a point-to-point call, and I have the connectivity >> established (i.e. IP addresses and the like), why should I trouble at >> all with CNAME? And, indeed, are there privacy concerns with it >> (well, there are with using @, I rather suspect). Can >> the CNAME problem be handled when aggregation happens? > >Because you don't know when a peer is a single user, or a conference >bridge. In the later case of you will need the cname. Also for point to >point you might need it if you have multiple sources that should or >should not be synchronized. The point of the new RFC is that the cname >can be set session specific, by drawing a random number that is being >used. Thus you can avoid the downsides of CNAME from privacy point of >view, and the generation aspects. (Working on catching up with traffic on this list... you may see some more answers to old messages) The bridge aspect is a strong example. Another random obvious example: even a single user might be sending multiple A/V pairs, which need to be synced to each other, but do not necessarily need to be synced to each other, or multiple non-synchronized audio streams. -- Randell Jesup randell-ietf@jesup.org From randell1@jesup.org Sun Jun 12 09:33:18 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2EF1F0C36 for ; Sun, 12 Jun 2011 09:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGrzdpxWQ+9J for ; Sun, 12 Jun 2011 09:33:18 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 7103B1F0C35 for ; Sun, 12 Jun 2011 09:33:18 -0700 (PDT) Received: from pool-71-185-223-77.phlapa.fios.verizon.net ([71.185.223.77] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QVnbB-0006b2-Vn for rtcweb@ietf.org; Sun, 12 Jun 2011 11:33:18 -0500 Message-ID: <4DF4E9CA.8040101@jesup.org> Date: Sun, 12 Jun 2011 12:31:06 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4DF3DCB8.9090805@alvestrand.no> <4DF454DA.8030300@alvestrand.no> <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 16:33:19 -0000 On 6/12/2011 10:52 AM, Stefan Håkansson LK wrote: > >> Remember that JS is single-threaded, so other parts of the app >> can easily >> starve you for much longer than this if they are carelessly >> written. That's >> why I'd like to see a demonstration in a site that is actually >> doing substantial >> other JS action. > And on a device at the lower end of the performance spectrum. > --Stefan Yes! Please remember that while desktops have unheard-of performance compared to 10 or even 5 years ago, an ever-increasing use-case for browsers and applications are smartphones and tablets that have an order of magnitude (or more) less performance (even with JITs) compared to desktops. They will get better in terms of performance, but even if they get fast (dual/quad core, higher clock rates, etc), that speed comes at a price - for mobile devices it's more an issue of energy expended once a certain amount of performance has been obtained. So even if the mobile device *can* run a pure-JS implementation fast enough, it may expend several times more energy in order to do so. Now, in some cases that doesn't matter - it's a one-time-ish operation. But in others it matters a lot (media), and there's a gray area inbetween (moderately-frequent or rare-but-expensive operations). It's something that needs to be considered before a decision is made. It doesn't mean JS is the wrong choice, just that raw performance (especially on a desktop) isn't the (only) bar to judge against. The other recently-mentioned point is very important - lack of threading in JS may cause RT or semi-RT operations needed for "call" setup or in-"call" things to be seriously delayed. We should verify this and options for dealing with it with some JS experts. (Brendan, are you here? ;-) (Note: still catching up and haven't read the proposal itself yet; just the last few messages discussing it.) -- Randell Jesup randell-ietf@jesup.org From dzonatas@gmail.com Sun Jun 12 09:50:06 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BEB11E80BB for ; Sun, 12 Jun 2011 09:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.951 X-Spam-Level: X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[AWL=-2.352, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJSRu5eS2fCI for ; Sun, 12 Jun 2011 09:50:06 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC20611E80AE for ; Sun, 12 Jun 2011 09:50:05 -0700 (PDT) Received: by pvh18 with SMTP id 18so1996194pvh.31 for ; Sun, 12 Jun 2011 09:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7R2+i9qPecD/LLEUqcKguDDSJY09gFdhc388PhUyLDA=; b=wrOXxQPHEwXsZWYT1dSWssujQIIjqLX33KSqeGIlgfzMWoEQ4oPP/htKo/ByrBjcJW yX2marBk7LD7bmFCEZWkc+1DjW4O7ydFnhyJZKApCQjdvMjOu+kSkw7EHWpkz/1gEttF za7sqT0VSDS0P0YWFkGJrx4WhLKGaBU7Y8tHE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=BZ5mDwOcE/iOX5eIy0+toTGZkgJqL5IVTNnFe7slWuTYHTaWJVBMa5H/cQtsPH4YYt LPA2xuo1idieQU8Pen+h6z1dodHjKL7KpY76qFO9u662MX7LPYkShug3AMR9n4yYi2FC z7bg6DDoaDSNgKKtrE0rQXfD/cuQq9ClUuiCg= Received: by 10.142.152.27 with SMTP id z27mr248361wfd.271.1307897405524; Sun, 12 Jun 2011 09:50:05 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id v6sm5079474wfe.2.2011.06.12.09.50.03 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Jun 2011 09:50:04 -0700 (PDT) Message-ID: <4DF4EDF4.60502@gmail.com> Date: Sun, 12 Jun 2011 09:48:52 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: , <4DF3DCB8.9090805@alvestrand.no> <4DF454DA.8030300@alvestrand.no> <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> <4DF48DA7.6080002@alvestrand.no> In-Reply-To: <4DF48DA7.6080002@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 16:50:06 -0000 On 06/12/2011 02:57 AM, Harald Alvestrand wrote: > On 06/12/2011 11:05 AM, Matthew Kaufman wrote: >> >> On Jun 12, 2011, at 7:55 AM, Harald Alvestrand wrote: >> >>> On 06/12/2011 12:09 AM, Bernard Aboba wrote: >>>> These kind of "performance" arguments tend to fall victim to >>>> improvements in technology, so even if they can be demonstrated to >>>> be true at a given point in time, the argument may prove invalid >>>> years or even months down the road. >>>> >>>> In this particular case, there have been some major improvements in >>>> Javascript performance in recent browser releases, and it is quite >>>> possible that those improvements may continue. >>> Actually my worry is more the javascript model than absolute >>> performance. My tests with current browsers indicate that the timer >>> resolutions for timed events are on the order of magnitude of 10-50 >>> msec, depending on browser, and the single-threaded model of the >>> Javascript event queue means that response to timers depends on >>> nothing else happening in that Javascript context. While I'm not a >>> Javascript expert, I haven't had any reassurance that we can get >>> around this from Javascript experts I've asked. >> >> The resolution of waking up for a timer on WinNT is 30 msec and only >> 15 msec on WinXP and ICE works just fine there. >> >> I am not at all convinced that for our use cases we need anything >> better than ~100 msec, so your 50 msec is already twice as good. > The shortest timer in RFC 5245 (as far as I can see) is Ta (section > 16.1), which has a lower bound of 20 msec; however, this is a lower > bound on transmission intervals, so it's possible that an > implementation that fires only every 100 msec would be perfectly > interoperable with an application that fires every 20 msec. > > Testing will show.... If there is some simple way to add something like the "Expires:" header then this may help settle the case of what is "real" per second across the page (legal size or 16:9). I can think of arguments against that and possible expansion yet synchronization simplicity and reimplementation avoidance is the possibility I had in mind to avoid further cost. What-if there are multiple script engines (or multiple browsers) on one page, so speed of one single javascript instance alone is not the best measurement (even in smaller msec). One oversimplified example, let's say there are multiple tapes with date stamp per frame, and they are all played randomly. In this example, the system aligns the frames (per second) despite no guarantee each source starts with the same datestamp. Now scale that to colosseum size with added info for GPS, focal length, and direction where everybody records or recorded some part of any sports event. Another example is in skeletal animation of multiple dancers. There are options that help automate alignment of each playback of dance moves among couples or several groups of people across each viewer. The significance is is the possible synchronization of less than per "real" second. Complexity varies in ability to decentralize from simulcast, yet we can assume some kind of tether exists, physical or tangible (in traversal). Some may get the gist of this for other use-cases. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From bernard_aboba@hotmail.com Sun Jun 12 10:30:04 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DC511E80E8 for ; Sun, 12 Jun 2011 10:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp2Pkh31Gb8i for ; Sun, 12 Jun 2011 10:30:03 -0700 (PDT) Received: from blu0-omc3-s37.blu0.hotmail.com (blu0-omc3-s37.blu0.hotmail.com [65.55.116.112]) by ietfa.amsl.com (Postfix) with ESMTP id ABA7D11E80AE for ; Sun, 12 Jun 2011 10:30:03 -0700 (PDT) Received: from BLU152-W24 ([65.55.116.74]) by blu0-omc3-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Jun 2011 10:30:03 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_94323b45-75ed-4026-93f2-a8f8b73ef671_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: Date: Sun, 12 Jun 2011 10:30:02 -0700 Importance: Normal In-Reply-To: References: , <4DF3DCB8.9090805@alvestrand.no>, , <4DF454DA.8030300@alvestrand.no>, <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net>, , MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jun 2011 17:30:03.0250 (UTC) FILETIME=[5CFD4520:01CC2926] Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 17:30:05 -0000 --_94323b45-75ed-4026-93f2-a8f8b73ef671_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Emil Ivov said: Besides=2C unless I've missed something=2C most of the arguments against = an in-browser ICE implementation=2C like being able to use port-prediction= =2C IPv6 tweaks=2C etc. are about the way an application would harvest candid= ates. [BA] Many of the choices arise in formulating (and responding) to an offer. >From RFC 5245 Section 4: In order to send the initial offer in an offer/answer exchange=2C an agent must (1) gather candidates=2C (2) prioritize them=2C (3) eliminate redundant candidates=2C (4) choose default candidates=2C and then (5) formulate and send the SDP offer. Emil Ivov also said: If we agree on that then wouldn't it make sense to make that part extensible by applications (i.e. javascript)=2C and have the rest handl= ed by the browser? In other words=2C the browser could come with a set of default harvesters (i.e. host=2C stun=2C turn) and allow applications t= o provide additional ones. Connectivity checks=2C which are arguably where 90% of the ICE complexit= y is can be handled by the browser which would also worry timing and such. We've followed a similar model in ice4j.org and it has proven to be rather practical. [BA] I'd agree that the time-critical portions can be handled by the browser while still preserving much of the flexibility that Mathew's draft argues for. So it isn't just a choice between "all in the browser" or "all but STUN/TURN in Javascript". Harald said: One of my implementor colleagues claims (in another context) that a main difference between an embedded-in-browser implementation and a javascrip= t one is that the browser one has less than 10 significant implementations that have to interoperate [BA] Based on the recent SIPIt summaries=2C it seems that we still have a w= ay to go before demonstrating interop between 10 ICE implementations: https://www.sipit.net/SIPit23_Summary https://www.sipit.net/SIPit24_Summary https://www.sipit.net/SIPit26_Summary https://www.sipit.net/SIPit27_Summary To understand the challenges=2C it might be useful to go over the ICE inter= op learnings at IETF 81.=20 Harald also said: Hm... in draft-holmberg-rtcweb-ucreqs=2C only the last scenario (teleph= ony=20 interoperation)=20 describes this need=2C and that scenario could also be=20 handled with a media transcoder.=20 We may need to add some scenarios to=20 that document if we want to make sure we capture=20 the other scenarios in=20 the requirements. [BA] That sounds like a good idea.=20 = --_94323b45-75ed-4026-93f2-a8f8b73ef671_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Emil Ivov said:

 =3B Besides=2C unless I've missed something=2C = most of the arguments against an
 =3B in-browser ICE implementation= =2C like being able to use port-prediction=2C
 =3B IPv6 tweaks=2C et= c. are about the way an application would harvest candidates.

[BA] M= any of the choices arise in formulating (and responding) to an offer.
Fr= om RFC 5245 Section 4:

 =3B =3B In order to send the initial= offer in an offer/answer exchange=2C an
 =3B =3B agent must (1)= gather candidates=2C (2) prioritize them=2C (3) eliminate
 =3B = =3B redundant candidates=2C (4) choose default candidates=2C and then (5) =3B =3B formulate and send the SDP offer.

Emil Ivov also = said:

 =3B =3B =3B If we agree on that then wouldn't it = make sense to make that part
 =3B =3B =3B extensible by appl= ications (i.e. javascript)=2C and have the rest handled
 =3B =3B=  =3B by the browser? In other words=2C the browser could come with a se= t of
 =3B =3B =3B default harvesters (i.e. host=2C stun=2C t= urn) and allow applications to
 =3B =3B =3B provide addition= al ones.

 =3B =3B Connectivity checks=2C which are arguably = where 90% of the ICE complexity
 =3B =3B is can be handled by th= e browser which would also worry timing and such.
 =3B =3B We've= followed a similar model in ice4j.org and it has proven to be
 =3B&= nbsp=3B rather practical.

[BA] I'd agree that the time-critical port= ions can be handled by the
browser while still preserving much of the fl= exibility that Mathew's
draft argues for. =3B =3B So it isn't ju= st a choice between "all in the browser"
or "all but STUN/TURN in Javasc= ript".

Harald said:

 =3B =3B One of my implementor co= lleagues claims (in another context) that a main
 =3B =3B differ= ence between an embedded-in-browser implementation and a javascript
&nbs= p=3B =3B one is that the browser one has less than 10 significant imple= mentations
 =3B =3B that have to interoperate

[BA] Based = on the recent SIPIt summaries=2C it seems that we still have a way to go be= fore demonstrating interop between 10 ICE implementations:

https://w= ww.sipit.net/SIPit23_Summary
https://www.sipit.net/SIPit24_Summary
ht= tps://www.sipit.net/SIPit26_Summary
https://www.sipit.net/SIPit27_Summar= y

To understand the challenges=2C it might be useful to go over the = ICE interop learnings at IETF 81.

Harald also said:

&nbs= p=3B =3B =3B Hm... in draft-holmberg-rtcweb-ucreqs=2C only the last= scenario (telephony=20 interoperation)
 =3B =3B =3B describes this need= =2C and that scenario could also be=20 handled with a media transcoder.
 =3B =3B =3B We m= ay need to add some scenarios to=20 that document if we want to make sure we capture
 =3B = =3B =3B the other scenarios in=20 the requirements.

[BA] That sounds like a good i= dea.
= --_94323b45-75ed-4026-93f2-a8f8b73ef671_-- From bernard_aboba@hotmail.com Sun Jun 12 11:55:57 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD6C11E8114 for ; Sun, 12 Jun 2011 11:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-SWW5zDfnoj for ; Sun, 12 Jun 2011 11:55:56 -0700 (PDT) Received: from blu0-omc3-s6.blu0.hotmail.com (blu0-omc3-s6.blu0.hotmail.com [65.55.116.81]) by ietfa.amsl.com (Postfix) with ESMTP id A9D2A11E810A for ; Sun, 12 Jun 2011 11:55:56 -0700 (PDT) Received: from BLU152-W23 ([65.55.116.73]) by blu0-omc3-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Jun 2011 11:55:56 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_350d0d1a-853b-4670-8722-d8c2573bdb3c_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: Date: Sun, 12 Jun 2011 11:55:55 -0700 Importance: Normal In-Reply-To: References: , <4DF3DCB8.9090805@alvestrand.no>, , <4DF454DA.8030300@alvestrand.no>, <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net>, , , MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jun 2011 18:55:56.0414 (UTC) FILETIME=[5C83B1E0:01CC2932] Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 18:55:57 -0000 --_350d0d1a-853b-4670-8722-d8c2573bdb3c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Emil said:=20 Connectivity checks=2C which are arguably where 90% of the ICE complexit= y is can be handled by the browser which would also worry timing and such. We've followed a similar model in ice4j.org and it has proven to be rather practical. [BA] The issue here is not just performance/flexibility=2C there are archit= ectural implications as well. If we assume that it necessary to allow vari= ation in signaling=2C then the signaling and connectivity checking function= s of ICE cannot be combined into a single "monolithic" implementation in th= e browser. For example=2C the actual SDP negotiation may be handled with= in a Javascript library supporting a given signaling approach (e.g. Strophe= for XMPP). However=2C to enable the building of an offer (and response)= =2C the ICE candidates need to be gathered=2C prioritized=2C etc. This imp= lies the creation of APIs to support this. After the (implementation depen= dent) offer/answer is completed=2C then the connectivity checking portion c= an be handled natively in the browser=2C but you have to have some API supp= ort to enable getting to that point. = --_350d0d1a-853b-4670-8722-d8c2573bdb3c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Emil said:

 =3B =3B Connectivity checks=2C which are arguab= ly where 90% of the ICE complexity
 =3B =3B is can be handled by= the browser which would also worry timing and such.
 =3B =3B We= 've followed a similar model in ice4j.org and it has proven to be
 = =3B =3B rather practical.

[BA] The issue here is not just perfor= mance/flexibility=2C there are architectural implications as well. =3B = If we assume that it necessary to allow variation in signaling=2C then the = signaling and connectivity checking functions of ICE cannot be combined int= o a single "monolithic" implementation in the browser. =3B =3B For = example=2C =3B the actual SDP negotiation may be handled within a Javas= cript library supporting a given signaling approach (e.g. Strophe for XMPP)= . =3B =3B However=2C to enable the building of an offer (and respon= se)=2C the ICE candidates need to be gathered=2C prioritized=2C etc. = =3B This implies the creation of APIs to support this. =3B After the (i= mplementation dependent) offer/answer is completed=2C then the connectivity= checking portion can be handled natively in the browser=2C but you have to= have some API support to enable getting to that point.
= --_350d0d1a-853b-4670-8722-d8c2573bdb3c_-- From emil@sip-communicator.org Sun Jun 12 15:16:19 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B0011E8127 for ; Sun, 12 Jun 2011 15:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-YjWbRbDnTg for ; Sun, 12 Jun 2011 15:16:18 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7230311E8118 for ; Sun, 12 Jun 2011 15:16:16 -0700 (PDT) Received: by wyb29 with SMTP id 29so3289664wyb.31 for ; Sun, 12 Jun 2011 15:16:15 -0700 (PDT) Received: by 10.216.28.1 with SMTP id f1mr4499739wea.41.1307916974883; Sun, 12 Jun 2011 15:16:14 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id k70sm2576712weq.6.2011.06.12.15.16.12 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Jun 2011 15:16:13 -0700 (PDT) Message-ID: <4DF53AAB.20808@jitsi.org> Date: Mon, 13 Jun 2011 00:16:11 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bernard Aboba References: , <4DF3DCB8.9090805@alvestrand.no>, , <4DF454DA.8030300@alvestrand.no>, <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net>, , , In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 22:16:19 -0000 =D0=9D=D0=B0 12.06.11 20:55, Bernard Aboba =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > Emil said: >=20 > Connectivity checks, which are arguably where 90% of the ICE complex= ity > is can be handled by the browser which would also worry timing and s= uch. > We've followed a similar model in ice4j.org and it has proven to be > rather practical. >=20 > [BA] The issue here is not just performance/flexibility, there are > architectural implications as well. If we assume that it necessary to > allow variation in signaling, then the signaling and connectivity > checking functions of ICE cannot be combined into a single "monolithic"= > implementation in the browser.=20 When you say signalling, do you mean the exchange of candidates between peers? If so, and provided we are not to pick a signalling protocol here, then of course, this should most definitely be outside the ICE impl and left to the javascript, just as it would be the case with a regular application and an ICE stack. > For example, the actual SDP > negotiation may be handled within a Javascript library supporting a > given signaling approach (e.g. Strophe for XMPP). Right. > However, to enable > the building of an offer (and response), the ICE candidates need to be > gathered, prioritized, etc. This implies the creation of APIs to > support this.=20 Right. > After the (implementation dependent) offer/answer is > completed, then the connectivity checking portion can be handled > natively in the browser, but you have to have some API support to enabl= e > getting to that point. Yes. Basically the browser would act as the ICE stack and the javascript as the application. Emil From harald@alvestrand.no Mon Jun 13 01:00:05 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D16011E8077 for ; Mon, 13 Jun 2011 01:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-VSx5gKu+0f for ; Mon, 13 Jun 2011 01:00:03 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBEC11E8073 for ; Mon, 13 Jun 2011 01:00:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 835E039E08B; Mon, 13 Jun 2011 09:59:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+HaCpMxq036; Mon, 13 Jun 2011 09:59:03 +0200 (CEST) Received: from [172.16.33.81] (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id A3B9B39E082; Mon, 13 Jun 2011 09:59:01 +0200 (CEST) Message-ID: <4DF5C37D.2060709@alvestrand.no> Date: Mon, 13 Jun 2011 09:59:57 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bernard Aboba References: , <4DF3DCB8.9090805@alvestrand.no>, , <4DF454DA.8030300@alvestrand.no>, <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net>, , , In-Reply-To: Content-Type: multipart/alternative; boundary="------------050101070301070909050305" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 08:00:05 -0000 This is a multi-part message in MIME format. --------------050101070301070909050305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/12/11 20:55, Bernard Aboba wrote: > Emil said: > > Connectivity checks, which are arguably where 90% of the ICE complexity > is can be handled by the browser which would also worry timing and > such. > We've followed a similar model in ice4j.org and it has proven to be > rather practical. > > [BA] The issue here is not just performance/flexibility, there are > architectural implications as well. If we assume that it necessary to > allow variation in signaling, then the signaling and connectivity > checking functions of ICE cannot be combined into a single > "monolithic" implementation in the browser. For example, the actual > SDP negotiation may be handled within a Javascript library supporting > a given signaling approach (e.g. Strophe for XMPP). SDP or mechanisms of similar expressive power, yes. > However, to enable the building of an offer (and response), the ICE > candidates need to be gathered, prioritized, etc. This implies the > creation of APIs to support this. After the (implementation > dependent) offer/answer is completed, then the connectivity checking > portion can be handled natively in the browser, but you have to have > some API support to enable getting to that point. I think we agree on that point (that you have to have some API support to enable getting to that point). In the WHATWG proposal, that interface consists of SDP blobs thrown across the JS/browser interface; in the Google RTCWeb implementation, that interface consists of JSON blobs thrown in the same fashion. It's possible to write a JS app that just passes these blobs to a backend - or one can have a JS app that parses the blobs and does more with them before sending them off to wherever they need to go - but it's kind of obvious that these blobs need to contain the ICE candidates that the other end should learn about. --------------050101070301070909050305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/12/11 20:55, Bernard Aboba wrote:
Emil said:

   Connectivity checks, which are arguably where 90% of the ICE complexity
   is can be handled by the browser which would also worry timing and such.
   We've followed a similar model in ice4j.org and it has proven to be
   rather practical.

[BA] The issue here is not just performance/flexibility, there are architectural implications as well.  If we assume that it necessary to allow variation in signaling, then the signaling and connectivity checking functions of ICE cannot be combined into a single "monolithic" implementation in the browser.   For example,  the actual SDP negotiation may be handled within a Javascript library supporting a given signaling approach (e.g. Strophe for XMPP).
SDP or mechanisms of similar expressive power, yes.
  However, to enable the building of an offer (and response), the ICE candidates need to be gathered, prioritized, etc.  This implies the creation of APIs to support this.  After the (implementation dependent) offer/answer is completed, then the connectivity checking portion can be handled natively in the browser, but you have to have some API support to enable getting to that point.
I think we agree on that point (that you have to have some API support to enable getting to that point). In the WHATWG proposal, that interface consists of SDP blobs thrown across the JS/browser interface; in the Google RTCWeb implementation, that interface consists of JSON blobs thrown in the same fashion. It's possible to write a JS app that just passes these blobs to a backend - or one can have a JS app that parses the blobs and does more with them before sending them off to wherever they need to go - but it's kind of obvious that these blobs need to contain the ICE candidates that the other end should learn about.


--------------050101070301070909050305-- From harald@alvestrand.no Mon Jun 13 05:14:18 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481379E8008 for ; Mon, 13 Jun 2011 05:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_53=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T2RtjyD7J5l for ; Mon, 13 Jun 2011 05:14:17 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B26819E8004 for ; Mon, 13 Jun 2011 05:14:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C4C5139E08B for ; Mon, 13 Jun 2011 14:13:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W89sCa4zVIEF for ; Mon, 13 Jun 2011 14:13:16 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 0680239E082 for ; Mon, 13 Jun 2011 14:13:15 +0200 (CEST) Message-ID: <4DF5FF13.6020201@alvestrand.no> Date: Mon, 13 Jun 2011 14:14:11 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] RTP multiplexing - my understanding of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 12:14:18 -0000 I thought I'd try to capture my understanding of the state of play wrt RTP multiplexing as of the end of Wednesday's meeting. As I understand it, we have two possibilities for guidelines, and the difference between them can be decided on whether it's technically feasible or not to put audio and video into the same RTP session. (for the sake of clarity of argument, I'm claiming that only two types of media exist: audio and video, and I'm ignoring the question of additional sessions for FEC. It's simpler to see what we come out with that way.) ------------------------------------------------- 1) draft-perkins-rtcweb-rtp-usage, as clarified in discussion: Each RTCWEB user has two RTP sessions active. All outgoing and incoming audio channels go on one RTP session; all outgoing and incoming RTP sessions go on the other RTP session. Audio and video from a single user is correlated based on the CNAME; the SSRC for streams with the same CNAME can be different in the two RTP sessions. Each RTP session, together with its RTCP data, is carried over a single pair of ports (5-tuple, for those who prefer that terminology) between each pair of participants. The RTP sessions are bidirectional. (Note: in draft-holmberg's scenario 4.3, multiparty without central server, there are multiple participants; I don't know if this would have only one pair of RTP sessions or one per pair.) 2) A not-yet-written-up alternative: Each RTCWEB user has one RTP session active. Audio and video both use the same RTP session. Streams from the same user all have the same CNAME; the audio and video stream [must have different SSRCs|can have the same SSRC|must have the same SSRC]. All data between two participants is carried over a single 5-tuple. ------------------------------------------- I recognize that this is a gross simplification that glosses over significant detail, but ... can we agree that this is a roughly correct description of the alternatives we were talking about? Harald From csp@csperkins.org Mon Jun 13 05:29:31 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE47B9E8010 for ; Mon, 13 Jun 2011 05:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.936 X-Spam-Level: X-Spam-Status: No, score=-102.936 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k6+WO7-5aET for ; Mon, 13 Jun 2011 05:29:31 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id 03BB49E8009 for ; Mon, 13 Jun 2011 05:29:31 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QW6Ev-0005IW-kd; Mon, 13 Jun 2011 12:27:33 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4DF5FF13.6020201@alvestrand.no> Date: Mon, 13 Jun 2011 13:27:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <88C5F73E-E612-4DBE-B2DA-08D905CC2D8D@csperkins.org> References: <4DF5FF13.6020201@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP multiplexing - my understanding of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 12:29:31 -0000 On 13 Jun 2011, at 13:14, Harald Alvestrand wrote: > I thought I'd try to capture my understanding of the state of play wrt = RTP multiplexing as of the end of Wednesday's meeting. >=20 > As I understand it, we have two possibilities for guidelines, and the = difference between them can be decided on whether it's technically = feasible or not to put audio and video into the same RTP session. >=20 > (for the sake of clarity of argument, I'm claiming that only two types = of media exist: audio and video, and I'm ignoring the question of = additional sessions for FEC. It's simpler to see what we come out with = that way.) >=20 > ------------------------------------------------- >=20 > 1) draft-perkins-rtcweb-rtp-usage, as clarified in discussion: >=20 > Each RTCWEB user has two RTP sessions active. All outgoing and = incoming audio channels go on one RTP session; all outgoing and incoming = RTP sessions go on the other RTP session. >=20 > Audio and video from a single user is correlated based on the CNAME; = the SSRC for streams with the same CNAME can be different in the two RTP = sessions. >=20 > Each RTP session, together with its RTCP data, is carried over a = single pair of ports (5-tuple, for those who prefer that terminology) = between each pair of participants. The RTP sessions are bidirectional. >=20 > (Note: in draft-holmberg's scenario 4.3, multiparty without central = server, there are multiple participants; I don't know if this would have = only one pair of RTP sessions or one per pair.) >=20 > 2) A not-yet-written-up alternative: >=20 > Each RTCWEB user has one RTP session active. Audio and video both use = the same RTP session. Streams from the same user all have the same = CNAME; the audio and video stream [must have different SSRCs|can have = the same SSRC|must have the same SSRC]. >=20 > All data between two participants is carried over a single 5-tuple. >=20 > ------------------------------------------- > I recognize that this is a gross simplification that glosses over = significant detail, but ... can we agree that this is a roughly correct = description of the alternatives we were talking about? RTP requires some lower-layer demultiplexing point to identify sessions. = A third alternative is to introduce some shim-layer between RTP and UDP = that can provide this demultiplexing point. This has the advantage that = it also only uses a single 5-tuple, but unlike option 2, doesn't break = the RTP protocol. --=20 Colin Perkins http://csperkins.org/ From harald@alvestrand.no Mon Jun 13 05:34:26 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317EB9E8011 for ; Mon, 13 Jun 2011 05:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_53=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEqyLPe4zprq for ; Mon, 13 Jun 2011 05:34:25 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6984E9E8010 for ; Mon, 13 Jun 2011 05:34:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3445239E08B; Mon, 13 Jun 2011 14:33:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVk5qsVpZzPE; Mon, 13 Jun 2011 14:33:27 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 4118239E082; Mon, 13 Jun 2011 14:33:27 +0200 (CEST) Message-ID: <4DF603CF.7040601@alvestrand.no> Date: Mon, 13 Jun 2011 14:34:23 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Colin Perkins References: <4DF5FF13.6020201@alvestrand.no> <88C5F73E-E612-4DBE-B2DA-08D905CC2D8D@csperkins.org> In-Reply-To: <88C5F73E-E612-4DBE-B2DA-08D905CC2D8D@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP multiplexing - my understanding of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 12:34:26 -0000 On 06/13/11 14:27, Colin Perkins wrote: > On 13 Jun 2011, at 13:14, Harald Alvestrand wrote: >> I thought I'd try to capture my understanding of the state of play wrt RTP multiplexing as of the end of Wednesday's meeting. >> >> As I understand it, we have two possibilities for guidelines, and the difference between them can be decided on whether it's technically feasible or not to put audio and video into the same RTP session. >> >> (for the sake of clarity of argument, I'm claiming that only two types of media exist: audio and video, and I'm ignoring the question of additional sessions for FEC. It's simpler to see what we come out with that way.) >> >> ------------------------------------------------- >> >> 1) draft-perkins-rtcweb-rtp-usage, as clarified in discussion: >> >> Each RTCWEB user has two RTP sessions active. All outgoing and incoming audio channels go on one RTP session; all outgoing and incoming RTP sessions go on the other RTP session. >> >> Audio and video from a single user is correlated based on the CNAME; the SSRC for streams with the same CNAME can be different in the two RTP sessions. >> >> Each RTP session, together with its RTCP data, is carried over a single pair of ports (5-tuple, for those who prefer that terminology) between each pair of participants. The RTP sessions are bidirectional. >> >> (Note: in draft-holmberg's scenario 4.3, multiparty without central server, there are multiple participants; I don't know if this would have only one pair of RTP sessions or one per pair.) >> >> 2) A not-yet-written-up alternative: >> >> Each RTCWEB user has one RTP session active. Audio and video both use the same RTP session. Streams from the same user all have the same CNAME; the audio and video stream [must have different SSRCs|can have the same SSRC|must have the same SSRC]. >> >> All data between two participants is carried over a single 5-tuple. >> >> ------------------------------------------- >> I recognize that this is a gross simplification that glosses over significant detail, but ... can we agree that this is a roughly correct description of the alternatives we were talking about? > > RTP requires some lower-layer demultiplexing point to identify sessions. A third alternative is to introduce some shim-layer between RTP and UDP that can provide this demultiplexing point. This has the advantage that it also only uses a single 5-tuple, but unlike option 2, doesn't break the RTP protocol. > Yes - the disadvantage is of course that it kills all hope of interoperability with any other RTP implementation; people may or may not think of that as "breaking the RTP protocol". An interesting property of RTP is that if a third party monitors two packet streams on different ports, I don't think he can tell whether they belong to the same RTP session or not - the tying of transport 5-tuples to RTP sessions is n-to-n, and must be done using singalling. Harald From csp@csperkins.org Mon Jun 13 05:37:43 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D098E9E8010 for ; Mon, 13 Jun 2011 05:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.859 X-Spam-Level: X-Spam-Status: No, score=-102.859 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6FRQq3yuVyI for ; Mon, 13 Jun 2011 05:37:43 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0883621F8462 for ; Mon, 13 Jun 2011 05:37:43 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QW6Ok-0003Pd-aO; Mon, 13 Jun 2011 12:37:42 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4DF603CF.7040601@alvestrand.no> Date: Mon, 13 Jun 2011 13:37:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2B253010-544E-424D-A665-9D12815C2863@csperkins.org> References: <4DF5FF13.6020201@alvestrand.no> <88C5F73E-E612-4DBE-B2DA-08D905CC2D8D@csperkins.org> <4DF603CF.7040601@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP multiplexing - my understanding of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 12:37:43 -0000 On 13 Jun 2011, at 13:34, Harald Alvestrand wrote: > On 06/13/11 14:27, Colin Perkins wrote: >> On 13 Jun 2011, at 13:14, Harald Alvestrand wrote: >>> I thought I'd try to capture my understanding of the state of play = wrt RTP multiplexing as of the end of Wednesday's meeting. >>>=20 >>> As I understand it, we have two possibilities for guidelines, and = the difference between them can be decided on whether it's technically = feasible or not to put audio and video into the same RTP session. >>>=20 >>> (for the sake of clarity of argument, I'm claiming that only two = types of media exist: audio and video, and I'm ignoring the question of = additional sessions for FEC. It's simpler to see what we come out with = that way.) >>>=20 >>> ------------------------------------------------- >>>=20 >>> 1) draft-perkins-rtcweb-rtp-usage, as clarified in discussion: >>>=20 >>> Each RTCWEB user has two RTP sessions active. All outgoing and = incoming audio channels go on one RTP session; all outgoing and incoming = RTP sessions go on the other RTP session. >>>=20 >>> Audio and video from a single user is correlated based on the CNAME; = the SSRC for streams with the same CNAME can be different in the two RTP = sessions. >>>=20 >>> Each RTP session, together with its RTCP data, is carried over a = single pair of ports (5-tuple, for those who prefer that terminology) = between each pair of participants. The RTP sessions are bidirectional. >>>=20 >>> (Note: in draft-holmberg's scenario 4.3, multiparty without central = server, there are multiple participants; I don't know if this would have = only one pair of RTP sessions or one per pair.) >>>=20 >>> 2) A not-yet-written-up alternative: >>>=20 >>> Each RTCWEB user has one RTP session active. Audio and video both = use the same RTP session. Streams from the same user all have the same = CNAME; the audio and video stream [must have different SSRCs|can have = the same SSRC|must have the same SSRC]. >>>=20 >>> All data between two participants is carried over a single 5-tuple. >>>=20 >>> ------------------------------------------- >>> I recognize that this is a gross simplification that glosses over = significant detail, but ... can we agree that this is a roughly correct = description of the alternatives we were talking about? >>=20 >> RTP requires some lower-layer demultiplexing point to identify = sessions. A third alternative is to introduce some shim-layer between = RTP and UDP that can provide this demultiplexing point. This has the = advantage that it also only uses a single 5-tuple, but unlike option 2, = doesn't break the RTP protocol. >>=20 > Yes - the disadvantage is of course that it kills all hope of = interoperability with any other RTP implementation; people may or may = not think of that as "breaking the RTP protocol". Option 2 cannot directly interoperate with standard RTP either. They = both need some form of gateway to separate the sessions.=20 Colin > An interesting property of RTP is that if a third party monitors two = packet streams on different ports, I don't think he can tell whether = they belong to the same RTP session or not - the tying of transport = 5-tuples to RTP sessions is n-to-n, and must be done using singalling. >=20 > Harald >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From salvatore.loreto@ericsson.com Mon Jun 13 07:45:01 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE389E8017 for ; Mon, 13 Jun 2011 07:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n29EzN+6XqKI for ; Mon, 13 Jun 2011 07:45:00 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 72DB59E8011 for ; Mon, 13 Jun 2011 07:44:55 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-4c-4df62266d06d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 54.F7.09774.66226FD4; Mon, 13 Jun 2011 16:44:54 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 13 Jun 2011 16:44:53 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9BB02231A for ; Mon, 13 Jun 2011 17:44:53 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 629D651052 for ; Mon, 13 Jun 2011 17:44:53 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1DD1550106 for ; Mon, 13 Jun 2011 17:44:53 +0300 (EEST) Message-ID: <4DF62264.6090802@ericsson.com> Date: Mon, 13 Jun 2011 17:44:52 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4DF29433.2080503@alcatel-lucent.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090709030700060004070506" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] How do we implement SIP event subscription in RTCweb? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 14:45:01 -0000 --------------090709030700060004070506 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit On 6/11/11 1:29 AM, Justin Uberti wrote: > > > On Fri, Jun 10, 2011 at 3:01 PM, Igor Faynberg > > wrote: > > A question. > > When SIP is implemented in an application within the present > RTCweb architecture, how exactly could we use WebSockets for > SUBSCRIBE/NOTIFY? > > It appears to me that the only way to achieve that is to open a > persistent connection. Am I right? > > > Yes, that is correct. This is how asynchronous web applications work > today. > > If so, is it not a problem, given the potential duration of such > connections and potential tie-up of network resources? > > > An unused TCP/WebSockets connection consumes very few resources. more there is also the intention in the HyBi wg to work on a MUX extension to the WebSocket protocol -- Salvatore Loreto www.sloreto.com --------------090709030700060004070506 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit On 6/11/11 1:29 AM, Justin Uberti wrote:


On Fri, Jun 10, 2011 at 3:01 PM, Igor Faynberg <igor.faynberg@alcatel-lucent.com> wrote:
A question.

When SIP is implemented in an application within the present RTCweb architecture, how exactly could we use WebSockets for SUBSCRIBE/NOTIFY?

It appears to me that the only way to achieve that is to open a persistent connection.  Am I right?

Yes, that is correct. This is how asynchronous web applications work today.
 
If so, is it not a problem, given the potential duration of such connections and potential tie-up of network resources?

An unused TCP/WebSockets connection consumes very few resources.

more there is also the intention in the HyBi wg to work on a MUX extension to the WebSocket protocol



-- 
Salvatore Loreto
www.sloreto.com
--------------090709030700060004070506-- From prvs=1384f3398=tterriberry@mozilla.com Mon Jun 13 08:28:54 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4688921F84DE for ; Mon, 13 Jun 2011 08:28:54 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OupsO7juzv9B for ; Mon, 13 Jun 2011 08:28:50 -0700 (PDT) Received: from mxip0i.isis.unc.edu (mxip0i.isis.unc.edu [152.2.0.72]) by ietfa.amsl.com (Postfix) with ESMTP id E656E21F84EB for ; Mon, 13 Jun 2011 08:28:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYIAKkr9k2sGgRa/2dsb2JhbABEDpdbjgOBU4hyvz6DGYMLBIcNjmgOiy4 X-IronPort-AV: E=Sophos;i="4.65,359,1304308800"; d="scan'208";a="157636213" Received: from mr2a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.90]) by mxip0o.isis.unc.edu with ESMTP; 13 Jun 2011 11:28:45 -0400 X-UNC-Auth-As: tterribe X-UNC-Auth-IP: 69.181.137.38 Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id p5DFShAJ018659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 13 Jun 2011 11:28:45 -0400 (EDT) Message-ID: <4DF62CAB.1070509@mozilla.com> Date: Mon, 13 Jun 2011 08:28:43 -0700 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 CC: "rtcweb@ietf.org" References: <4DF5FF13.6020201@alvestrand.no> <88C5F73E-E612-4DBE-B2DA-08D905CC2D8D@csperkins.org> <4DF603CF.7040601@alvestrand.no> <2B253010-544E-424D-A665-9D12815C2863@csperkins.org> In-Reply-To: <2B253010-544E-424D-A665-9D12815C2863@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTP multiplexing - my understanding of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 15:28:54 -0000 > On 13 Jun 2011, at 13:34, Harald Alvestrand wrote: >> On 06/13/11 14:27, Colin Perkins wrote: >>> On 13 Jun 2011, at 13:14, Harald Alvestrand wrote: >>>> Each RTCWEB user has two RTP sessions active. All outgoing and incoming >>>> audio channels go on one RTP session; all outgoing and incoming RTP >>>> sessions go on the other RTP session. s/sessions go/video goes/, I assume? >>>> 2) A not-yet-written-up alternative: >>>> >>>> Each RTCWEB user has one RTP session active. Audio and video both use the Allow me to make a suggestion for how this might work below... >>> RTP requires some lower-layer demultiplexing point to identify sessions. A >>> third alternative is to introduce some shim-layer between RTP and UDP that >>> can provide this demultiplexing point. This has the advantage that it also >>> only uses a single 5-tuple, but unlike option 2, doesn't break the RTP >>> protocol. So, I looked at some of RFCs mentioned in the rtp-usage-01 draft. RFC 2733 (FEC) says, "For unicast, different ports or different SSRC may be used. Each of these approaches has drawbacks and benefits which depend on the application." This flexibility was apparently removed 8 years later in RFC 5109, though I suspect there are a number of people in this WG who still believe the second sentence from RFC 2733 is true. RFC 4588 (retransmission) also says, "These two streams may be multiplexed either by sending them in two different sessions, i.e., session-multiplexing, or in the same session using different SSRC values, i.e., SSRC-multiplexing." >> Yes - the disadvantage is of course that it kills all hope of interoperability >> with any other RTP implementation; people may or may not think of that as >> "breaking the RTP protocol". The problem, as I see it, is that ports are rare and expensive, and SSRC values are plentiful and cheap. With NATs, many endpoints (and potentially pairs of hosts) must share the same port namespace, and firewalls/routers/etc. consume resources for each one. In contrast, there are 32-bits of available SSRC space per CNAME, but the number of actual streams needed is usually quite small and self-limiting (since there are normally significant processing requirements at the endpoints associated with each one). I propose taking the most significant, say, 8 bits of the SSRC value and using them as a "pseudo-session" identifier. Then the association of mutliple streams for purposes of scalability, retransmission, and FEC can be done simply by clearing the top 8 bits, with no signaling required. This can be thought of as a variation of the "shim-layer" approach (what has been meant by that has never been clear to me, but my assumption has always been that it would encapsulate the RTP packets with yet another header), but it has some advantages: 1) No additional bytes must be transmitted. IP+UDP+RTP is already 40 bytes, or 16 kbps when sending 50 packets per second (typical for audio, where this is a significant fraction of the total bandwidth). 2) Interoperability with existing RTP implementations works for the cases where only a single session is needed (e.g., simple audio, or even audio with some amount of FEC, as the packet sizes are typically much smaller than an MTU). 3) As the change and semantics are relatively simple, eventually upgrading existing RTP deployments should not be hard. For interoperability in more complex cases, you can add the same translation tool a shim-layer would normally need, and it can be just as simple and generic. So, what does this break? RFC 3550 Section 5.2 lists 5 points. The first 3 are eliminated by using different SSRCs. Point 4 is, "An RTP mixer would not be able to combine interleaved streams of incompatible media into one stream," which is still true, but it would be able to combine them into a small number of streams, the same as if they had been transmitted in different sessions, based on media type (which it would have to know to be able recombine them at all), so I'm not sure what the actual drawback is here. Point 5 says SSRC-multiplexing precludes 3 things: A) "...the use of different network paths or network resource allocations if appropriate..." Resource allocation already requires deep packet inspection for many parts of the internet, and the inspection required here is not particularly onerous (masking off a fixed-size field at a fixed offset that is always transmitted in the clear, even for SRTP). B) "...reception of a subset of the media, if desired, for example just audio if video would exceed the available bandwidth..." This is true, but I expect rtcweb to be mostly point-to-point, and that these decisions should be made during call setup, so this doesn't really apply (I assume it was meant for multicast environments where one might wish to subscribe to a subset of the available streams). C) "...receiver implementations that use separate processes for the different media..." It would not be hard to write packet-filter rules to distribute the separate session data to multiple processes if this was really desired, but at least at the endpoints, is there really much expectation that audio and video data which must be synchronized to a single, common clock can be processed in separate processes? What else am I missing? From harald@alvestrand.no Mon Jun 13 08:41:20 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D43121F853B for ; Mon, 13 Jun 2011 08:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng4rpj+AcIfx for ; Mon, 13 Jun 2011 08:41:20 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D067D21F8479 for ; Mon, 13 Jun 2011 08:41:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9667739E08B; Mon, 13 Jun 2011 17:40:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1Be47qtGchw; Mon, 13 Jun 2011 17:40:22 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id EBE4B39E082; Mon, 13 Jun 2011 17:40:21 +0200 (CEST) Message-ID: <4DF62F9D.2040008@alvestrand.no> Date: Mon, 13 Jun 2011 17:41:17 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Timothy B. Terriberry" References: <4DF5FF13.6020201@alvestrand.no> <88C5F73E-E612-4DBE-B2DA-08D905CC2D8D@csperkins.org> <4DF603CF.7040601@alvestrand.no> <2B253010-544E-424D-A665-9D12815C2863@csperkins.org> <4DF62CAB.1070509@mozilla.com> In-Reply-To: <4DF62CAB.1070509@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP multiplexing - my understanding of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 15:41:20 -0000 On 06/13/11 17:28, Timothy B. Terriberry wrote: >> On 13 Jun 2011, at 13:34, Harald Alvestrand wrote: >>> On 06/13/11 14:27, Colin Perkins wrote: >>>> On 13 Jun 2011, at 13:14, Harald Alvestrand wrote: >>>>> Each RTCWEB user has two RTP sessions active. All outgoing and >>>>> incoming >>>>> audio channels go on one RTP session; all outgoing and incoming RTP >>>>> sessions go on the other RTP session. > > s/sessions go/video goes/, I assume? Yes, sorry about that. Silly of me, since it's the whole point. I'll hold off on commenting on the rest of the message. From randell1@jesup.org Mon Jun 13 08:51:55 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE5611E810B for ; Mon, 13 Jun 2011 08:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afk7kSD3BTy7 for ; Mon, 13 Jun 2011 08:51:54 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id A0F7A11E80CE for ; Mon, 13 Jun 2011 08:51:49 -0700 (PDT) Received: from pool-71-185-223-77.phlapa.fios.verizon.net ([71.185.223.77] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QW9Qa-0004Wj-UA for rtcweb@ietf.org; Mon, 13 Jun 2011 10:51:49 -0500 Message-ID: <4DF6318E.1010603@jesup.org> Date: Mon, 13 Jun 2011 11:49:34 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4DF5FF13.6020201@alvestrand.no> <88C5F73E-E612-4DBE-B2DA-08D905CC2D8D@csperkins.org> <4DF603CF.7040601@alvestrand.no> <2B253010-544E-424D-A665-9D12815C2863@csperkins.org> In-Reply-To: <2B253010-544E-424D-A665-9D12815C2863@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] RTP multiplexing - my understanding of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 15:51:55 -0000 On 6/13/2011 8:37 AM, Colin Perkins wrote: > On 13 Jun 2011, at 13:34, Harald Alvestrand wrote: >> On 06/13/11 14:27, Colin Perkins wrote: >>> On 13 Jun 2011, at 13:14, Harald Alvestrand wrote: >>>> I thought I'd try to capture my understanding of the state of play wrt RTP multiplexing as of the end of Wednesday's meeting. >>>> >>>> As I understand it, we have two possibilities for guidelines, and the difference between them can be decided on whether it's technically feasible or not to put audio and video into the same RTP session. >>>> >>>> (for the sake of clarity of argument, I'm claiming that only two types of media exist: audio and video, and I'm ignoring the question of additional sessions for FEC. It's simpler to see what we come out with that way.) >>>> >>>> ------------------------------------------------- >>>> >>>> 1) draft-perkins-rtcweb-rtp-usage, as clarified in discussion: >>>> >>>> Each RTCWEB user has two RTP sessions active. All outgoing and incoming audio channels go on one RTP session; all outgoing and incoming RTP sessions go on the other RTP session. >>>> >>>> Audio and video from a single user is correlated based on the CNAME; the SSRC for streams with the same CNAME can be different in the two RTP sessions. >>>> >>>> Each RTP session, together with its RTCP data, is carried over a single pair of ports (5-tuple, for those who prefer that terminology) between each pair of participants. The RTP sessions are bidirectional. >>>> >>>> (Note: in draft-holmberg's scenario 4.3, multiparty without central server, there are multiple participants; I don't know if this would have only one pair of RTP sessions or one per pair.) >>>> >>>> 2) A not-yet-written-up alternative: >>>> >>>> Each RTCWEB user has one RTP session active. Audio and video both use the same RTP session. Streams from the same user all have the same CNAME; the audio and video stream [must have different SSRCs|can have the same SSRC|must have the same SSRC]. >>>> >>>> All data between two participants is carried over a single 5-tuple. >>>> >>>> ------------------------------------------- >>>> I recognize that this is a gross simplification that glosses over significant detail, but ... can we agree that this is a roughly correct description of the alternatives we were talking about? >>> RTP requires some lower-layer demultiplexing point to identify sessions. A third alternative is to introduce some shim-layer between RTP and UDP that can provide this demultiplexing point. This has the advantage that it also only uses a single 5-tuple, but unlike option 2, doesn't break the RTP protocol. I assume the Matthew Kaufman here is the same one who presented the paper on RTMFP for Adobe at IETF 77. :-) From the email address, I take it you work for Skype now. While that protocol per se may be out-of-bounds (proprietary, patents), some of the problems they were trying to solve aren't entirely different than what we're looking at here. In particular, there may be advantages in setup time and complexity to reducing the number of "5-tuples" required and multiplexing data. For example, if you need to poke holes in a firewall using UPnP it can be painful and slow (to the point where we at WorldGate pre-poked holes to use if a call came in, and we had to keep 2 or 3 sets of holes open to handle call-waiting cases, etc). Even ignoring that and just considering ICE, the number of messages to open N ports is a lot higher than 1 or a pair of ports, and it may also increase the chance of a single-packet loss interfering and slowing down convergence (or pushing ICE to select a sub-optimal connection method). Also, what are the odds of ICE selecting different methods for the different streams? As mentioned, if this is done as a shim/multiplex layer it simplifies interop with existing voice gateways. Side note: there is a draft for (just) multiplexing RTP and RTCP which I had weighed in on and supported; I forget where it stands currently. Another goal from RTMFP that is worth considering is consolidated congestion control - doing congestion control and bandwidth measurement/adaptation across all the streams exchanged with another endpoint together. This is simplified by using a single or smaller number of "5-tuples", though it isn't gated on that. Thought should be given to some of the other goals of RTMFP and if they're in-scope or not. (IP addr changes, etc). >> Yes - the disadvantage is of course that it kills all hope of interoperability with any other RTP implementation; people may or may not think of that as "breaking the RTP protocol". > Option 2 cannot directly interoperate with standard RTP either. They both need some form of gateway to separate the sessions. > > Colin From randell1@jesup.org Mon Jun 13 10:09:32 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E14211E817E for ; Mon, 13 Jun 2011 10:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwTTDHE5gOaY for ; Mon, 13 Jun 2011 10:09:31 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 13D8E11E80AC for ; Mon, 13 Jun 2011 10:09:30 -0700 (PDT) Received: from pool-71-185-223-77.phlapa.fios.verizon.net ([71.185.223.77] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QWAdm-0008Mo-8z for rtcweb@ietf.org; Mon, 13 Jun 2011 12:09:30 -0500 Message-ID: <4DF643C3.3020504@jesup.org> Date: Mon, 13 Jun 2011 13:07:15 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4DF5FF13.6020201@alvestrand.no> <88C5F73E-E612-4DBE-B2DA-08D905CC2D8D@csperkins.org> <4DF603CF.7040601@alvestrand.no> <2B253010-544E-424D-A665-9D12815C2863@csperkins.org> <4DF62CAB.1070509@mozilla.com> In-Reply-To: <4DF62CAB.1070509@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] RTP multiplexing - my understanding of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 17:09:32 -0000 On 6/13/2011 11:28 AM, Timothy B. Terriberry wrote: >> On 13 Jun 2011, at 13:34, Harald Alvestrand wrote: >>> On 06/13/11 14:27, Colin Perkins wrote: >>>> On 13 Jun 2011, at 13:14, Harald Alvestrand wrote: >>>>> Each RTCWEB user has two RTP sessions active. All outgoing and >>>>> incoming >>>>> audio channels go on one RTP session; all outgoing and incoming RTP >>>>> sessions go on the other RTP session. > > s/sessions go/video goes/, I assume? > >>>>> 2) A not-yet-written-up alternative: >>>>> >>>>> Each RTCWEB user has one RTP session active. Audio and video both >>>>> use the > > Allow me to make a suggestion for how this might work below... > >>>> RTP requires some lower-layer demultiplexing point to identify >>>> sessions. A >>>> third alternative is to introduce some shim-layer between RTP and >>>> UDP that >>>> can provide this demultiplexing point. This has the advantage that >>>> it also >>>> only uses a single 5-tuple, but unlike option 2, doesn't break the RTP >>>> protocol. > > So, I looked at some of RFCs mentioned in the rtp-usage-01 draft. > > RFC 2733 (FEC) says, "For unicast, different ports or different SSRC > may be used. Each of these approaches has drawbacks and benefits which > depend on the application." This flexibility was apparently removed 8 > years later in RFC 5109, though I suspect there are a number of people > in this WG who still believe the second sentence from RFC 2733 is true. > > RFC 4588 (retransmission) also says, "These two streams may be > multiplexed either by sending them in two different sessions, i.e., > session-multiplexing, or in the same session using different SSRC > values, i.e., SSRC-multiplexing." > >>> Yes - the disadvantage is of course that it kills all hope of >>> interoperability >>> with any other RTP implementation; people may or may not think of >>> that as >>> "breaking the RTP protocol". > > The problem, as I see it, is that ports are rare and expensive, and > SSRC values are plentiful and cheap. With NATs, many endpoints (and > potentially pairs of hosts) must share the same port namespace, and > firewalls/routers/etc. consume resources for each one. In contrast, > there are 32-bits of available SSRC space per CNAME, but the number of > actual streams needed is usually quite small and self-limiting (since > there are normally significant processing requirements at the > endpoints associated with each one). > > I propose taking the most significant, say, 8 bits of the SSRC value > and using them as a "pseudo-session" identifier. Then the association > of mutliple streams for purposes of scalability, retransmission, and > FEC can be done simply by clearing the top 8 bits, with no signaling > required. I can understand the temptation to re-purpose the SSRC in this manner. > This can be thought of as a variation of the "shim-layer" approach > (what has been meant by that has never been clear to me, but my > assumption has always been that it would encapsulate the RTP packets > with yet another header), but it has some advantages: I would assume the "shim layer" suggested is a multiplexor byte or more between RTP/RTCP and UDP. > > 1) No additional bytes must be transmitted. IP+UDP+RTP is already 40 > bytes, or 16 kbps when sending 50 packets per second (typical for > audio, where this is a significant fraction of the total bandwidth). Agreed. > 2) Interoperability with existing RTP implementations works for the > cases where only a single session is needed (e.g., simple audio, or > even audio with some amount of FEC, as the packet sizes are typically > much smaller than an MTU). In my experience, most video implementations (which can fill packets) avoid using every possible byte in an ethernet MTU because this can cause problems with things like PPPOE/etc (which is a form of shim layer itself). It does mean you don't need to strip the shim layer outgoing, and you don't need to fragment (in the rare case of full-MTU incoming). Note however this may cause issues with interop requiring SSRC translation, since the interop device may change SSRCs to any value at will, and SSRC translation gets fun when you have to deal with RTCP and all the variants like XR report blocks. Perhaps I'm overplaying the issues here; Magnus & Colin are probably more familiar with the issues. > 3) As the change and semantics are relatively simple, eventually > upgrading existing RTP deployments should not be hard. You mean "RTP v3"? Perhaps I mis-understand your comment. Technically it wouldn't be hard, but in practice I think you'd have to wait a long time even if there was agreement that this was the "next step" for RTP - you'd need pretty much for all existing equipment to be end-of-lifed and retired. There's little or no incentive for them to switch, let alone upgrade existing devices and servers. > For interoperability in more complex cases, you can add the same > translation tool a shim-layer would normally need, and it can be just > as simple and generic. > > So, what does this break? > > RFC 3550 Section 5.2 lists 5 points. The first 3 are eliminated by > using different SSRCs. Point 4 is, "An RTP mixer would not be able to > combine interleaved streams of incompatible media into one stream," > which is still true, but it would be able to combine them into a small > number of streams, the same as if they had been transmitted in > different sessions, based on media type (which it would have to know > to be able recombine them at all), so I'm not sure what the actual > drawback is here. Point 5 says SSRC-multiplexing precludes 3 things: > > A) "...the use of different network paths or network resource > allocations if appropriate..." Resource allocation already requires > deep packet inspection for many parts of the internet, and the > inspection required here is not particularly onerous (masking off a > fixed-size field at a fixed offset that is always transmitted in the > clear, even for SRTP). An example of this is resource-reservations (in particular upstream bandwidth) done on HFC cable access networks. I know such things used to be done circa 4-5 years ago, or at least were being played with by the cable companies. In theory different media (audio vs video) could be treated differently by a resource-reservation if they're on separate ports; I'm not sure that's ever actually done however. > B) "...reception of a subset of the media, if desired, for example > just audio if video would exceed the available bandwidth..." This is > true, but I expect rtcweb to be mostly point-to-point, and that these > decisions should be made during call setup, so this doesn't really > apply (I assume it was meant for multicast environments where one > might wish to subscribe to a subset of the available streams). This is a fairly bogus issue at least for the rtcweb use-cases I know of, in that you need the sender to throttle if you want to save available bandwidth, though in theory a midbox or conference server could do so for you. These decisions may be made in-call instead of at setup, but they still require coordination with the sender. > C) "...receiver implementations that use separate processes for the > different media..." It would not be hard to write packet-filter rules > to distribute the separate session data to multiple processes if this > was really desired, but at least at the endpoints, is there really > much expectation that audio and video data which must be synchronized > to a single, common clock can be processed in separate processes? Well, RTP is designed to not only allow separate processes to handle different media types (streams) but also to allow different devices (IP addresses) for each stream in a session. And yes, such devices really do exist. In the context of rtcweb, however, I can't think of a use-case for this ability. (Magnus, Colin?) -- Randell Jesup randell-ietf@jesup.org From csp@csperkins.org Mon Jun 13 10:14:43 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFE411E8162 for ; Mon, 13 Jun 2011 10:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.402 X-Spam-Level: X-Spam-Status: No, score=-103.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rm1CRYdTcPuF for ; Mon, 13 Jun 2011 10:14:40 -0700 (PDT) Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by ietfa.amsl.com (Postfix) with ESMTP id 426AA11E80ED for ; Mon, 13 Jun 2011 10:14:40 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QWAil-00011e-eI; Mon, 13 Jun 2011 17:14:39 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4DF62CAB.1070509@mozilla.com> Date: Mon, 13 Jun 2011 18:14:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DF5FF13.6020201@alvestrand.no> <88C5F73E-E612-4DBE-B2DA-08D905CC2D8D@csperkins.org> <4DF603CF.7040601@alvestrand.no> <2B253010-544E-424D-A665-9D12815C2863@csperkins.org> <4DF62CAB.1070509@mozilla.com> To: Timothy B. Terriberry X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP multiplexing - my understanding of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 17:14:43 -0000 On 13 Jun 2011, at 16:28, Timothy B. Terriberry wrote: >> On 13 Jun 2011, at 13:34, Harald Alvestrand wrote: >>> On 06/13/11 14:27, Colin Perkins wrote: >>>> On 13 Jun 2011, at 13:14, Harald Alvestrand wrote: >>>>> Each RTCWEB user has two RTP sessions active. All outgoing and = incoming audio channels go on one RTP session; all outgoing and incoming = RTP sessions go on the other RTP session. >=20 > s/sessions go/video goes/, I assume? >=20 >>>>> 2) A not-yet-written-up alternative: >>>>>=20 >>>>> Each RTCWEB user has one RTP session active. Audio and video both = use the >=20 > Allow me to make a suggestion for how this might work below... >=20 >>>> RTP requires some lower-layer demultiplexing point to identify = sessions. A third alternative is to introduce some shim-layer between = RTP and UDP that can provide this demultiplexing point. This has the = advantage that it also only uses a single 5-tuple, but unlike option 2, = doesn't break the RTPprotocol. >=20 > So, I looked at some of RFCs mentioned in the rtp-usage-01 draft. >=20 > RFC 2733 (FEC) says, "For unicast, different ports or different SSRC = may be used. Each of these approaches has drawbacks and benefits which = depend on the application." This flexibility was apparently removed 8 = years later in RFC 5109, though I suspect there are a number of people = in this WG who still believe the second sentence from RFC 2733 is true. I'm sure there are. Unfortunately, the SSRC multiplexing mechanism used = in RFC 2733 breaks when a participant tries to send several streams in = the session, which is why RFC 5109 mandates a separate RTP session for = the FEC.=20 > RFC 4588 (retransmission) also says, "These two streams may be = multiplexed either by sending them in two different sessions, i.e., = session-multiplexing, or in the same session using different SSRC = values, i.e., SSRC-multiplexing." Again, as Section 5.3 of RFC 4588 explains, there are difficulties when = using SSRC multiplexing when a participant tries to send several streams = in a session. In both cases, SSRC multiplexing appears to work, until you consider the = more complex scenarios in which RTP is used. >>> Yes - the disadvantage is of course that it kills all hope of = interoperability with any other RTP implementation; people may or may = not think of that as "breaking the RTP protocol". >=20 > The problem, as I see it, is that ports are rare and expensive, and = SSRC values are plentiful and cheap. With NATs, many endpoints (and = potentially pairs of hosts) must share the same port namespace, and = firewalls/routers/etc. consume resources for each one. So add a shim layer to demultiplex, sitting between the UDP header and = the RTP header. Don't break RTP. > In contrast, there are 32-bits of available SSRC space per CNAME, but = the number of actual streams needed is usually quite small and = self-limiting (since there are normally significant processing = requirements at the endpoints associated with each one). >=20 > I propose taking the most significant, say, 8 bits of the SSRC value = and using them as a "pseudo-session" identifier. Then the association of = mutliple streams for purposes of scalability, retransmission, and FEC = can be done simply by clearing the top 8 bits, with no signaling = required. >=20 > This can be thought of as a variation of the "shim-layer" approach = (what has been meant by that has never been clear to me, but my = assumption has always been that it would encapsulate the RTP packets = with yet another header), but it has some advantages: The shim could be a simple as a single byte to identify the RTP session = prepended onto the packets (there might be advantages in using something = more complex like RTP in DCCP in UDP encapsulation, but this also has = some significant costs). > 1) No additional bytes must be transmitted. IP+UDP+RTP is already 40 = bytes, or 16 kbps when sending 50 packets per second (typical for audio, = where this is a significant fraction of the total bandwidth). >=20 > 2) Interoperability with existing RTP implementations works for the = cases where only a single session is needed (e.g., simple audio, or even = audio with some amount of FEC, as the packet sizes are typically much = smaller than an MTU). It's not clear that this interoperates, since the other endpoint might = pick one of the reserved SSRC values. You'd need to translate the SSRC = at the gateway, which is non-trival once you start including RTCP = packets in the translation. > 3) As the change and semantics are relatively simple, eventually = upgrading existing RTP deployments should not be hard. The semantics are complex, especially once you start to think about the = interactions with the RTCP timing rules. It would be much simpler to add = a demultiplexing shim. > For interoperability in more complex cases, you can add the same = translation tool a shim-layer would normally need, and it can be just as = simple and generic. It's much more complex, since you may need to rewrite SSRC values in = RTCP and deal with the differences in RTCP timing and participant = timeout. > So, what does this break? >=20 > RFC 3550 Section 5.2 lists 5 points. The first 3 are eliminated by = using different SSRCs. Point 4 is, "An RTP mixer would not be able to = combine interleaved streams of incompatible media into one stream," = which is still true, but it would be able to combine them into a small = number of streams, the same as if they had been transmitted in different = sessions, based on media type (which it would have to know to be able = recombine them at all), so I'm not sure what the actual drawback is = here. Point 5 says SSRC-multiplexing precludes 3 things: >=20 > A) "...the use of different network paths or network resource = allocations if appropriate..." Resource allocation already requires deep = packet inspection for many parts of the internet, and the inspection = required here is not particularly onerous (masking off a fixed-size = field at a fixed offset that is always transmitted in the clear, even = for SRTP). Demultiplexing based on a shim is also no more onerous. > B) "...reception of a subset of the media, if desired, for example = just audio if video would exceed the available bandwidth..." This is = true, but I expect rtcweb to be mostly point-to-point, and that these = decisions should be made during call setup, so this doesn't really apply = (I assume it was meant for multicast environments where one might wish = to subscribe to a subset of the available streams). It's also useful in unicast environments.=20 > C) "...receiver implementations that use separate processes for the = different media..." It would not be hard to write packet-filter rules to = distribute the separate session data to multiple processes if this was = really desired, but at least at the endpoints, is there really much = expectation that audio and video data which must be synchronized to a = single, common clock can be processed in separate processes? There have been implementations that work that way, but a more common = issue might be where audio and video are rendered by different devices. > What else am I missing? You also break the RTCP timing rules and participant timeouts, the SSRC = allocation, and the SSRC collision detection and resolution algorithm. = All of these make it incompatible with other RTP implementations.=20 And all to avoid a one byte shim layer... --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon Jun 13 10:28:54 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0DF11E810B for ; Mon, 13 Jun 2011 10:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.424 X-Spam-Level: X-Spam-Status: No, score=-103.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFb3D36-5GjH for ; Mon, 13 Jun 2011 10:28:52 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEAA11E80CE for ; Mon, 13 Jun 2011 10:28:52 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QWAvG-0004XY-lN; Mon, 13 Jun 2011 17:27:34 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4DF643C3.3020504@jesup.org> Date: Mon, 13 Jun 2011 18:27:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <03B881F6-A46E-4204-8F96-6AD29630E771@csperkins.org> References: <4DF5FF13.6020201@alvestrand.no> <88C5F73E-E612-4DBE-B2DA-08D905CC2D8D@csperkins.org> <4DF603CF.7040601@alvestrand.no> <2B253010-544E-424D-A665-9D12815C2863@csperkins.org> <4DF62CAB.1070509@mozilla.com> <4DF643C3.3020504@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTP multiplexing - my understanding of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 17:28:54 -0000 On 13 Jun 2011, at 18:07, Randell Jesup wrote: > On 6/13/2011 11:28 AM, Timothy B. Terriberry wrote: >>> On 13 Jun 2011, at 13:34, Harald Alvestrand wrote: >>>> On 06/13/11 14:27, Colin Perkins wrote: >>>>> On 13 Jun 2011, at 13:14, Harald Alvestrand wrote: >>>>>> Each RTCWEB user has two RTP sessions active. All outgoing and = incoming audio channels go on one RTP session; all outgoing and incoming = RTP sessions go on the other RTP session. >>=20 >> s/sessions go/video goes/, I assume? >>=20 >>>>>> 2) A not-yet-written-up alternative: >>>>>>=20 >>>>>> Each RTCWEB user has one RTP session active. Audio and video both = use the >>=20 >> Allow me to make a suggestion for how this might work below... >>=20 >>>>> RTP requires some lower-layer demultiplexing point to identify = sessions. A third alternative is to introduce some shim-layer between = RTP and UDP that can provide this demultiplexing point. This has the = advantage that it also only uses a single 5-tuple, but unlike option 2, = doesn't break the RTP protocol. >>=20 >> So, I looked at some of RFCs mentioned in the rtp-usage-01 draft. >>=20 >> RFC 2733 (FEC) says, "For unicast, different ports or different SSRC = may be used. Each of these approaches has drawbacks and benefits which = depend on the application." This flexibility was apparently removed 8 = years later in RFC 5109, though I suspect there are a number of people = in this WG who still believe the second sentence from RFC 2733 is true. >>=20 >> RFC 4588 (retransmission) also says, "These two streams may be = multiplexed either by sending them in two different sessions, i.e., = session-multiplexing, or in the same session using different SSRC = values, i.e., SSRC-multiplexing." >>=20 >>>> Yes - the disadvantage is of course that it kills all hope of = interoperability with any other RTP implementation; people may or may = not think of that as "breaking the RTP protocol". >>=20 >> The problem, as I see it, is that ports are rare and expensive, and = SSRC values are plentiful and cheap. With NATs, many endpoints (and = potentially pairs of hosts) must share the same port namespace, and = firewalls/routers/etc. consume resources for each one. In contrast, = there are 32-bits of available SSRC space per CNAME, but the number of = actual streams needed is usually quite small and self-limiting (since = there are normally significant processing requirements at the endpoints = associated with each one). >>=20 >> I propose taking the most significant, say, 8 bits of the SSRC value = and using them as a "pseudo-session" identifier. Then the association of = mutliple streams for purposes of scalability, retransmission, and FEC = can be done simply by clearing the top 8 bits, with no signaling = required. >=20 > I can understand the temptation to re-purpose the SSRC in this manner. >=20 >> This can be thought of as a variation of the "shim-layer" approach = (what has been meant by that has never been clear to me, but my = assumption has always been that it would encapsulate the RTP packets = with yet another header), but it has some advantages: >=20 > I would assume the "shim layer" suggested is a multiplexor byte or = more between RTP/RTCP and UDP. >=20 >>=20 >> 1) No additional bytes must be transmitted. IP+UDP+RTP is already 40 = bytes, or 16 kbps when sending 50 packets per second (typical for audio, = where this is a significant fraction of the total bandwidth). >=20 > Agreed. >=20 >> 2) Interoperability with existing RTP implementations works for the = cases where only a single session is needed (e.g., simple audio, or even = audio with some amount of FEC, as the packet sizes are typically much = smaller than an MTU). >=20 > In my experience, most video implementations (which can fill packets) = avoid using every possible byte in an ethernet MTU because this can = cause problems with things like PPPOE/etc (which is a form of shim layer = itself). It does mean you don't need to strip the shim layer outgoing, = and you don't need to fragment (in the rare case of full-MTU incoming). = Note however this may cause issues with interop requiring SSRC = translation, since the interop device may change SSRCs to any value at = will, and SSRC translation gets fun when you have to deal with RTCP and = all the variants like XR report blocks. Perhaps I'm overplaying the = issues here; Magnus & Colin are probably more familiar with the issues. No, the translation will get very difficult once you consider all the = RTCP packet types. The trivial case can be made to work, but the = complexity rapidly spirals up as you consider all the other ways in = which RTP is used. >> 3) As the change and semantics are relatively simple, eventually = upgrading existing RTP deployments should not be hard. >=20 > You mean "RTP v3"? Perhaps I mis-understand your comment. = Technically it wouldn't be hard, but in practice I think you'd have to = wait a long time even if there was agreement that this was the "next = step" for RTP - you'd need pretty much for all existing equipment to be = end-of-lifed and retired. There's little or no incentive for them to = switch, let alone upgrade existing devices and servers. >=20 >> For interoperability in more complex cases, you can add the same = translation tool a shim-layer would normally need, and it can be just as = simple and generic. >>=20 >> So, what does this break? >>=20 >> RFC 3550 Section 5.2 lists 5 points. The first 3 are eliminated by = using different SSRCs. Point 4 is, "An RTP mixer would not be able to = combine interleaved streams of incompatible media into one stream," = which is still true, but it would be able to combine them into a small = number of streams, the same as if they had been transmitted in different = sessions, based on media type (which it would have to know to be able = recombine them at all), so I'm not sure what the actual drawback is = here. Point 5 says SSRC-multiplexing precludes 3 things: >>=20 >> A) "...the use of different network paths or network resource = allocations if appropriate..." Resource allocation already requires deep = packet inspection for many parts of the internet, and the inspection = required here is not particularly onerous (masking off a fixed-size = field at a fixed offset that is always transmitted in the clear, even = for SRTP). >=20 > An example of this is resource-reservations (in particular upstream = bandwidth) done on HFC cable access networks. I know such things used = to be done circa 4-5 years ago, or at least were being played with by = the cable companies. In theory different media (audio vs video) could = be treated differently by a resource-reservation if they're on separate = ports; I'm not sure that's ever actually done however. >=20 >> B) "...reception of a subset of the media, if desired, for example = just audio if video would exceed the available bandwidth..." This is = true, but I expect rtcweb to be mostly point-to-point, and that these = decisions should be made during call setup, so this doesn't really apply = (I assume it was meant for multicast environments where one might wish = to subscribe to a subset of the available streams). >=20 > This is a fairly bogus issue at least for the rtcweb use-cases I know = of, in that you need the sender to throttle if you want to save = available bandwidth, though in theory a midbox or conference server = could do so for you. These decisions may be made in-call instead of at = setup, but they still require coordination with the sender. >=20 >> C) "...receiver implementations that use separate processes for the = different media..." It would not be hard to write packet-filter rules to = distribute the separate session data to multiple processes if this was = really desired, but at least at the endpoints, is there really much = expectation that audio and video data which must be synchronized to a = single, common clock can be processed in separate processes? >=20 > Well, RTP is designed to not only allow separate processes to handle = different media types (streams) but also to allow different devices (IP = addresses) for each stream in a session. And yes, such devices really = do exist. In the context of rtcweb, however, I can't think of a = use-case for this ability. (Magnus, Colin?) We don't have a use case, or we don't have a use case _yet_? While we = may not want to support more advanced scenarios today, we don't want to = make decisions which preclude them if we can avoid it (and, in this = case, we can easily avoid it by either using separate UDP ports, or by = adding a shim layer between UDP and RTP, and leaving the SSRC semantics = alone). --=20 Colin Perkins http://csperkins.org/ From blizzard@mozilla.com Mon Jun 13 10:42:39 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80D711E80A9 for ; Mon, 13 Jun 2011 10:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS57tuZSXekM for ; Mon, 13 Jun 2011 10:42:39 -0700 (PDT) Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by ietfa.amsl.com (Postfix) with ESMTP id 794F511E80F4 for ; Mon, 13 Jun 2011 10:42:39 -0700 (PDT) Received: from [10.250.2.228] (corp-240.mv.mozilla.com [63.245.220.240]) by mail.mozilla.com (Postfix) with ESMTPSA id 196F3AE6402A; Mon, 13 Jun 2011 10:42:38 -0700 (PDT) Message-ID: <4DF64C0D.4080909@mozilla.com> Date: Mon, 13 Jun 2011 10:42:37 -0700 From: Christopher Blizzard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Harald Alvestrand References: , <4DF3DCB8.9090805@alvestrand.no> <4DF454DA.8030300@alvestrand.no> In-Reply-To: <4DF454DA.8030300@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 17:42:39 -0000 On 6/11/2011 10:55 PM, Harald Alvestrand wrote: > One of my implementor colleagues claims (in another context) that a > main difference between an embedded-in-browser implementation and a > Javascript one is that the browser one has less than 10 significant > implementations that have to interoperate, while the Javascript one > will have an essentially unbounded number of implementations > ("millions of web pages"). His conclusion was that for the things we > need to get right in order to have interoperability (for the case we > were discussing, which was not ICE), it's better to have them embedded > in the browser than to depend on Javascript. Agreed on this point. The level for this API is probably pretty high to reduce the matrix for testing an interop. --Chris From blizzard@mozilla.com Mon Jun 13 10:45:05 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85AA521F849B for ; Mon, 13 Jun 2011 10:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ervmK7AwrKL0 for ; Mon, 13 Jun 2011 10:45:05 -0700 (PDT) Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2175221F8499 for ; Mon, 13 Jun 2011 10:45:05 -0700 (PDT) Received: from [10.250.2.228] (corp-240.mv.mozilla.com [63.245.220.240]) by mail.mozilla.com (Postfix) with ESMTPSA id E4C59AE6402C; Mon, 13 Jun 2011 10:45:04 -0700 (PDT) Message-ID: <4DF64CA0.1070705@mozilla.com> Date: Mon, 13 Jun 2011 10:45:04 -0700 From: Christopher Blizzard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Matthew Kaufman References: , <4DF3DCB8.9090805@alvestrand.no> <4DF454DA.8030300@alvestrand.no> <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> In-Reply-To: <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 17:45:05 -0000 On 6/12/2011 2:05 AM, Matthew Kaufman wrote: > (The example that keeps coming to mind is the difference between > progressive playback of HTTP video (as is in Flash Player and most > HTML5 video tag implementation) vs. adaptive HTTP streaming (which, in > Flash Player was architected as low-level ActionScript primitives plus > reference code, and which has already done several things that weren't > originally imagined when the APIs were first added)) For this case you should know that we're interested in the web browser to do both - have a "just works" mode for people that want adaptive bandwidth and a low-level API for people who want to control it directly. But keep in mind that the interop matrix there is small - we're still talking about a few products and the site has control of its entire stack. Getting services talking to each other with a lower level API is very different from a single site. --Chris From fluffy@cisco.com Mon Jun 13 10:53:35 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEF4228015 for ; Mon, 13 Jun 2011 10:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owNJGo-bruWq for ; Mon, 13 Jun 2011 10:53:35 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 09C7F228004 for ; Mon, 13 Jun 2011 10:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1372; q=dns/txt; s=iport; t=1307987614; x=1309197214; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=s3Jr1Brzgz5Hks9HqyghFFtoFDUUxDfqnNvysDo5+9E=; b=LU6+0xZuSxM22nzgi9Iqgk7R6NxgR2vLXrnBOKRPInClGcMLHiq6/dyD ZvFnAPi/RuvdCMktYIDSWXrMzIIhidcIpEwW2BS9O1lveBeTDxyfY94d3 H4m7eARBAP8lcO+CXVaaVnO2bCnOEUHQqw3MFFYQAdBUUKFb1+QWuxxqc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACpO9k2rRDoJ/2dsb2JhbABSpi53qladZoYkBIcNiieET4st X-IronPort-AV: E=Sophos;i="4.65,359,1304294400"; d="scan'208";a="464613825" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 13 Jun 2011 17:53:33 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5DHrWXG021712; Mon, 13 Jun 2011 17:53:33 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <03B881F6-A46E-4204-8F96-6AD29630E771@csperkins.org> Date: Mon, 13 Jun 2011 11:53:32 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3614E622-6E1A-4863-AC31-8AC35D8CA0F9@cisco.com> References: <4DF5FF13.6020201@alvestrand.no> <88C5F73E-E612-4DBE-B2DA-08D905CC2D8D@csperkins.org> <4DF603CF.7040601@alvestrand.no> <2B253010-544E-424D-A665-9D12815C2863@csperkins.org> <4DF62CAB.1070509@mozilla.com> <4DF643C3.3020504@jesup.org> <03B881F6-A46E-4204-8F96-6AD29630E771@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTP multiplexing - my understanding of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 17:53:35 -0000 On Jun 13, 2011, at 11:27 AM, Colin Perkins wrote: >>=20 >> Well, RTP is designed to not only allow separate processes to handle = different media types (streams) but also to allow different devices (IP = addresses) for each stream in a session. And yes, such devices really = do exist. In the context of rtcweb, however, I can't think of a = use-case for this ability. (Magnus, Colin?) >=20 >=20 > We don't have a use case, or we don't have a use case _yet_? While we = may not want to support more advanced scenarios today, we don't want to = make decisions which preclude them if we can avoid it (and, in this = case, we can easily avoid it by either using separate UDP ports, or by = adding a shim layer between UDP and RTP, and leaving the SSRC semantics = alone). One possible use case is I want the video displayed in my browser but = the audio going to a high quality speaker phone on my desk. People often = do this with soft phones today so it is easy to imagine them wanting to = do with a browser and phone. So I can impinge a use case, however... I'm = not seeing that this use case changes much. Assuming that SSRC multiplex = is signaled and both ends negotiate using it, I'm not understanding = Colin's & Magnus draft well enough to see what breaks that people care = about.=20 Cullen From igor.faynberg@alcatel-lucent.com Mon Jun 13 11:05:35 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AE711E80AC for ; Mon, 13 Jun 2011 11:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwcEVAz5-amp for ; Mon, 13 Jun 2011 11:05:35 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2938111E80CE for ; Mon, 13 Jun 2011 11:05:35 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p5DI5YSC009546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jun 2011 13:05:34 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5DI5XnK001375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Jun 2011 13:05:34 -0500 Received: from [135.244.25.71] (faynberg.lra.lucent.com [135.244.25.71]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5DI5WGv029889; Mon, 13 Jun 2011 13:05:33 -0500 (CDT) Message-ID: <4DF6516C.4070307@alcatel-lucent.com> Date: Mon, 13 Jun 2011 14:05:32 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Avasarala, Ranjit" References: <4DF29433.2080503@alcatel-lucent.com> <9F9278CB1892FB48BF35CB5CC3992478A5325210E7@HKGMBOXPRD01.polycom.com> In-Reply-To: <9F9278CB1892FB48BF35CB5CC3992478A5325210E7@HKGMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How do we implement SIP event subscription in RTCweb? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 18:05:35 -0000 That part I thought was easy: The application will send REGISTER. I was worried about keeping a persistent connection, but Justin (to whom many thanks for answering my query right away!) assures me that this is not a problem, and so far no one said anything otherwise. Igor Avasarala, Ranjit wrote: > Hi > > Any idea how the initial SIP signaling would take place between an RTC web application and SIP server? > > Regards > Ranjit > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Igor Faynberg > Sent: Saturday, June 11, 2011 3:31 AM > To: rtcweb@ietf.org > Subject: [rtcweb] How do we implement SIP event subscription in RTCweb? > > A question. > > When SIP is implemented in an application within the present RTCweb > architecture, how exactly could we use WebSockets for SUBSCRIBE/NOTIFY? > > It appears to me that the only way to achieve that is to open a > persistent connection. Am I right? > > If so, is it not a problem, given the potential duration of such > connections and potential tie-up of network resources? > > If not, how else could that be done? > > With many thanks, > > Igor > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From blizzard@mozilla.com Mon Jun 13 11:09:02 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCCF11E80F4 for ; Mon, 13 Jun 2011 11:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QO1pDJifAh7O for ; Mon, 13 Jun 2011 11:09:01 -0700 (PDT) Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by ietfa.amsl.com (Postfix) with ESMTP id C480111E80F1 for ; Mon, 13 Jun 2011 11:09:01 -0700 (PDT) Received: from [10.250.2.228] (corp-240.mv.mozilla.com [63.245.220.240]) by mail.mozilla.com (Postfix) with ESMTPSA id 31651AE6400A; Mon, 13 Jun 2011 11:09:01 -0700 (PDT) Message-ID: <4DF6523C.4060901@mozilla.com> Date: Mon, 13 Jun 2011 11:09:00 -0700 From: Christopher Blizzard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <4DF29433.2080503@alcatel-lucent.com> <9F9278CB1892FB48BF35CB5CC3992478A5325210E7@HKGMBOXPRD01.polycom.com> <4DF6516C.4070307@alcatel-lucent.com> In-Reply-To: <4DF6516C.4070307@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How do we implement SIP event subscription in RTCweb? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 18:09:02 -0000 On 6/13/2011 11:05 AM, Igor Faynberg wrote: > I was worried about keeping a persistent connection, but Justin (to > whom many thanks for answering my query right away!) assures me that > this is not a problem, and so far no one said anything otherwise. The larger issue is that we need a way to do connections & applications outside of the single page context. How do you signal from a service when someone might not have a web page open? This is a problem that's outside of the scope of both the IETF and W3C groups, but it's a problem in any case. --Chris From fluffy@cisco.com Mon Jun 13 11:26:55 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA20811E808C for ; Mon, 13 Jun 2011 11:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ0PqJr8hjYr for ; Mon, 13 Jun 2011 11:26:55 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA3411E8072 for ; Mon, 13 Jun 2011 11:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=957; q=dns/txt; s=iport; t=1307989615; x=1309199215; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=HfR7Mw9v6G7dN+93MX/Y1D0Rk198i+TI6LF90uWjDlA=; b=IrZblQEdWfZH5jr/rdHIAhYBbG1HEJvyeUcSK7ekoGUjXFIkdDXEVQe1 EpleJnabzNcr/yOfRfvcNr06szc9cDKx+cTRQ1L2ZBCV7IVu4kjRKQbya GJZ54CVCELuJN40164YwsivZKfHmrrKver3taSabpHZ9+VMZis2fmevoE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJVV9k2rRDoH/2dsb2JhbABSpi53iHKhYp1mhiQEhw2KJ4RPiy0 X-IronPort-AV: E=Sophos;i="4.65,359,1304294400"; d="scan'208";a="375731717" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 13 Jun 2011 18:26:51 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5DIQotS001776; Mon, 13 Jun 2011 18:26:51 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Mon, 13 Jun 2011 12:26:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <46DA3872-9A32-4821-B67C-DC5C8BCB39BA@cisco.com> References: To: Bernard Aboba X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-rescorla-rtcweb-security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 18:26:56 -0000 On Jun 11, 2011, at 3:40 PM, Bernard Aboba wrote: > 4.2.2. Masking >=20 > Once consent is verified, there still is some concern about > misinterpretation attacks as described by Huang et al.[huang-w2sp]. > As long as communication is limited to UDP, then this risk is > probably limited, thus masking is not required for UDP. =20 >=20 > [BA] Are you saying that the browser should be able to send arbitrary > UDP traffic once "consent" is granted? =20 I could be very confused about this but .... I think it is OK with UDP = (after consent is given on the 5 tuple) or even with TLS over TCP. I'm = not sure how long the consent should last. The only place I know of = where this is a problem is when there are middle boxes that intercept = traffic that is not addressed to them. I don't think this happens to the = existing UDP based protocols. Not sure if I have this right but I hope = some discussions ensues.... =20 From csp@csperkins.org Mon Jun 13 11:40:46 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A560E21F85EC for ; Mon, 13 Jun 2011 11:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbnSYAfeE2Bi for ; Mon, 13 Jun 2011 11:40:46 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by ietfa.amsl.com (Postfix) with ESMTP id CCCF221F85EB for ; Mon, 13 Jun 2011 11:40:45 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.21]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QWC44-0000h2-ZO; Mon, 13 Jun 2011 18:40:45 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <3614E622-6E1A-4863-AC31-8AC35D8CA0F9@cisco.com> Date: Mon, 13 Jun 2011 19:40:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <62CA86D6-8B78-4A37-9BB4-2439D453D832@csperkins.org> References: <4DF5FF13.6020201@alvestrand.no> <88C5F73E-E612-4DBE-B2DA-08D905CC2D8D@csperkins.org> <4DF603CF.7040601@alvestrand.no> <2B253010-544E-424D-A665-9D12815C2863@csperkins.org> <4DF62CAB.1070509@mozilla.com> <4DF643C3.3020504@jesup.org> <03B881F6-A46E-4204-8F96-6AD29630E771@csperkins.org> <3614E622-6E1A-4863-AC31-8AC35D8CA0F9@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTP multiplexing - my understanding of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 18:40:46 -0000 On 13 Jun 2011, at 18:53, Cullen Jennings wrote: > On Jun 13, 2011, at 11:27 AM, Colin Perkins wrote: >>> Well, RTP is designed to not only allow separate processes to handle = different media types (streams) but also to allow different devices (IP = addresses) for each stream in a session. And yes, such devices really = do exist. In the context of rtcweb, however, I can't think of a = use-case for this ability. (Magnus, Colin?) >>=20 >> We don't have a use case, or we don't have a use case _yet_? While we = may not want to support more advanced scenarios today, we don't want to = make decisions which preclude them if we can avoid it (and, in this = case, we can easily avoid it by either using separate UDP ports, or by = adding a shim layer between UDP and RTP, and leaving the SSRC semantics = alone). >=20 > One possible use case is I want the video displayed in my browser but = the audio going to a high quality speaker phone on my desk. People often = do this with soft phones today so it is easy to imagine them wanting to = do with a browser and phone. So I can impinge a use case, however... I'm = not seeing that this use case changes much. Assuming that SSRC multiplex = is signaled and both ends negotiate using it, I'm not understanding = Colin's & Magnus draft well enough to see what breaks that people care = about.=20 The problem is in signalling the SSRC multiplexing, partitioning the = SSRC space between the different RTP sessions, and updating the RTP = end-points and middleboxes to cope with the changed SSRC semantics and = RTCP timing rules. All of this is possible, but the result isn't = compatible with RTP as it stands now, and is not easy to gateway into a = standard RTP session.=20 --=20 Colin Perkins http://csperkins.org/ From dzonatas@gmail.com Mon Jun 13 11:51:53 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D1711E80B1 for ; Mon, 13 Jun 2011 11:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.737 X-Spam-Level: X-Spam-Status: No, score=-5.737 tagged_above=-999 required=5 tests=[AWL=-2.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-DycBB6HhiN for ; Mon, 13 Jun 2011 11:51:52 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6F03E11E80AA for ; Mon, 13 Jun 2011 11:51:52 -0700 (PDT) Received: by pxi20 with SMTP id 20so3570097pxi.27 for ; Mon, 13 Jun 2011 11:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xjrh02StPQQYRRu1eKDlYuTUYNc203VSSMIZrPl0/OQ=; b=NxtsCcRVrELjtTsIQlEEhG7WZtZYt59QT8FUBr2xuX++LqgqMRZnFbme2hrwzDzDr6 /kw7aPiSplizurS2HxBNTzwSVfFKpEnvNPhgCp8atwifs8jWMn0s7B9j/STAgDNMJ/3t QoAhwrGQ1thURSosAaeCvHwsRREKFi/JA64xQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Km6GMs4ZlIsIX4VRGTUzSmT5qA8Com8U6Hnx2Uy452u9T3RsejUrm76OLVltjpoiNs Ca48rZPK7A31fWg2HLTv8STIcDuiw2K1UKswTSw6caW01PzLmVrcRev14lEb4s4/vids runHA0cYm0phD5u7PKMu//N49cP7uXf6gjbYo= Received: by 10.68.38.33 with SMTP id d1mr2453599pbk.389.1307991112079; Mon, 13 Jun 2011 11:51:52 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id f3sm4851739pbj.80.2011.06.13.11.51.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Jun 2011 11:51:51 -0700 (PDT) Message-ID: <4DF65C01.5050904@gmail.com> Date: Mon, 13 Jun 2011 11:50:41 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4DF5FF13.6020201@alvestrand.no> <88C5F73E-E612-4DBE-B2DA-08D905CC2D8D@csperkins.org> <4DF603CF.7040601@alvestrand.no> <2B253010-544E-424D-A665-9D12815C2863@csperkins.org> <4DF62CAB.1070509@mozilla.com> <4DF643C3.3020504@jesup.org> In-Reply-To: <4DF643C3.3020504@jesup.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTP multiplexing - my understanding of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 18:51:53 -0000 On 06/13/2011 10:07 AM, Randell Jesup wrote: > On 6/13/2011 11:28 AM, Timothy B. Terriberry wrote: > >> C) "...receiver implementations that use separate processes for the >> different media..." It would not be hard to write packet-filter rules >> to distribute the separate session data to multiple processes if this >> was really desired, but at least at the endpoints, is there really >> much expectation that audio and video data which must be synchronized >> to a single, common clock can be processed in separate processes? > > Well, RTP is designed to not only allow separate processes to handle > different media types (streams) but also to allow different devices > (IP addresses) for each stream in a session. And yes, such devices > really do exist. In the context of rtcweb, however, I can't think of > a use-case for this ability. (Magnus, Colin?) > The basic common clock is most available in kernel mode, so of course use-cases are harder to delineate that way unless there are ties into that mode (into user mode). Exploitation of that clock can lead to over-usage of resources, which then lead to known depletion of energy or cause resource imbalances. That's why my previous message hinted about the colosseum, yet think where every seat has their own clock however set (i.e. for now, cellphone-cams or D8 media). Start with one solution as if the Olympics would setup some kind of heartbeat server for all media that stems (ports) from such an event. It's not an odd use-case unless the idea of software development doesn't belong in any kind of Olympic theme (which seems anti-Olympian and only supports privatization in such idea). I have distributed processes in mind that go over collections of assets or posted content and render the scene. The harder part is how-to layout the words for specific use-case that does not favor any particular development or group other than to say "on the Olympic scale." The Olympics prove how resourceful people are in reality, and the rings represent such elementary thinking. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Mon Jun 13 12:42:37 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66B111E80B1 for ; Mon, 13 Jun 2011 12:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.559 X-Spam-Level: X-Spam-Status: No, score=-5.559 tagged_above=-999 required=5 tests=[AWL=-1.960, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cu8KkTRixxJw for ; Mon, 13 Jun 2011 12:42:36 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id BA2D311E80A1 for ; Mon, 13 Jun 2011 12:42:36 -0700 (PDT) Received: by pxi20 with SMTP id 20so3602606pxi.27 for ; Mon, 13 Jun 2011 12:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jWNVFGLemN2OBwAC5MY8fZbLnbPl/c0z6Kvdp5qLsIg=; b=NP/1jDbox0hdtNGnDuPPg4wlcotuqWtg6bOWNcR8vrmjAwtEfSleQu07OSLK85wtpm uA+k9Y4m59qGbKrOJPftk89ec734LcXLRgGwsnOeP3j/lzLnYPtSTUIhsv9y3AeCTTtk vF+ezs0w/v4J6NHfqwmf8jMHSghsY6D6V8H3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=RRHaBsFT92s+++06ByXUUD0/grs3vzNH/zkRN4bH9LGNKyp9C45bhQduVl9EYwe1Vo 4dkCahFaTgoH16fEdgMZ4rLFjO1A/rncbIdfalvlqV3HCp4/p57u7DcVRm/jSIXyPPGd DtsRTzuLGqTQGArJkzFeqMS0nEo7aEBPITQpU= Received: by 10.142.212.10 with SMTP id k10mr1040327wfg.4.1307994156276; Mon, 13 Jun 2011 12:42:36 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id o2sm4887390pbj.49.2011.06.13.12.42.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Jun 2011 12:42:35 -0700 (PDT) Message-ID: <4DF667E5.1000908@gmail.com> Date: Mon, 13 Jun 2011 12:41:25 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: , <4DF3DCB8.9090805@alvestrand.no> <4DF454DA.8030300@alvestrand.no> <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> <4DF64CA0.1070705@mozilla.com> In-Reply-To: <4DF64CA0.1070705@mozilla.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 19:42:37 -0000 On 06/13/2011 10:45 AM, Christopher Blizzard wrote: > On 6/12/2011 2:05 AM, Matthew Kaufman wrote: >> (The example that keeps coming to mind is the difference between >> progressive playback of HTTP video (as is in Flash Player and most >> HTML5 video tag implementation) vs. adaptive HTTP streaming (which, >> in Flash Player was architected as low-level ActionScript primitives >> plus reference code, and which has already done several things that >> weren't originally imagined when the APIs were first added)) > > For this case you should know that we're interested in the web browser > to do both - have a "just works" mode for people that want adaptive > bandwidth and a low-level API for people who want to control it > directly. But keep in mind that the interop matrix there is small - > we're still talking about a few products and the site has control of > its entire stack. Getting services talking to each other with a lower > level API is very different from a single site. > > Yes and people try to build browser in a browser in a browser etc turtles on turtles as they sort out the layers. With hypervisors available, the concept of service stacks as an entire separate system on the same hardware is known, and browsers can use those instead of endless built-in extensions (or major re-implementations). I wouldn't be surprised to see hypervisors that designate one guest system per port, per protocol (API), per URI scheme, and/or per URN. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From harald@alvestrand.no Tue Jun 14 04:27:17 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A380511E80FF for ; Tue, 14 Jun 2011 04:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFVbhFMEvZhL for ; Tue, 14 Jun 2011 04:27:17 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC5511E80FE for ; Tue, 14 Jun 2011 04:27:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4FFBA39E148; Tue, 14 Jun 2011 13:26:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCupLorEOMom; Tue, 14 Jun 2011 13:26:18 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id AA7A139E0C4; Tue, 14 Jun 2011 13:26:18 +0200 (CEST) Message-ID: <4DF74593.1010701@alvestrand.no> Date: Tue, 14 Jun 2011 13:27:15 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christopher Blizzard References: <4DF29433.2080503@alcatel-lucent.com> <9F9278CB1892FB48BF35CB5CC3992478A5325210E7@HKGMBOXPRD01.polycom.com> <4DF6516C.4070307@alcatel-lucent.com> <4DF6523C.4060901@mozilla.com> In-Reply-To: <4DF6523C.4060901@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How do we implement SIP event subscription in RTCweb? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 11:27:17 -0000 On 06/13/11 20:09, Christopher Blizzard wrote: > On 6/13/2011 11:05 AM, Igor Faynberg wrote: >> I was worried about keeping a persistent connection, but Justin (to >> whom many thanks for answering my query right away!) assures me that >> this is not a problem, and so far no one said anything otherwise. > > The larger issue is that we need a way to do connections & > applications outside of the single page context. How do you signal > from a service when someone might not have a web page open? This is a > problem that's outside of the scope of both the IETF and W3C groups, > but it's a problem in any case. Isn't this the "Web Application / Background Page" problem - that is, having stuff run in the browser when no pages are open? I believe there are W3C groups hard at work on that; we should punt it to them if we can. Harald From igor.faynberg@alcatel-lucent.com Tue Jun 14 06:43:31 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597229E801E for ; Tue, 14 Jun 2011 06:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxlb9CyLT4N5 for ; Tue, 14 Jun 2011 06:43:30 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id BF7569E8004 for ; Tue, 14 Jun 2011 06:43:30 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p5EDhR9v016690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jun 2011 08:43:27 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5EDhQXc017285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Jun 2011 08:43:26 -0500 Received: from [135.244.25.71] (faynberg.lra.lucent.com [135.244.25.71]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5EDhO1V017476; Tue, 14 Jun 2011 08:43:25 -0500 (CDT) Message-ID: <4DF7657C.9010004@alcatel-lucent.com> Date: Tue, 14 Jun 2011 09:43:24 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Harald Alvestrand References: <4DF29433.2080503@alcatel-lucent.com> <9F9278CB1892FB48BF35CB5CC3992478A5325210E7@HKGMBOXPRD01.polycom.com> <4DF6516C.4070307@alcatel-lucent.com> <4DF6523C.4060901@mozilla.com> <4DF74593.1010701@alvestrand.no> In-Reply-To: <4DF74593.1010701@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How do we implement SIP event subscription in RTCweb? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 13:43:31 -0000 We should, and YOU are the best person to do that, since you are already there (and with a lot of clout). But... what can we do in the IETF? Igotr Harald Alvestrand wrote: > On 06/13/11 20:09, Christopher Blizzard wrote: >> On 6/13/2011 11:05 AM, Igor Faynberg wrote: >>> I was worried about keeping a persistent connection, but Justin (to >>> whom many thanks for answering my query right away!) assures me that >>> this is not a problem, and so far no one said anything otherwise. >> >> The larger issue is that we need a way to do connections & >> applications outside of the single page context. How do you signal >> from a service when someone might not have a web page open? This is >> a problem that's outside of the scope of both the IETF and W3C >> groups, but it's a problem in any case. > Isn't this the "Web Application / Background Page" problem - that is, > having stuff run in the browser when no pages are open? > I believe there are W3C groups hard at work on that; we should punt it > to them if we can. > > Harald From Hannes.Tschofenig@gmx.net Tue Jun 14 07:33:37 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3E311E8147 for ; Tue, 14 Jun 2011 07:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+8Md0cs28qP for ; Tue, 14 Jun 2011 07:33:36 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 27CDE11E8131 for ; Tue, 14 Jun 2011 07:33:35 -0700 (PDT) Received: (qmail 23081 invoked by uid 0); 14 Jun 2011 14:33:34 -0000 Received: from 192.100.112.210 by rms-de009.v300.gmx.net with HTTP Content-Type: multipart/alternative; boundary="========GMXBoundary43771308062011482861" Date: Tue, 14 Jun 2011 16:33:31 +0200 From: "Hannes Tschofenig" Message-ID: <20110614143331.43770@gmx.net> MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com,rtcweb@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: GMX.net Web Mailer x-registered: 0 X-GMX-UID: dASWKXBwa0A7XJIMtzAzTu4/Njh6dI6r Subject: Re: [rtcweb] How do we implement SIP event subscription in RTCweb? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 14:33:37 -0000 --========GMXBoundary43771308062011482861 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Igor, I do not quite understand where you are heading with your question. Your question can be interpreted in two ways, namely: a) How do I implement SIP event subscription alike concepts in a browser? (without using SIP itself but with browser technologies) b) I want to provide interworking with an existing SIP implementation that uses the SIP event package: how do I do it? In any case, you need to provide more details about what you want to accomplish in order for someone to provide you a good answer. For example, you may want to provide some information about * what data would you like to subscribe to, * where is the data, * who is supposed to receive it? Ciao Hannes PS: Your remark that maintaining connectivity alive for asynchronous communication is correct but what do you want to do if that's your desired functionality? This aspect is independent of SIP, XMPP and the Web. ----- Ursprüngliche Nachricht ----- Von: Igor Faynberg Gesendet: 11.06.11 01:01 Uhr An: rtcweb@ietf.org Betreff: [rtcweb] How do we implement SIP event subscription in RTCweb? A question. When SIP is implemented in an application within the present RTCweb architecture, how exactly could we use WebSockets for SUBSCRIBE/NOTIFY? It appears to me that the only way to achieve that is to open a persistent connection. Am I right? If so, is it not a problem, given the potential duration of such connections and potential tie-up of network resources? If not, how else could that be done? With many thanks, Igor _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --========GMXBoundary43771308062011482861 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Igor,=
=20
=20 I do not quite understand where you are heading with your question.
= =20
=20 Your question can be interpreted in two ways, namely:
=20
=20 a) How do I implement SIP event subscription alike concepts in a browser?=20 (without using SIP itself but with browser technologies)
=20
=20 b) I want to provide interworking with an existing SIP implementation that = uses the SIP event package: how do I do it?
=20
=20 In any case, you need to provide more details about what you want to accomp= lish in order for someone to provide you a good answer.
=20
=20 For example, you may want to provide some information about
=20 * what data would you like to subscribe to,
=20 * where is the data,
=20 * who is supposed to receive it?  
=20
=20 Ciao
=20 Hannes
=20
=20 PS: Your remark that maintaining connectivity alive for asynchronous commun= ication is correct but what do you want to do if that's your desired functi= onality?
=20 This aspect is independent of SIP, XMPP and the Web.
=20
=20

=20 =C2=A0

=20
=20

=20 ----- = Urspr=C3=BCngliche Nachricht -----

=20

=20 Von: I= gor Faynberg

=20

=20 Gesend= et: 11.06.11 01:01 Uhr

=20

=20 An: rt= cweb@ietf.org

=20

=20 Betref= f: [rtcweb] How do we implement SIP event subscription in RTCweb?

=20
=20
=20
=20 
=20
A question.=20

When SIP is implemented in an application within the present RTCweb=20
architecture, how exactly could we use WebSockets for SUBSCRIBE/NOTIFY?=20

It appears to me that the only way to achieve that is to open a=20
persistent connection.  Am I right?=20

If so, is it not a problem, given the potential duration of such=20
connections and potential tie-up of network resources?=20

If not, how else could that be done?=20

With many thanks,=20

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

=20 =C2=A0

=20 --========GMXBoundary43771308062011482861-- From igor.faynberg@alcatel-lucent.com Tue Jun 14 09:52:55 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696E111E808A for ; Tue, 14 Jun 2011 09:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-koXsnLSydK for ; Tue, 14 Jun 2011 09:52:54 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4A811E807F for ; Tue, 14 Jun 2011 09:52:54 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p5EGqpkk002367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jun 2011 11:52:51 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5EGqpLx027581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Jun 2011 11:52:51 -0500 Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173] (may be forged)) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5EGqQTK005643; Tue, 14 Jun 2011 11:52:37 -0500 (CDT) Message-ID: <4DF791C8.70203@alcatel-lucent.com> Date: Tue, 14 Jun 2011 12:52:24 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Hannes Tschofenig References: <20110614143331.43770@gmx.net> In-Reply-To: <20110614143331.43770@gmx.net> Content-Type: multipart/alternative; boundary="------------070102060704080703000108" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] How do we implement SIP event subscription in RTCweb? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:52:55 -0000 This is a multi-part message in MIME format. --------------070102060704080703000108 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hannes, Thanks for following up! I actually think that my question has already been answered, but to reply to your query, I think that of the two options you mentioned, the closest one to my question is ... b) I want to provide interworking with an existing SIP implementation that uses the SIP event package: how do I do it? ... More precisely, the problem statement was: I need to have SIP on my Internet appliance. Now that I have only the browser to rely on, how do I implement it? I assume that I have 1) JavaScript to program in and 2) the WebSockets interface. All is well until asynchronous processing comes in. To implement SUBSCRIBE/NOTIFY, I would need to be able to receive the NOTIFY messages (i.e., catch interrupts) whenever they come. I thought that the only way to achieve that was to keep an open TCP connection... forever. (I was under the impression that this was not considered a good practice--both in terms of resending "keep alive" and holding resources (such as NAT). The responses that I got so far confirmed that my assumption about keeping a TCP connection open was right, but that the practice of keeping a TCP connection open has no longer been considered wasteful and is, in fact, implemented. There was also a message about the necessity of being tied to the page, but this appears to me as something that can be meaningfully worked around. I guess more clarifications and implementation reports will come my way. I do think it is critical that SIP be implementable in the browser-only environment. I understand the reasons for the decision NOT to have SIP (or, for that matter ICE) as part of the browser, but that implied that SIP can be implemented in the application. Igor On 6/14/2011 10:33 AM, Hannes Tschofenig wrote: > Hi Igor, > > I do not quite understand where you are heading with your question. > > Your question can be interpreted in two ways, namely: > > a) How do I implement SIP event subscription alike concepts in a browser? > (without using SIP itself but with browser technologies) > > b) I want to provide interworking with an existing SIP implementation > that uses the SIP event package: how do I do it? > > In any case, you need to provide more details about what you want to > accomplish in order for someone to provide you a good answer. > > For example, you may want to provide some information about > * what data would you like to subscribe to, > * where is the data, > * who is supposed to receive it? > > Ciao > Hannes > > PS: Your remark that maintaining connectivity alive for asynchronous > communication is correct but what do you want to do if that's your > desired functionality? > This aspect is independent of SIP, XMPP and the Web. > >> ----- Ursprüngliche Nachricht ----- >> >> Von: Igor Faynberg >> >> Gesendet: 11.06.11 01:01 Uhr >> >> An: rtcweb@ietf.org >> >> Betreff: [rtcweb] How do we implement SIP event subscription in RTCweb? >> >> >> >> A question. >> >> When SIP is implemented in an application within the present RTCweb >> architecture, how exactly could we use WebSockets for SUBSCRIBE/NOTIFY? >> >> It appears to me that the only way to achieve that is to open a >> persistent connection. Am I right? >> >> If so, is it not a problem, given the potential duration of such >> connections and potential tie-up of network resources? >> >> If not, how else could that be done? >> >> With many thanks, >> >> Igor >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > --------------070102060704080703000108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hannes,

Thanks for following up! I actually think that my question has already been answered, but to reply to  your query, I think that of  the two options you mentioned, the closest one to my question  is

...
b) I want to provide interworking with an existing SIP implementation that uses the SIP event package: how do I do it?
...

More precisely, the problem statement was: I need to have SIP on my Internet appliance. Now that I have only the browser to rely on, how do I implement it?  

 I assume that I have 1) JavaScript to program in and 2) the WebSockets interface.  All is well until asynchronous processing comes in.  To implement SUBSCRIBE/NOTIFY, I would need to be able to receive the NOTIFY messages (i.e., catch interrupts) whenever they come.   I thought that the only way to achieve that was to keep an open TCP connection... forever.  (I was under the impression that this was not considered a good practice--both in terms of resending "keep alive" and holding resources (such as NAT).

The responses that I got so far confirmed that my assumption about keeping a TCP connection open  was right, but that the practice of keeping a TCP connection open has no longer been considered wasteful and is, in fact, implemented.  There was also a message about the necessity of being tied to the page, but this appears to me as something that can be meaningfully worked around.

I guess more clarifications and implementation reports will come my way.  I do think it is critical that SIP be implementable in the browser-only environment.  I understand the reasons for the decision NOT to have SIP (or, for that matter ICE) as part of the browser, but that implied that SIP can be implemented in the application.

Igor

On 6/14/2011 10:33 AM, Hannes Tschofenig wrote:
Hi Igor,

I do not quite understand where you are heading with your question.

Your question can be interpreted in two ways, namely:

a) How do I implement SIP event subscription alike concepts in a browser?
(without using SIP itself but with browser technologies)

b) I want to provide interworking with an existing SIP implementation that uses the SIP event package: how do I do it?

In any case, you need to provide more details about what you want to accomplish in order for someone to provide you a good answer.

For example, you may want to provide some information about
* what data would you like to subscribe to,
* where is the data,
* who is supposed to receive it?  

Ciao
Hannes

PS: Your remark that maintaining connectivity alive for asynchronous communication is correct but what do you want to do if that's your desired functionality?
This aspect is independent of SIP, XMPP and the Web.

 

----- Ursprüngliche Nachricht -----

Von: Igor Faynberg

Gesendet: 11.06.11 01:01 Uhr

An: rtcweb@ietf.org

Betreff: [rtcweb] How do we implement SIP event subscription in RTCweb?


 
A question. 

When SIP is implemented in an application within the present RTCweb 
architecture, how exactly could we use WebSockets for SUBSCRIBE/NOTIFY? 

It appears to me that the only way to achieve that is to open a 
persistent connection.  Am I right? 

If so, is it not a problem, given the potential duration of such 
connections and potential tie-up of network resources? 

If not, how else could that be done? 

With many thanks, 

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

 
--------------070102060704080703000108-- From mthornbu@adobe.com Tue Jun 14 18:08:30 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35E71F0C6D for ; Tue, 14 Jun 2011 18:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.835 X-Spam-Level: X-Spam-Status: No, score=-105.835 tagged_above=-999 required=5 tests=[AWL=0.764, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laQPK6OMKWuq for ; Tue, 14 Jun 2011 18:08:30 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id B6D421F0C68 for ; Tue, 14 Jun 2011 18:08:29 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKTfgGDK5A1O/epi0ifk5H8M8nN2icj6HT@postini.com; Tue, 14 Jun 2011 18:08:29 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p5F17JES018742 for ; Tue, 14 Jun 2011 18:07:20 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id p5F18PaO013647 for ; Tue, 14 Jun 2011 18:08:26 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Tue, 14 Jun 2011 18:08:25 -0700 From: Michael Thornburgh To: "rtcweb@ietf.org" Date: Tue, 14 Jun 2011 18:08:24 -0700 Thread-Topic: Re: [rtcweb] RTP multiplexing - my understanding of status Thread-Index: Acwq+LmjtvTW3qZfS/itMBSnkrYTvQ== Message-ID: <02485FF93524F8408ECA9608E47D9F2007AF8175CE@nambx05.corp.adobe.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: [rtcweb] RTP multiplexing - my understanding of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 01:08:30 -0000 (apologies for breaking the "in-reply-to" threadiness; i've been reading th= e list through the archive web page) On 6/13/2011 11:49:34 -0400, Randell Jesup wrote: > I assume the Matthew Kaufman here is the same one who presented the paper= on RTMFP for Adobe at IETF 77. :-) From the email address, I take it you w= ork for Skype now. > While that protocol per se may be out-of-bounds (proprietary, patents), s= ome of the problems they were trying to solve aren't entirely different tha= n what we're looking at here. except for "interoperation with legacy systems" and "no plug-ins", the prob= lems we set out to solve with RTMFP were almost exactly the same: secure, r= eal-time, congestion controlled, safe P2P communication of voice, video, an= d data in the browser, with NAT traversal. > In particular, there may be advantages in setup time and complexity to re= ducing the number of "5-tuples" required and multiplexing data. For example= , if you need to poke holes in a firewall using UPnP it can be painful and = slow (to the point where we at WorldGate pre-poked holes to use if a call c= ame in, and we had to keep 2 or 3 sets of holes open to handle call-waiting= cases, etc). Even ignoring that and just considering ICE, the number of me= ssages to open N ports is a lot higher than 1 or a pair of ports, and it ma= y also increase the chance of a single-packet loss interfering and slowing = down convergence (or pushing ICE to select a sub-optimal connection method)= . Also, what are the odds of ICE selecting different methods for the differ= ent streams? RTMFP takes multiplexing over UDP further: communications with multiple dis= tinct endpoints can (if desired) share the same UDP port on a host, which c= an make more efficient use of NAT resources and traversal-helpers (the "Red= irectors" and "Forwarders" from Matthew's presentation at IETF 77 [1, pp19-= 30]). > As mentioned, if this is done as a shim/multiplex layer it simplifies int= erop with existing voice gateways. Side note: there is a draft for (just) m= ultiplexing RTP and RTCP which I had weighed in on and supported; I forget = where it stands currently. > Another goal from RTMFP that is worth considering is consolidated congest= ion control - doing congestion control and bandwidth measurement/adaptation= across all the streams exchanged with another endpoint together. This is s= implified by using a single or smaller number of "5-tuples", though it isn'= t gated on that. > Thought should be given to some of the other goals of RTMFP and if they'r= e in-scope or not. (IP addr changes, etc). some other goals of RTMFP to which thought should be given: * all traffic is congestion controlled all the time (i know RTCWeb is alr= eady thinking about this, but we think it's critical so i'm mentioning it a= gain) * consolidated congestion control for prioritization of traffic (for e= xample, control/signaling over media, audio over video & data, real-time da= ta over bulk data) * multi-endpoint cooperative congestion control for real-time vs not-r= eal-time concurrent communications [1, p34] * full or partial reliability for data (and audio & video media) * ordered or un-ordered (ASAP) receipt of messages * fragmentation/reassembly of large (>504 bytes) data messages * flow association to provide unambiguous channel grouping of distinct pa= rallel communications between a single pair of endpoints, still sharing a s= ingle security association, UDP port, congestion control and prioritization= domain * perform endpoint "white listing" based on ephemeral cryptographic ident= ity instead of IP address/port number, while still using end-to-end encrypt= ion keying Michael Thornburgh [1] http://www.ietf.org/proceedings/10mar/slides/tsvarea-1.pdf From harald@alvestrand.no Thu Jun 16 05:35:48 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9E611E808E for ; Thu, 16 Jun 2011 05:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fhDY8z+-909 for ; Thu, 16 Jun 2011 05:35:48 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 14EF311E8088 for ; Thu, 16 Jun 2011 05:35:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 996E839E155 for ; Thu, 16 Jun 2011 14:34:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCPjvkl9HPQx for ; Thu, 16 Jun 2011 14:34:48 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id E70D939E091 for ; Thu, 16 Jun 2011 14:34:48 +0200 (CEST) Message-ID: <4DF9F8A1.1040503@alvestrand.no> Date: Thu, 16 Jun 2011 14:35:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Use case addition: Interoperable calling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 12:35:49 -0000 At the interim meeting discussion, the point was brought up that the use cases document at the moment doesn't contain any example where interoperability between clients driven by different Web applications could be an issue. Rather than leaving this for later, I'll try to suggest some text below, in a form that should be easy to insert into draft-holmberg. Comments on the below? Too little? Too much? Wrong? Just right? Harald ---------------------------------------------------------------------- 4.X. Use-case: Simple video communication service with inter-operator calling 4.X.1. Description Two users have logged into two different web applications, provided by different service providers. The service providers are interconnected by some means, but exchange no more information about the users than what can be carried using SIP. (Note: More profiling of what this means may be needed.) Each web service publishes information about user login status for users that have a relationship with the other user; how this is established is out of scope. The same functionality as in the "Simple Video Communication Service" is available. The same issues with connectivity apply. 4.X.2 Derived requirements (This describes requirements adding to the existing requirements) FX1 The browser MUST be able to initiate and accept a media session using a common, standard protocol where the data needed for establishment can be carried in SIP. FX2 The browser MUST support a baseline audio and video codec FX3 There SHOULD be a mapping of the minimum needed data for setting up connections into SIP, so that the restriction to SIP-carriable data can be verified. (There might be more here) From stefan.lk.hakansson@ericsson.com Thu Jun 16 06:26:27 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1DE11E80E0 for ; Thu, 16 Jun 2011 06:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG9zsSiLiPZl for ; Thu, 16 Jun 2011 06:26:26 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2B09911E8071 for ; Thu, 16 Jun 2011 06:26:25 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-d3-4dfa0480615b Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CD.A8.20773.0840AFD4; Thu, 16 Jun 2011 15:26:24 +0200 (CEST) Received: from [150.132.141.128] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 16 Jun 2011 15:26:24 +0200 Message-ID: <4DFA047F.5050900@ericsson.com> Date: Thu, 16 Jun 2011 15:26:23 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org, harald@alvestrand.no References: <4DF9F8A1.1040503@alvestrand.no> In-Reply-To: <4DF9F8A1.1040503@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Use case addition: Interoperable calling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 13:26:27 -0000 I think this additional use case makes a lot of sense. Some comments in line. On 2011-06-16 14:35, Harald Alvestrand wrote: > At the interim meeting discussion, the point was brought up that the use > cases document at the moment doesn't contain any example where > interoperability between clients driven by different Web applications > could be an issue. > > Rather than leaving this for later, I'll try to suggest some text below, > in a form that should be easy to insert into draft-holmberg. > > Comments on the below? Too little? Too much? Wrong? Just right? > > Harald > > ---------------------------------------------------------------------- > > 4.X. Use-case: Simple video communication service with inter-operator > calling > > 4.X.1. Description > > Two users have logged into two different web applications, provided by > different > service providers. > > The service providers are interconnected by some means, but exchange no > more information about the users than what can be carried using SIP. > (Note: More profiling of what this means may be needed.) > > Each web service publishes information about user login status for users > that have a relationship with the other user; how this is established is > out of scope. > > The same functionality as in the "Simple Video Communication Service" is > available. > The same issues with connectivity apply. > > 4.X.2 Derived requirements > > (This describes requirements adding to the existing requirements) > > FX1 The browser MUST be able to initiate and accept a media session > using a common, standard protocol where the data needed for > establishment can be carried in SIP. Do you by "common, standard protocol" mean http, WS or something else? > > FX2 The browser MUST support a baseline audio and video codec Related to the current F18. Video is added, and then I guess it is up for discussion if the telephony codec is sufficient as baseline audio. > > FX3 There SHOULD be a mapping of the minimum needed data for setting up > connections into SIP, so that the restriction to SIP-carriable data can > be verified. Do you mean a mapping document the WG produces? Or do you mean that the browser should have some "SIP-validator" function implemented? > > (There might be more here) > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Thu Jun 16 06:53:21 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6712D11E80E3 for ; Thu, 16 Jun 2011 06:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2Slp1wNn-oO for ; Thu, 16 Jun 2011 06:53:21 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A294911E80D7 for ; Thu, 16 Jun 2011 06:53:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A2C6339E176; Thu, 16 Jun 2011 15:52:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3dfDtrrKPnT; Thu, 16 Jun 2011 15:52:21 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id AF41C39E091; Thu, 16 Jun 2011 15:52:21 +0200 (CEST) Message-ID: <4DFA0ACE.5010207@alvestrand.no> Date: Thu, 16 Jun 2011 15:53:18 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= References: <4DF9F8A1.1040503@alvestrand.no> <4DFA047F.5050900@ericsson.com> In-Reply-To: <4DFA047F.5050900@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use case addition: Interoperable calling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 13:53:21 -0000 On 06/16/11 15:26, Stefan H=E5kansson LK wrote: > I think this additional use case makes a lot of sense. Some comments=20 > in line. > On 2011-06-16 14:35, Harald Alvestrand wrote: >> At the interim meeting discussion, the point was brought up that the u= se >> cases document at the moment doesn't contain any example where >> interoperability between clients driven by different Web applications >> could be an issue. >> >> Rather than leaving this for later, I'll try to suggest some text belo= w, >> in a form that should be easy to insert into draft-holmberg. >> >> Comments on the below? Too little? Too much? Wrong? Just right? >> >> Harald >> >> ----------------------------------------------------------------------= >> >> 4.X. Use-case: Simple video communication service with inter-operator >> calling >> >> 4.X.1. Description >> >> Two users have logged into two different web applications, provided by= >> different >> service providers. >> >> The service providers are interconnected by some means, but exchange n= o >> more information about the users than what can be carried using SIP. >> (Note: More profiling of what this means may be needed.) >> >> Each web service publishes information about user login status for use= rs >> that have a relationship with the other user; how this is established = is >> out of scope. >> >> The same functionality as in the "Simple Video Communication Service" = is >> available. >> The same issues with connectivity apply. >> >> 4.X.2 Derived requirements >> >> (This describes requirements adding to the existing requirements) >> >> FX1 The browser MUST be able to initiate and accept a media session >> using a common, standard protocol where the data needed for >> establishment can be carried in SIP. > Do you by "common, standard protocol" mean http, WS or something else?= I was actually thinking "common" as in "both parties implement it", and=20 thinking of the browser-to-browser connection, not the=20 browser-to-webserver connection. ICE + RTP is the combination I was thinking about, but naming protocols=20 in requirements isn't nice if we can avoid it. >> >> FX2 The browser MUST support a baseline audio and video codec > Related to the current F18. Video is added, and then I guess it is up=20 > for discussion if the telephony codec is sufficient as baseline audio. Good argument to have. I think U-Law falls way short of a good baseline, = but it's not obvious that this falls out of any present usecase. >> >> FX3 There SHOULD be a mapping of the minimum needed data for setting u= p >> connections into SIP, so that the restriction to SIP-carriable data ca= n >> be verified. > Do you mean a mapping document the WG produces? Or do you mean that=20 > the browser should have some "SIP-validator" function implemented? A mapping document that the WG produces would satisfy me as a way to=20 show that it can be mapped. Code is even better, of course. From stefan.lk.hakansson@ericsson.com Thu Jun 16 07:09:30 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B5911E80FD for ; Thu, 16 Jun 2011 07:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Scu8pHdScjHx for ; Thu, 16 Jun 2011 07:09:30 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B5ABD11E80F5 for ; Thu, 16 Jun 2011 07:09:29 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-6f-4dfa0e98e7ae Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id ED.D3.09774.89E0AFD4; Thu, 16 Jun 2011 16:09:28 +0200 (CEST) Received: from [150.132.141.128] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 16 Jun 2011 16:09:26 +0200 Message-ID: <4DFA0E95.2050807@ericsson.com> Date: Thu, 16 Jun 2011 16:09:25 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Harald Alvestrand References: <4DF9F8A1.1040503@alvestrand.no> <4DFA047F.5050900@ericsson.com> <4DFA0ACE.5010207@alvestrand.no> In-Reply-To: <4DFA0ACE.5010207@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Use case addition: Interoperable calling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 14:09:30 -0000 On 2011-06-16 15:53, Harald Alvestrand wrote: > On 06/16/11 15:26, Stefan Håkansson LK wrote: >> I think this additional use case makes a lot of sense. Some comments >> in line. >> On 2011-06-16 14:35, Harald Alvestrand wrote: >>> At the interim meeting discussion, the point was brought up that the use >>> cases document at the moment doesn't contain any example where >>> interoperability between clients driven by different Web applications >>> could be an issue. >>> >>> Rather than leaving this for later, I'll try to suggest some text below, >>> in a form that should be easy to insert into draft-holmberg. >>> >>> Comments on the below? Too little? Too much? Wrong? Just right? >>> >>> Harald >>> >>> ---------------------------------------------------------------------- >>> >>> 4.X. Use-case: Simple video communication service with inter-operator >>> calling >>> >>> 4.X.1. Description >>> >>> Two users have logged into two different web applications, provided by >>> different >>> service providers. >>> >>> The service providers are interconnected by some means, but exchange no >>> more information about the users than what can be carried using SIP. >>> (Note: More profiling of what this means may be needed.) >>> >>> Each web service publishes information about user login status for users >>> that have a relationship with the other user; how this is established is >>> out of scope. >>> >>> The same functionality as in the "Simple Video Communication Service" is >>> available. >>> The same issues with connectivity apply. >>> >>> 4.X.2 Derived requirements >>> >>> (This describes requirements adding to the existing requirements) >>> >>> FX1 The browser MUST be able to initiate and accept a media session >>> using a common, standard protocol where the data needed for >>> establishment can be carried in SIP. >> Do you by "common, standard protocol" mean http, WS or something else? > I was actually thinking "common" as in "both parties implement it", and > thinking of the browser-to-browser connection, not the > browser-to-webserver connection. > > ICE + RTP is the combination I was thinking about, but naming protocols > in requirements isn't nice if we can avoid it. Aha, then I get it. The new part is "data needed for establishment can be carried in SIP"; the rest is already covered (F2 - F4). Maybe it should be slightly re-phrased; when I read it "using a common, standard protocol" confuses, perhaps those words could just be removed? If there is a need to state that the media session should use "a common, standard protocol" it is much earlier, this is relevant already to the first use case. >>> >>> FX2 The browser MUST support a baseline audio and video codec >> Related to the current F18. Video is added, and then I guess it is up >> for discussion if the telephony codec is sufficient as baseline audio. > Good argument to have. I think U-Law falls way short of a good baseline, > but it's not obvious that this falls out of any present usecase. >>> >>> FX3 There SHOULD be a mapping of the minimum needed data for setting up >>> connections into SIP, so that the restriction to SIP-carriable data can >>> be verified. >> Do you mean a mapping document the WG produces? Or do you mean that >> the browser should have some "SIP-validator" function implemented? > > A mapping document that the WG produces would satisfy me as a way to > show that it can be mapped. > Code is even better, of course. > > > From emcho@sip-communicator.org Thu Jun 16 08:40:26 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222B021F848B for ; Thu, 16 Jun 2011 08:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJuoK8T88Zug for ; Thu, 16 Jun 2011 08:40:25 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6417821F848A for ; Thu, 16 Jun 2011 08:40:25 -0700 (PDT) Received: by vxg33 with SMTP id 33so1618487vxg.31 for ; Thu, 16 Jun 2011 08:40:24 -0700 (PDT) Received: by 10.220.65.40 with SMTP id g40mr369550vci.104.1308238824641; Thu, 16 Jun 2011 08:40:24 -0700 (PDT) Received: from mail-vx0-f172.google.com ([209.85.220.172]) by mx.google.com with ESMTPS id t20sm255562vci.34.2011.06.16.08.40.24 (version=SSLv3 cipher=OTHER); Thu, 16 Jun 2011 08:40:24 -0700 (PDT) Received: by vxg33 with SMTP id 33so1618473vxg.31 for ; Thu, 16 Jun 2011 08:40:24 -0700 (PDT) Received: by 10.52.98.40 with SMTP id ef8mr1450653vdb.54.1308238824167; Thu, 16 Jun 2011 08:40:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.169.106 with HTTP; Thu, 16 Jun 2011 08:40:04 -0700 (PDT) In-Reply-To: <4DF9F8A1.1040503@alvestrand.no> References: <4DF9F8A1.1040503@alvestrand.no> From: Emil Ivov Date: Thu, 16 Jun 2011 17:40:04 +0200 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=20cf307f37fc655a3e04a5d6161e Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Use case addition: Interoperable calling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 15:40:26 -0000 --20cf307f37fc655a3e04a5d6161e Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 16, 2011 at 2:35 PM, Harald Alvestrand wrote: > > Each web service publishes information about user login status for users > that have a relationship with the other user; how this is established is out > of scope. > I am not sure if I am understanding this part correctly. To me it sounds like some sort of presence exchanged between users and, if so, I was wondering if it was really necessary for inter-operator communication. Emil --20cf307f37fc655a3e04a5d6161e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jun 16, 2011 at 2:35 PM, Harald = Alvestrand <ha= rald@alvestrand.no> wrote:

Each web service publishes information about user login status for users th= at have a relationship with the other user; how this is established is out = of scope.

I am not sure if I am understanding this= part correctly. To me it sounds like some sort of presence exchanged betwe= en users and, if so, I was wondering if it was really necessary for inter-o= perator communication.

Emil
--20cf307f37fc655a3e04a5d6161e-- From harald@alvestrand.no Thu Jun 16 09:20:47 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1224E21F8467 for ; Thu, 16 Jun 2011 09:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo4t6p3naeoq for ; Thu, 16 Jun 2011 09:20:46 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E5A0F21F8466 for ; Thu, 16 Jun 2011 09:20:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BA15C39E176; Thu, 16 Jun 2011 18:19:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY0eGc375NmY; Thu, 16 Jun 2011 18:19:46 +0200 (CEST) Received: from [192.168.0.2] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id A0F8839E091; Thu, 16 Jun 2011 18:19:46 +0200 (CEST) Message-ID: <4DFA2D5C.3090708@alvestrand.no> Date: Thu, 16 Jun 2011 18:20:44 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Emil Ivov References: <4DF9F8A1.1040503@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090707030000060005080407" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Use case addition: Interoperable calling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 16:20:47 -0000 This is a multi-part message in MIME format. --------------090707030000060005080407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/16/11 17:40, Emil Ivov wrote: > > > On Thu, Jun 16, 2011 at 2:35 PM, Harald Alvestrand > > wrote: > > > Each web service publishes information about user login status for > users that have a relationship with the other user; how this is > established is out of scope. > > > I am not sure if I am understanding this part correctly. To me it > sounds like some sort of presence exchanged between users and, if so, > I was wondering if it was really necessary for inter-operator > communication. I don't know - all chat networks and web-based calling networks use network presence pretty heavily; the phone network's able to live without it, assuming that "everyone's there all the time". The only reason for mentioning it here is that it's out of our scope to standardize it - if we don't mention it, some people might believe it's in scope, others that it's out of scope. --------------090707030000060005080407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/16/11 17:40, Emil Ivov wrote:


On Thu, Jun 16, 2011 at 2:35 PM, Harald Alvestrand <harald@alvestrand.no> wrote:

Each web service publishes information about user login status for users that have a relationship with the other user; how this is established is out of scope.

I am not sure if I am understanding this part correctly. To me it sounds like some sort of presence exchanged between users and, if so, I was wondering if it was really necessary for inter-operator communication.
I don't know - all chat networks and web-based calling networks use network presence pretty heavily; the phone network's able to live without it, assuming that "everyone's there all the time".

The only reason for mentioning it here is that it's out of our scope to standardize it - if we don't mention it, some people might believe it's in scope, others that it's out of scope.


--------------090707030000060005080407-- From tedh@ipinfusion.com Thu Jun 16 21:30:55 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3534E11E8153 for ; Thu, 16 Jun 2011 21:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwSN+M2fo0Bx for ; Thu, 16 Jun 2011 21:30:53 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B109711E8080 for ; Thu, 16 Jun 2011 21:30:52 -0700 (PDT) Received: by vws12 with SMTP id 12so2136769vws.31 for ; Thu, 16 Jun 2011 21:30:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.94.239 with SMTP id df15mr2245334vdb.254.1308285050848; Thu, 16 Jun 2011 21:30:50 -0700 (PDT) Received: by 10.52.159.132 with HTTP; Thu, 16 Jun 2011 21:30:50 -0700 (PDT) Date: Thu, 16 Jun 2011 21:30:50 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf307f3ac6b886e704a5e0d983 Subject: [rtcweb] Call for comment on document split X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 04:34:59 -0000 --20cf307f3ac6b886e704a5e0d983 Content-Type: text/plain; charset=ISO-8859-1 Hi Folks, In order to allow folks time to submit draft-ietf-rtcweb versions in time for the upcoming 00 deadline, the chairs would like to first outline our theory of the document splits to meet our chartered milestones (to refresh you self on them: http://datatracker.ietf.org/wg/rtcweb/charter/) in the August time frame. We'd like to have one document which describes the use cases. We'd like to have one document that gives a system overview and outlines the overall model. We'd like to have one document that describes the privacy and security model. We'd like to have one document that describes the connectivity model (for NAT traversal etc.). Later documents will be: signaling and negotiation methods, media transports, datagram transport for non-media data, and one or more documents on media processing and codecs. Note that this set of "documents we'd like" is missing one that says "requirements". Discussion among the chairs has come to consensus that we have at least three different kinds of requirements being discussed and the the use of the term "requirement" is hindering both our internal discussion and the balance of work between us and the W3C at the moment. So, we'd like to have the focus be on what the parts of the system *do* within the context of a system overview, rather than on a discussion of requirements or, even worse, a meta discussion of what the word "requirements" means in particular contexts. If folks our okay with this document set, the chairs will then appoint editors from among those who have contributed text so far. This may mean that the initial -00 versions have a strong resemblance to the individual submissions they'd already presented; it also may not. We'd like to remind everyone that taking on the role of document editor in an IETF context means accepting the responsibility to make the document reflect the consensus of the group. If a WG -00 is missing items or needs revision to meet the needs of the group, in other words, that's normal--send text. Ted, Magnus, and Cullen --20cf307f3ac6b886e704a5e0d983 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Folks,

In order to allow folks time to submit draft-ietf-rtcweb versions in=20 time for the upcoming 00 deadline, the chairs would like to first=20 outline our theory of the document splits to meet our chartered=20 milestones (to refresh you self on them: http://datatracker.ietf.org/wg/r= tcweb/charter/) in the August time frame.

We'd like to have one document which describes the use cases.
We'd like to have one document that gives a system overview and outline= s the overall model.
We'd like to have one document that describes the privacy and security = model.
We'd like to have one document that =A0describes the connectivity model= (for NAT traversal etc.).

Later documents will be: signaling and negotiation methods, media=20 transports, datagram transport for non-media data, and one or more=20 documents on media processing and codecs.

Note that this set of "documents we'd like" is missing one th= at says=20 "requirements". =A0Discussion among the chairs has come to consen= sus that=20 we have at least three different kinds of requirements being discussed=20 and the the use of the term "requirement" is hindering both our i= nternal discussion and the balance of work between us and the W3C at the=20 moment. =A0So, we'd like to have the focus be on what the parts of the= =20 system *do* within the context of a system overview, rather than on a=20 discussion of requirements or, even worse, a meta discussion of what the word "requirements" means in particular contexts.

If folks our okay with this document set, the chairs will then appoint=20 editors from among those who have contributed text so far. =A0This may=20 mean that the initial -00 versions have a strong resemblance to the=20 individual submissions they'd already presented; it also may not. =A0We= 'd=20 like to remind everyone that taking on the role of document editor in an IETF context means accepting the responsibility to make the document=20 reflect the consensus of the group. =A0If a WG -00 is missing items or=20 needs revision to meet the needs of the group, in other words, that's= =20 normal--send text.

Ted, Magnus, and Cullen
--20cf307f3ac6b886e704a5e0d983-- From dhc@dcrocker.net Thu Jun 16 22:21:25 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA7711E808F for ; Thu, 16 Jun 2011 22:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.594 X-Spam-Level: X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJJYCfFiK0Ml for ; Thu, 16 Jun 2011 22:21:25 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 049D011E8085 for ; Thu, 16 Jun 2011 22:21:24 -0700 (PDT) Received: from [192.168.1.15] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p5H5LIeS023755 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2011 22:21:23 -0700 Message-ID: <4DFAE451.9030105@dcrocker.net> Date: Thu, 16 Jun 2011 22:21:21 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Ted Hardie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 16 Jun 2011 22:21:24 -0700 (PDT) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for comment on document split X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 05:21:25 -0000 On 6/16/2011 9:30 PM, Ted Hardie wrote: > We'd like to have one document which describes the use cases. > We'd like to have one document that gives a system overview and outlines the > overall model. > We'd like to have one document that describes the privacy and security model. > We'd like to have one document that describes the connectivity model (for NAT > traversal etc.). > > Later documents will be: signaling and negotiation methods, media transports, > datagram transport for non-media data, and one or more documents on media > processing and codecs. If someone wants to implement the simplest, core capability that is useful within this context of service, how many docs are they going to have to read? Which ones? How long before they will be written? For classic Web, I think it is still just 2. Same for email. My question is motivated by the usual concern about barriers to adoption that can stymie new services. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From christer.holmberg@ericsson.com Fri Jun 17 00:16:04 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35E511E80D4 for ; Fri, 17 Jun 2011 00:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6EuocGMB6VG for ; Fri, 17 Jun 2011 00:16:03 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8474011E8083 for ; Fri, 17 Jun 2011 00:16:00 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-f0-4dfaff2fbacb Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 75.C8.09774.F2FFAFD4; Fri, 17 Jun 2011 09:15:59 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 17 Jun 2011 09:15:56 +0200 From: Christer Holmberg To: Ted Hardie , "rtcweb@ietf.org" Date: Fri, 17 Jun 2011 09:15:56 +0200 Thread-Topic: [rtcweb] Call for comment on document split Thread-Index: Acwsp+0jRTFm1ZJlSDGwBT9i02Uj7QAFm1JA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3E71AE@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585194E3E71AEESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Call for comment on document split X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 07:16:05 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3E71AEESESSCMS0356e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I think the proposed document split looks very good. Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ted Hardie Sent: 17. kes=E4kuuta 2011 7:31 To: rtcweb@ietf.org Subject: [rtcweb] Call for comment on document split Hi Folks, In order to allow folks time to submit draft-ietf-rtcweb versions in time f= or the upcoming 00 deadline, the chairs would like to first outline our the= ory of the document splits to meet our chartered milestones (to refresh you= self on them: http://datatracker.ietf.org/wg/rtcweb/charter/) in the Augus= t time frame. We'd like to have one document which describes the use cases. We'd like to have one document that gives a system overview and outlines th= e overall model. We'd like to have one document that describes the privacy and security mode= l. We'd like to have one document that describes the connectivity model (for = NAT traversal etc.). Later documents will be: signaling and negotiation methods, media transport= s, datagram transport for non-media data, and one or more documents on medi= a processing and codecs. Note that this set of "documents we'd like" is missing one that says "requi= rements". Discussion among the chairs has come to consensus that we have a= t least three different kinds of requirements being discussed and the the u= se of the term "requirement" is hindering both our internal discussion and = the balance of work between us and the W3C at the moment. So, we'd like to= have the focus be on what the parts of the system *do* within the context = of a system overview, rather than on a discussion of requirements or, even = worse, a meta discussion of what the word "requirements" means in particula= r contexts. If folks our okay with this document set, the chairs will then appoint edit= ors from among those who have contributed text so far. This may mean that = the initial -00 versions have a strong resemblance to the individual submis= sions they'd already presented; it also may not. We'd like to remind every= one that taking on the role of document editor in an IETF context means acc= epting the responsibility to make the document reflect the consensus of the= group. If a WG -00 is missing items or needs revision to meet the needs o= f the group, in other words, that's normal--send text. Ted, Magnus, and Cullen --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3E71AEESESSCMS0356e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I think the proposed document split looks very=20 good.
 
Regards,
 
Christer

From: rtcweb-bounces@ietf.org=20 [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted=20 Hardie
Sent: 17. kes=E4kuuta 2011 7:31
To:=20 rtcweb@ietf.org
Subject: [rtcweb] Call for comment on document= =20 split

Hi Folks,

In order to allow folks time to submit=20 draft-ietf-rtcweb versions in time for the upcoming 00 deadline, the chai= rs=20 would like to first outline our theory of the document splits to meet our= =20 chartered milestones (to refresh you self on them: http://datatracker.ietf.org/wg/rtcweb/charter/) in th= e=20 August time frame.

We'd like to have one document which describes = the=20 use cases.
We'd like to have one document that gives a system overview= and=20 outlines the overall model.
We'd like to have one document that descri= bes=20 the privacy and security model.
We'd like to have one document that=20  describes the connectivity model (for NAT traversal etc.).

L= ater=20 documents will be: signaling and negotiation methods, media transports,=20 datagram transport for non-media data, and one or more documents on media= =20 processing and codecs.

Note that this set of "documents we'd like"= is=20 missing one that says "requirements".  Discussion among the chairs h= as=20 come to consensus that we have at least three different kinds of requirem= ents=20 being discussed and the the use of the term "requirement" is hindering bo= th=20 our internal discussion and the balance of work between us and the W3C at= the=20 moment.  So, we'd like to have the focus be on what the parts of the= =20 system *do* within the context of a system overview, rather than on a=20 discussion of requirements or, even worse, a meta discussion of what the = word=20 "requirements" means in particular contexts.

If folks our okay wit= h=20 this document set, the chairs will then appoint editors from among those = who=20 have contributed text so far.  This may mean that the initial -00=20 versions have a strong resemblance to the individual submissions they'd=20 already presented; it also may not.  We'd like to remind everyone th= at=20 taking on the role of document editor in an IETF context means accepting = the=20 responsibility to make the document reflect the consensus of the group.=20  If a WG -00 is missing items or needs revision to meet the needs of= the=20 group, in other words, that's normal--send text.

Ted, Magnus, and= =20 Cullen
--_000_7F2072F1E0DE894DA4B517B93C6A0585194E3E71AEESESSCMS0356e_-- From magnus.westerlund@ericsson.com Fri Jun 17 00:55:43 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4258811E8096 for ; Fri, 17 Jun 2011 00:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leu5CWUL9bnh for ; Fri, 17 Jun 2011 00:55:42 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0BD11E808A for ; Fri, 17 Jun 2011 00:55:42 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-94-4dfb087cd92d Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2C.D0.20773.C780BFD4; Fri, 17 Jun 2011 09:55:41 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Fri, 17 Jun 2011 09:55:37 +0200 Message-ID: <4DFB0879.4080001@ericsson.com> Date: Fri, 17 Jun 2011 09:55:37 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "dcrocker@bbiw.net" References: <4DFAE451.9030105@dcrocker.net> In-Reply-To: <4DFAE451.9030105@dcrocker.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for comment on document split X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 07:55:43 -0000 On 2011-06-17 07:21, Dave CROCKER wrote: > > > On 6/16/2011 9:30 PM, Ted Hardie wrote: >> We'd like to have one document which describes the use cases. >> We'd like to have one document that gives a system overview and outlines the >> overall model. >> We'd like to have one document that describes the privacy and security model. >> We'd like to have one document that describes the connectivity model (for NAT >> traversal etc.). >> >> Later documents will be: signaling and negotiation methods, media transports, >> datagram transport for non-media data, and one or more documents on media >> processing and codecs. > > > If someone wants to implement the simplest, core capability that is useful > within this context of service, how many docs are they going to have to read? That will likely be the full set of standards track documents, and the overview to know how they fit together > > Which ones? How long before they will be written? The point of getting them written is exactly why we have this split. We try to distribute the editing load over a number of people and people expertise to get high quality documents. > > For classic Web, I think it is still just 2. Same for email. > > My question is motivated by the usual concern about barriers to adoption that > can stymie new services. Well, RTCWEB is primarily umbrella standardization. Something we rarely do in IETF. This is actually about gluing together some 20-30 or more specifications into a service. Thus I think comparing it with basic HTTP service is not that relevant, which by the way still requires you to read a bit more than 2 specs. Even if I assume you have a working TCP/IP with DNS system to build on, you still need the HTTP, the URI, the MIME spec and likely a few small pieces more before you even can fetch an referenced object. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Jun 17 01:00:59 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0773B11E8096 for ; Fri, 17 Jun 2011 01:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+JRmR0YcYIz for ; Fri, 17 Jun 2011 01:00:58 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3065C11E808A for ; Fri, 17 Jun 2011 01:00:58 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-c0-4dfb09add844 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 67.53.20773.DA90BFD4; Fri, 17 Jun 2011 10:00:46 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Fri, 17 Jun 2011 10:00:44 +0200 Message-ID: <4DFB09AC.1090001@ericsson.com> Date: Fri, 17 Jun 2011 10:00:44 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] WG adoption for Use Case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 08:00:59 -0000 WG, We would like to adopt a WG document with the purpose for describing use cases for the RTCWEB work. This document would be targeted as publication as an Inforamtional RFC eventually. The candidate document for this is: Web Real-Time Communication Use-cases and Requirements https://datatracker.ietf.org/doc/draft-holmberg-rtcweb-ucreqs/ Based on our interim last week it was clear that there are some use cases that clearly needs development. However, the WG chairs believe that future development of the document can be done as WG item. WG participants please indicate if you agree in adopting this document as a basis, or if not, what the short comings you would like to see addressed prior to adoption. Once more, the document will be continued to be developed under the WG control and this is far from any final version. Please provide your view no later than Friday the 24th. Best Regards Magnus Westerlund WG chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From randell1@jesup.org Fri Jun 17 04:32:03 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E610E11E80C7 for ; Fri, 17 Jun 2011 04:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XdtakU2dctj for ; Fri, 17 Jun 2011 04:32:03 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 6184911E808B for ; Fri, 17 Jun 2011 04:32:03 -0700 (PDT) Received: from pool-71-185-223-77.phlapa.fios.verizon.net ([71.185.223.77] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QXXHO-00022e-Ob for rtcweb@ietf.org; Fri, 17 Jun 2011 06:32:02 -0500 Message-ID: <4DFB3AA1.7020004@jesup.org> Date: Fri, 17 Jun 2011 07:29:37 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4DFB09AC.1090001@ericsson.com> In-Reply-To: <4DFB09AC.1090001@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] WG adoption for Use Case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 11:32:04 -0000 On 6/17/2011 4:00 AM, Magnus Westerlund wrote: > WG, > > We would like to adopt a WG document with the purpose for describing use > cases for the RTCWEB work. This document would be targeted as > publication as an Inforamtional RFC eventually. > > The candidate document for this is: > Web Real-Time Communication Use-cases and Requirements > https://datatracker.ietf.org/doc/draft-holmberg-rtcweb-ucreqs/ Agreed From mary.ietf.barnes@gmail.com Fri Jun 17 04:59:31 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BC011E80CB for ; Fri, 17 Jun 2011 04:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGl18FWkIEiE for ; Fri, 17 Jun 2011 04:59:30 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 52AE011E808B for ; Fri, 17 Jun 2011 04:59:30 -0700 (PDT) Received: by vxg33 with SMTP id 33so2368892vxg.31 for ; Fri, 17 Jun 2011 04:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qkDXEhdsCADOB7jHuoxfRi0F7G7b4SmrmKozdBp8yvA=; b=k+Coq+/hrsE1if7CAKR80+0UDo4WOkTmTDKWYWetfYlL1HA405sTU35fP6Pj1jrYvw z+vbUZ0oZhGeXwpQj+P+of8X4TNFEFRlVV+N1Rf78BfcPUkSjQFEQMUlEhblnofudBU7 mlqLS/OZ2KjnU+3ETpFCM3VMnqkJP2nlG/Bt0= 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=jcvXtA9wnmOpdDQ8h6FSTYJBoQTXobuMHZOgG3EIohr3mjaKo6lmHneNjs2ChX+K72 Nh4/0f4Du7mf9qrefoREDDLDUhPipGCftnksAH81D//iHD1AHNkRggs+HFlI7xeO/Fkl 6EBcDdG0pRYtOa92SmpHBwZr+0/3DYbUU987E= MIME-Version: 1.0 Received: by 10.52.159.202 with SMTP id xe10mr2931597vdb.263.1308311969597; Fri, 17 Jun 2011 04:59:29 -0700 (PDT) Received: by 10.52.158.39 with HTTP; Fri, 17 Jun 2011 04:59:29 -0700 (PDT) In-Reply-To: <4DFB09AC.1090001@ericsson.com> References: <4DFB09AC.1090001@ericsson.com> Date: Fri, 17 Jun 2011 06:59:29 -0500 Message-ID: From: Mary Barnes To: Magnus Westerlund Content-Type: multipart/alternative; boundary=bcaec53f8f4f3409ce04a5e71e15 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG adoption for Use Case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 11:59:31 -0000 --bcaec53f8f4f3409ce04a5e71e15 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think the document is a good starting point, although, I personally would prefer that the mapping would should the use cases that were used to derive the requirements versus the requirements that are derived from the use case= . Otherise, you have to search through the use cases to see the one from which the requirement was derived. Or perhaps having the mapping both directions. Also, I would suggest some reformatting so that new use cases can be easily added - i.e., it doesn't look like the list is a result of the ... xml formatting. If that's not the case, I still don't like this dashy list style. Regards, Mary. On Fri, Jun 17, 2011 at 3:00 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > WG, > > We would like to adopt a WG document with the purpose for describing use > cases for the RTCWEB work. This document would be targeted as > publication as an Inforamtional RFC eventually. > > The candidate document for this is: > Web Real-Time Communication Use-cases and Requirements > https://datatracker.ietf.org/doc/draft-holmberg-rtcweb-ucreqs/ > > Based on our interim last week it was clear that there are some use > cases that clearly needs development. However, the WG chairs believe > that future development of the document can be done as WG item. > > WG participants please indicate if you agree in adopting this document > as a basis, or if not, what the short comings you would like to see > addressed prior to adoption. Once more, the document will be continued > to be developed under the WG control and this is far from any final > version. > > Please provide your view no later than Friday the 24th. > > Best Regards > > Magnus Westerlund > WG chair > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec53f8f4f3409ce04a5e71e15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think the document is a good starting point, although, I personally would= prefer that the mapping would should the use cases that were used to deriv= e the requirements versus the requirements that are derived from the use ca= se. =A0Otherise, you have to =A0 search through the use cases to see the on= e from which the requirement was derived. Or perhaps having the mapping bot= h directions. =A0

Also, I would suggest some reformatting so that new use case= s can be easily added - i.e., it doesn't look like the list is a result= of the <list>...</list> xml formatting. If that's not the = case, I still don't like this dashy list style.=A0

Regards,
Mary.=A0

On Fri, Jun 17, 2011 at 3:00 AM, Magnus Westerlund <magnus.westerlund@er= icsson.com> wrote:
WG,

We would like to adopt a WG document with the purpose for describing use cases for the RTCWEB work. This document would be targeted as
publication as an Inforamtional RFC eventually.

The candidate document for this is:
Web Real-Time Communication Use-cases and Requirements
https://datatracker.ietf.org/doc/draft-holmberg-rtcweb-uc= reqs/

Based on our interim last week it was clear that there are some use
cases that clearly needs development. However, the WG chairs believe
that future development of the document can be done as WG item.

WG participants please indicate if you agree in adopting this document
as a basis, or if not, what the short comings you would like to see
addressed prior to adoption. Once more, the document will be continued
to be developed under the WG control and this is far from any final
version.

Please provide your view no later than Friday the 24th.

Best Regards

Magnus Westerlund
WG chair

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

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

--bcaec53f8f4f3409ce04a5e71e15-- From christer.holmberg@ericsson.com Fri Jun 17 05:27:38 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C40A11E8085 for ; Fri, 17 Jun 2011 05:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-U8l8XunaVC for ; Fri, 17 Jun 2011 05:27:37 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id AB1B411E8074 for ; Fri, 17 Jun 2011 05:27:36 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-aa-4dfb4837f265 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 4D.28.09774.7384BFD4; Fri, 17 Jun 2011 14:27:35 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 17 Jun 2011 14:26:16 +0200 From: Christer Holmberg To: Mary Barnes , Magnus Westerlund Date: Fri, 17 Jun 2011 14:26:15 +0200 Thread-Topic: [rtcweb] WG adoption for Use Case document Thread-Index: Acws5hB0BRk0+ms9RRq/nd/rMz2+4QAA4J0Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3E74C5@ESESSCMS0356.eemea.ericsson.se> References: <4DFB09AC.1090001@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG adoption for Use Case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 12:27:38 -0000 Hi Mary, =09 >I think the document is a good starting point, although, I personally woul= d prefer that the mapping would should the use cases that were used to deri= ve the requirements versus the requirements=20 >that are derived from the use case.=20 We can fix that. >Otherise, you have to search through the use cases to see the one from w= hich the requirement was derived. Or perhaps having the mapping both direct= ions. =20 > >Also, I would suggest some reformatting so that new use cases can be easil= y added - i.e., it doesn't look like the list is a result of the ...<= /list> xml formatting. If that's not the=20 >case, I still don't like this dashy list style.=20 We can fix that too. Thanks! Regards, Christer =09 =09 On Fri, Jun 17, 2011 at 3:00 AM, Magnus Westerlund wrote: =09 WG, =09 We would like to adopt a WG document with the purpose for describing use cases for the RTCWEB work. This document would be targeted as publication as an Inforamtional RFC eventually. =09 The candidate document for this is: Web Real-Time Communication Use-cases and Requirements https://datatracker.ietf.org/doc/draft-holmberg-rtcweb-ucreqs/ =09 Based on our interim last week it was clear that there are some use cases that clearly needs development. However, the WG chairs believe that future development of the document can be done as WG item. =09 WG participants please indicate if you agree in adopting this document as a basis, or if not, what the short comings you would like to see addressed prior to adoption. Once more, the document will be continued to be developed under the WG control and this is far from any final version. =09 Please provide your view no later than Friday the 24th. =09 Best Regards =09 Magnus Westerlund WG chair =09 ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- =09 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =09 From anil.srivastava@oracle.com Fri Jun 17 06:33:37 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4F011E8070 for ; Fri, 17 Jun 2011 06:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7POFI45xQcy for ; Fri, 17 Jun 2011 06:33:36 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 86BE411E80E2 for ; Fri, 17 Jun 2011 06:33:36 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p5HDXUk8030451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2011 13:33:32 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5HDXTER002116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jun 2011 13:33:30 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5HDXOaV020442; Fri, 17 Jun 2011 08:33:24 -0500 Received: from [192.168.132.198] (/67.170.216.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 Jun 2011 06:33:24 -0700 References: <4DFB09AC.1090001@ericsson.com> In-Reply-To: <4DFB09AC.1090001@ericsson.com> Mime-Version: 1.0 (iPad Mail 8J2) Content-Type: text/plain; charset=utf-8 Message-Id: <08339F35-9029-4629-897A-6CDC11C0610F@oracle.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8J2) From: Anil SRIVASTAVA Date: Fri, 17 Jun 2011 06:33:15 -0700 To: Magnus Westerlund X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4DFB57AC.0082:SCFMA922111,ss=1,fgs=0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG adoption for Use Case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 13:33:37 -0000 Agreed.=20 Anil On Jun 17, 2011, at 1:00 AM, Magnus Westerlund wrote: > WG, >=20 > We would like to adopt a WG document with the purpose for describing use > cases for the RTCWEB work. This document would be targeted as > publication as an Inforamtional RFC eventually. >=20 > The candidate document for this is: > Web Real-Time Communication Use-cases and Requirements > https://datatracker.ietf.org/doc/draft-holmberg-rtcweb-ucreqs/ >=20 > Based on our interim last week it was clear that there are some use > cases that clearly needs development. However, the WG chairs believe > that future development of the document can be done as WG item. >=20 > WG participants please indicate if you agree in adopting this document > as a basis, or if not, what the short comings you would like to see > addressed prior to adoption. Once more, the document will be continued > to be developed under the WG control and this is far from any final > version. >=20 > Please provide your view no later than Friday the 24th. >=20 > Best Regards >=20 > Magnus Westerlund > WG chair >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Fri Jun 17 10:12:07 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3708F21F84A5 for ; Fri, 17 Jun 2011 10:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t8lUVPwZvzv for ; Fri, 17 Jun 2011 10:12:06 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id A15E521F84A0 for ; Fri, 17 Jun 2011 10:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=811; q=dns/txt; s=iport; t=1308330699; x=1309540299; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=QOOG52Zk9OWrmEEqMA39Fs6nx6kxQphfbY690Fc7mqQ=; b=XkyvlHyjvKo/ZOzbL7GZn3SJyEhVyBVWhr6pvn4l6e0l2wUONBp+86NV HcWf8n1rPfWq6kyzLcj4Ha3Al0xn3Q1fPfj4rrxQcX/co+EV39JQDK37u mpLLbE1AN5+UhcLqLHOmdKvJshdtG4w8Wb1zFAJftNL9egHxHotO5ZfYJ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUIAEOK+02rRDoI/2dsb2JhbABSmAiOSHeIc6B0ng+GJwSHIIo+hF+LPQ X-IronPort-AV: E=Sophos;i="4.65,382,1304294400"; d="scan'208";a="379251776" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 17 Jun 2011 17:11:39 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5HHBcPG026926; Fri, 17 Jun 2011 17:11:38 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4DFAE451.9030105@dcrocker.net> Date: Fri, 17 Jun 2011 11:11:38 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6718BDE0-1C0F-4AF6-BAF4-F67E9A25AE82@cisco.com> References: <4DFAE451.9030105@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for comment on document split X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:12:07 -0000 On Jun 16, 2011, at 11:21 PM, Dave CROCKER wrote: >=20 >=20 > If someone wants to implement the simplest, core capability that is = useful within this context of service, how many docs are they going to = have to read? Just as a random guess, probably around 20 to 50. This is a bit more = complicated that email. There's not consensus on what the set would be = yet but I would guess that in the end we will end up with a list of docs = a browser would need to implement (beyond what they already implement) = that is roughly along the lines of: the docs on RTP, SRTP and various = keying approach, various audio and video codecs, various offer answer = schemes, the whole ICE family of docs including STUN and TURN families, = a bunch of docs on SDP and various offer answer schemes.=20= From fluffy@cisco.com Fri Jun 17 10:13:07 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3455621F84A8 for ; Fri, 17 Jun 2011 10:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWvSGDae0ksR for ; Fri, 17 Jun 2011 10:13:06 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7479321F84A7 for ; Fri, 17 Jun 2011 10:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1179; q=dns/txt; s=iport; t=1308330786; x=1309540386; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ofFIvBmuF80UtjMMQxTB/vECDnPs5woFLHKnGLqF3ow=; b=ccyRTiIuqTZM87cLkG7gFpHIPlfg7/dfUgBEwV2p07QloVSQGI1U5Vqh /XOUvvECcdb3b/Sc+BPQu2Dd2bLueLaefwC+/yiO+0Ltn38IK762QCUKQ Uq+xiNzNGnzKsRxO7ah4TJhe2c5tatpNs2R9dXR9owfZz8t7B98OPsAbC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAH6K+02rRDoJ/2dsb2JhbABSplB3iHOgap4PhicEhyCKPoRfiz0 X-IronPort-AV: E=Sophos;i="4.65,382,1304294400"; d="scan'208";a="715929736" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 17 Jun 2011 17:13:04 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5HHD3rA028756; Fri, 17 Jun 2011 17:13:03 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 17 Jun 2011 11:13:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <72DF99A5-5684-4507-B25A-C83A1AA2F042@cisco.com> References: To: Ted Hardie X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for comment on document split X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:13:07 -0000 On Jun 16, 2011, at 10:30 PM, Ted Hardie wrote: > Hi Folks, >=20 > In order to allow folks time to submit draft-ietf-rtcweb versions in = time for the upcoming 00 deadline, the chairs would like to first = outline our theory of the document splits to meet our chartered = milestones (to refresh you self on them: = http://datatracker.ietf.org/wg/rtcweb/charter/) in the August time = frame. >=20 > We'd like to have one document which describes the use cases. > We'd like to have one document that gives a system overview and = outlines the overall model. > We'd like to have one document that describes the privacy and security = model. > We'd like to have one document that describes the connectivity model = (for NAT traversal etc.). >=20 > Later documents will be: signaling and negotiation methods, media = transports, datagram transport for non-media data, and one or more = documents on media processing and codecs. With my individual contributor hat on ...=20 I don't see the reason to wait for "later" on these other docs. I think = some of them are as ready now as the connectivity model stuff is. Let's = get moving with this stuff. From igor.faynberg@alcatel-lucent.com Fri Jun 17 10:14:28 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB6421F84C3 for ; Fri, 17 Jun 2011 10:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PDzsYKzD0N9 for ; Fri, 17 Jun 2011 10:14:27 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 226E621F84C2 for ; Fri, 17 Jun 2011 10:14:27 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p5HHEMmo008101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Jun 2011 12:14:23 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5HHEMpf005247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 17 Jun 2011 12:14:22 -0500 Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5HHEMSW026612; Fri, 17 Jun 2011 12:14:22 -0500 (CDT) Message-ID: <4DFB8B6E.7010201@alcatel-lucent.com> Date: Fri, 17 Jun 2011 13:14:22 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080905050800000306010108" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [rtcweb] Call for comment on document split X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:14:28 -0000 This is a multi-part message in MIME format. --------------080905050800000306010108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ted, I think the proposed split is well in line with the Internet Architecture principle, "Modularity is always good." It is well thought through. Igor On 6/17/2011 12:30 AM, Ted Hardie wrote: > Hi Folks, > > In order to allow folks time to submit draft-ietf-rtcweb versions in > time for the upcoming 00 deadline, the chairs would like to first > outline our theory of the document splits to meet our chartered > milestones (to refresh you self on them: > http://datatracker.ietf.org/wg/rtcweb/charter/) in the August time frame. > > We'd like to have one document which describes the use cases. > We'd like to have one document that gives a system overview and > outlines the overall model. > We'd like to have one document that describes the privacy and security > model. > We'd like to have one document that describes the connectivity model > (for NAT traversal etc.). > > Later documents will be: signaling and negotiation methods, media > transports, datagram transport for non-media data, and one or more > documents on media processing and codecs. > > Note that this set of "documents we'd like" is missing one that says > "requirements". Discussion among the chairs has come to consensus > that we have at least three different kinds of requirements being > discussed and the the use of the term "requirement" is hindering both > our internal discussion and the balance of work between us and the W3C > at the moment. So, we'd like to have the focus be on what the parts > of the system *do* within the context of a system overview, rather > than on a discussion of requirements or, even worse, a meta discussion > of what the word "requirements" means in particular contexts. > > If folks our okay with this document set, the chairs will then appoint > editors from among those who have contributed text so far. This may > mean that the initial -00 versions have a strong resemblance to the > individual submissions they'd already presented; it also may not. > We'd like to remind everyone that taking on the role of document > editor in an IETF context means accepting the responsibility to make > the document reflect the consensus of the group. If a WG -00 is > missing items or needs revision to meet the needs of the group, in > other words, that's normal--send text. > > Ted, Magnus, and Cullen > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------080905050800000306010108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ted,

I think the proposed split is well in line with the Internet Architecture principle, "Modularity is always good."

It is well thought through.

Igor

On 6/17/2011 12:30 AM, Ted Hardie wrote:
Hi Folks,

In order to allow folks time to submit draft-ietf-rtcweb versions in time for the upcoming 00 deadline, the chairs would like to first outline our theory of the document splits to meet our chartered milestones (to refresh you self on them: http://datatracker.ietf.org/wg/rtcweb/charter/) in the August time frame.

We'd like to have one document which describes the use cases.
We'd like to have one document that gives a system overview and outlines the overall model.
We'd like to have one document that describes the privacy and security model.
We'd like to have one document that  describes the connectivity model (for NAT traversal etc.).

Later documents will be: signaling and negotiation methods, media transports, datagram transport for non-media data, and one or more documents on media processing and codecs.

Note that this set of "documents we'd like" is missing one that says "requirements".  Discussion among the chairs has come to consensus that we have at least three different kinds of requirements being discussed and the the use of the term "requirement" is hindering both our internal discussion and the balance of work between us and the W3C at the moment.  So, we'd like to have the focus be on what the parts of the system *do* within the context of a system overview, rather than on a discussion of requirements or, even worse, a meta discussion of what the word "requirements" means in particular contexts.

If folks our okay with this document set, the chairs will then appoint editors from among those who have contributed text so far.  This may mean that the initial -00 versions have a strong resemblance to the individual submissions they'd already presented; it also may not.  We'd like to remind everyone that taking on the role of document editor in an IETF context means accepting the responsibility to make the document reflect the consensus of the group.  If a WG -00 is missing items or needs revision to meet the needs of the group, in other words, that's normal--send text.

Ted, Magnus, and Cullen

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--------------080905050800000306010108-- From igor.faynberg@alcatel-lucent.com Fri Jun 17 10:24:40 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3479C21F857A for ; Fri, 17 Jun 2011 10:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHlWZb2CJ9gY for ; Fri, 17 Jun 2011 10:24:39 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 596F221F8579 for ; Fri, 17 Jun 2011 10:24:39 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p5HHOb5p016183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Jun 2011 12:24:37 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5HHObuY020766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 17 Jun 2011 12:24:37 -0500 Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5HHOZuU004193; Fri, 17 Jun 2011 12:24:36 -0500 (CDT) Message-ID: <4DFB8DD3.1020002@alcatel-lucent.com> Date: Fri, 17 Jun 2011 13:24:35 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4DFAE451.9030105@dcrocker.net> In-Reply-To: <4DFAE451.9030105@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] Call for comment on document split X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:24:40 -0000 I share the concern, but yet no matter how humble the beginning was (e.g., SIP), things ended up with far too many specifications for anyone to grasp (e.g., ...SIP). don't think we will get away with two specifications no matter what (but I am a registered pessimist).I This is why I think that modularity thought through in the beginning (vs. ad-hoc additions) will ensure order in the future. In addition, with the controlled break-up, we could know in advance whether (and how) change in one document would affect others. It is true though that a short Informational describing the structure of the project and references to other documents would be helpful. Igor On 6/17/2011 1:21 AM, Dave CROCKER wrote: > > > On 6/16/2011 9:30 PM, Ted Hardie wrote: >> We'd like to have one document which describes the use cases. >> We'd like to have one document that gives a system overview and >> outlines the >> overall model. >> We'd like to have one document that describes the privacy and >> security model. >> We'd like to have one document that describes the connectivity model >> (for NAT >> traversal etc.). >> >> Later documents will be: signaling and negotiation methods, media >> transports, >> datagram transport for non-media data, and one or more documents on >> media >> processing and codecs. > > > If someone wants to implement the simplest, core capability that is > useful within this context of service, how many docs are they going to > have to read? > > Which ones? How long before they will be written? > > For classic Web, I think it is still just 2. Same for email. > > My question is motivated by the usual concern about barriers to > adoption that can stymie new services. > > d/ From fluffy@cisco.com Fri Jun 17 11:01:49 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D03711E811D for ; Fri, 17 Jun 2011 11:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA1VXht7gkTy for ; Fri, 17 Jun 2011 11:01:48 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id EE8DF11E8118 for ; Fri, 17 Jun 2011 11:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1066; q=dns/txt; s=iport; t=1308333707; x=1309543307; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=gksDbxwxRsRAPNnfId2cpXtev9HbEcL9cygeHsclzD0=; b=HUw7eojNYDHceR/+dlTSminelsRm4L9y8FK9LfZloj8MPF8wlR8C7afd 1+aQxXnOSWHT7Zxoo1JuGfJePudM4gcqDIsxzZH89mam9U5w3HnTjImA4 FiW9hw9CepN+IL8qx9KzoNbH/NJzb2rIZrZt9hOd8r4xrIurHYjrMRZZD c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAKW+02rRDoG/2dsb2JhbABSplB3iHOgep4HhicEhyCKPoRfiz0 X-IronPort-AV: E=Sophos;i="4.65,382,1304294400"; d="scan'208";a="379307298" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 17 Jun 2011 18:01:47 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5HI1kC8004103; Fri, 17 Jun 2011 18:01:46 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4DF48DA7.6080002@alvestrand.no> Date: Fri, 17 Jun 2011 12:01:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <4DF3DCB8.9090805@alvestrand.no> <4DF454DA.8030300@alvestrand.no> <6DA32DD7-6BB4-445C-B119-292246E24B0A@skype.net> <4DF48DA7.6080002@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) Cc: Bernard Aboba , rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-kaufman-rtcweb-traversal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 18:01:49 -0000 On Jun 12, 2011, at 3:57 AM, Harald Alvestrand wrote: >> The resolution of waking up for a timer on WinNT is 30 msec and only = 15 msec on WinXP and ICE works just fine there. >>=20 >> I am not at all convinced that for our use cases we need anything = better than ~100 msec, so your 50 msec is already twice as good. > The shortest timer in RFC 5245 (as far as I can see) is Ta (section = 16.1), which has a lower bound of 20 msec; however, this is a lower = bound on transmission intervals, so it's possible that an implementation = that fires only every 100 msec would be perfectly interoperable with an = application that fires every 20 msec. >=20 > Testing will show.... One complication is that there is ICE in theory and ICE in practice. = Some of the times in the theory are bit longer than some implementations = use in practice. This theory numbers are larger due to congestion = control concerns at IETF. Some of the practice numbers are a bit lower = to reduce the latency to have the call set up.=20 Testing will tell ... :-) From fluffy@cisco.com Fri Jun 17 11:09:56 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F8A9E800B for ; Fri, 17 Jun 2011 11:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEoOqpnIzvWN for ; Fri, 17 Jun 2011 11:09:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 986D99E8004 for ; Fri, 17 Jun 2011 11:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1619; q=dns/txt; s=iport; t=1308334192; x=1309543792; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=9tgWTjCUlpADgE6FigXKRsQvYVBUerPzhmWSeujeKOo=; b=YedKCqegwEM9jR7T3WRH51ZXLyXkyGcL42r2aljgyOX5OzAWKLdovVAm YR++hGS02AkAcji4Jml+v2YR+rfhvliwhs3VKBsOKgB1xZtK4uskC3Emd 9ol4jdcLiUAeKBspj8A/47D4Rm0mRpMlUlVY/RJfIJu9+YZwWTUhH7FPl 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUIAGuX+02rRDoG/2dsb2JhbABSmAiOSHepfJ4BhicEhyCKPoRfiz0 X-IronPort-AV: E=Sophos;i="4.65,382,1304294400"; d="scan'208";a="715991091" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 17 Jun 2011 18:09:51 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5HI9kQM021341; Fri, 17 Jun 2011 18:09:47 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Jun 2011 12:09:45 -0600 Message-Id: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] use case: X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 18:09:57 -0000 If people agree with the following use cases, I was hoping they might = get added to draft-holmberg-rtcweb-ucreqs. Video Size Change. Alice and Bob are in a video call in their browsers and have negotiate a = high resolution video. Bob decides to change the size of the windows his = browser is displaying video to a small size. Bob's browser should be = able to regenerate the video codec parameters with Alice's browser to = change the resolution of video Alice sends to match the smaller size.=20 Call Fedex Alice uses her web browser with a service something like Skype to be = able to phone PSTN numbers. Alice calls 1-800-gofedex. Alice should be = able to hear the initial prompts from the fedex IVR and when the IVR = says press 1, there should be a way for Alice to navigate the IVR.=20 NIC Change Alice is on her notebook computer that is plugged in to 1G ethernet and = has 802.11 wireless interface. Alice is in a call talking with Bob and = decides to unplug here notebook computer and walk down to a different = room. The call should continue as Alice unplugs from the fat network = interface and moves to a slower one. The media codecs may end up = renegotiating to select a different bandwidth consumption on the = wireless network.=20 QoS Marking=20 Alice's browser is on a computer behind a common residential router that = supports prioritization of traffic . The browser should be able to take = advantage of the capabilities of the router to prioritize voice and = video appropriately.=20 Cullen From richard@shockey.us Fri Jun 17 11:17:02 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9919E8004 for ; Fri, 17 Jun 2011 11:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.729 X-Spam-Level: X-Spam-Status: No, score=-101.729 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GbaBhU4ubhK for ; Fri, 17 Jun 2011 11:17:02 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id D94F59E8029 for ; Fri, 17 Jun 2011 11:17:01 -0700 (PDT) Received: (qmail 24129 invoked by uid 0); 17 Jun 2011 18:17:01 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy1.bluehost.com with SMTP; 17 Jun 2011 18:17:01 -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:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=OWWTj6anQ7wvNP/+nOrV6x3CvELDnU8Hxpf5oDe5eznJKpc0nKzD3OxQjagTSt0urrb2jra+C+AtJtW2xLnGSy7IwKu52SetYkewoNuHspXqvkID7XewbzEvSTr1tA7F; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1QXdbI-0002QM-T0 for rtcweb@ietf.org; Fri, 17 Jun 2011 12:17:01 -0600 From: "Richard Shockey" To: References: <4DF9F8A1.1040503@alvestrand.no> <4DFA2D5C.3090708@alvestrand.no> In-Reply-To: <4DFA2D5C.3090708@alvestrand.no> Date: Fri, 17 Jun 2011 14:17:00 -0400 Message-ID: <003201cc2d1a$c11f37f0$435da7d0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01CC2CF9.3A0D97F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwsQVu10SROk2sKQM6ODpbxC6IpbwA2HlLg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Subject: Re: [rtcweb] Use case addition: Interoperable calling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 18:17:02 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0033_01CC2CF9.3A0D97F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Jun 16, 2011 at 2:35 PM, Harald Alvestrand wrote: Each web service publishes information about user login status for users that have a relationship with the other user; how this is established is out of scope. I am not sure if I am understanding this part correctly. To me it sounds like some sort of presence exchanged between users and, if so, I was wondering if it was really necessary for inter-operator communication. I don't know - all chat networks and web-based calling networks use network presence pretty heavily; the phone network's able to live without it, assuming that "everyone's there all the time". Mobile networks have their own presence. HLR/VLR or HSS in IMS terms. The only reason for mentioning it here is that it's out of our scope to standardize it - if we don't mention it, some people might believe it's in scope, others that it's out of scope. So if this is out of scope and its seems it is , then this entire WEB-RTC exercise seems to perpetuate the kind of silos we seen in Instant Messaging and other forms of RTC. Pardon me for sounding overly cynical.. ------=_NextPart_000_0033_01CC2CF9.3A0D97F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

On Thu, Jun 16, 2011 at 2:35 PM, Harald Alvestrand = <harald@alvestrand.no> = wrote:


Each web service publishes = information about user login status for users that have a relationship = with the other user; how this is established is out of = scope.


I am not sure if I am = understanding this part correctly. To me it sounds like some sort of = presence exchanged between users and, if so, I was wondering if it was = really necessary for inter-operator = communication.

I don't know - all chat networks and = web-based calling networks use network presence pretty heavily; the = phone network's able to live without it, assuming that "everyone's = there all the time".

Mobile networks have their own presence.  HLR/VLR or HSS in IMS = terms.


The only reason for mentioning it = here is that it's out of our scope to standardize it - if we don't = mention it, some people might believe it's in scope, others that it's = out of scope.

So if this is out of scope and its seems it is , then this entire = WEB-RTC exercise seems to perpetuate the kind of silos we seen in = Instant Messaging and other forms of RTC.

Pardon me for sounding overly cynical..

 



------=_NextPart_000_0033_01CC2CF9.3A0D97F0-- From randell1@jesup.org Fri Jun 17 11:52:23 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E4D9E8026 for ; Fri, 17 Jun 2011 11:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSqtHmU-qmGX for ; Fri, 17 Jun 2011 11:52:23 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD3D9E800A for ; Fri, 17 Jun 2011 11:52:22 -0700 (PDT) Received: from pool-71-185-223-77.phlapa.fios.verizon.net ([71.185.223.77] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QXe9W-0000L9-EP for rtcweb@ietf.org; Fri, 17 Jun 2011 13:52:22 -0500 Message-ID: <4DFBA1D4.5060606@jesup.org> Date: Fri, 17 Jun 2011 14:49:56 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4DF9F8A1.1040503@alvestrand.no> <4DFA2D5C.3090708@alvestrand.no> In-Reply-To: <4DFA2D5C.3090708@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Use case addition: Interoperable calling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 18:52:23 -0000 On 6/16/2011 12:20 PM, Harald Alvestrand wrote: > On 06/16/11 17:40, Emil Ivov wrote: >> On Thu, Jun 16, 2011 at 2:35 PM, Harald Alvestrand >> > wrote: >> >> >> Each web service publishes information about user login status >> for users that have a relationship with the other user; how this >> is established is out of scope. >> I don't even think that's necessary - the user could indicate he wants to talk to Joe_OHara@facebook.com, without having to know if Joe is currently on and registered with Facebook or not. Also, a web service may implement the equivalent to network answering machines (forward to voice/videomail on not registered or no answer, or forward to another user, etc). >> >> I am not sure if I am understanding this part correctly. To me it >> sounds like some sort of presence exchanged between users and, if so, >> I was wondering if it was really necessary for inter-operator >> communication. > I don't know - all chat networks and web-based calling networks use > network presence pretty heavily; the phone network's able to live > without it, assuming that "everyone's there all the time". Well, the PSTN network doesn't really assume that. It knows where a number will get routed (which provider), but the device in question may not be reachable (especially for cellphones and VoIP phones). > The only reason for mentioning it here is that it's out of our scope > to standardize it - if we don't mention it, some people might believe > it's in scope, others that it's out of scope. Sure. -- Randell Jesup randell-ietf@jesup.org From arosenberg@logitech.com Fri Jun 17 12:38:34 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968B39E8038 for ; Fri, 17 Jun 2011 12:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n5ax8NB3ldq for ; Fri, 17 Jun 2011 12:38:34 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by ietfa.amsl.com (Postfix) with SMTP id 8A10F9E800A for ; Fri, 17 Jun 2011 12:38:33 -0700 (PDT) Received: from mail-wy0-f171.google.com ([74.125.82.171]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTfutOKEWOFAQRYJPdsla7IdsmstWs/uX@postini.com; Fri, 17 Jun 2011 12:38:33 PDT Received: by mail-wy0-f171.google.com with SMTP id 11so896717wyi.30 for ; Fri, 17 Jun 2011 12:38:32 -0700 (PDT) Received: by 10.216.254.37 with SMTP id g37mr2432003wes.36.1308339512072; Fri, 17 Jun 2011 12:38:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.235.198 with HTTP; Fri, 17 Jun 2011 12:38:12 -0700 (PDT) In-Reply-To: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> References: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> From: Aron Rosenberg Date: Fri, 17 Jun 2011 12:38:12 -0700 Message-ID: To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=0015174ff1f4dcda1f04a5ed8743 Subject: Re: [rtcweb] use case: X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 19:38:34 -0000 --0015174ff1f4dcda1f04a5ed8743 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings wrote: > > Video Size Change. > > Alice and Bob are in a video call in their browsers and have negotiate a > high resolution video. Bob decides to change the size of the windows his > browser is displaying video to a small size. Bob's browser should be able > to regenerate the video codec parameters with Alice's browser to change the > resolution of video Alice sends to match the smaller size. > > > Changing compression due to a user change in window size is usually not done since it has a bad long term effect on video quality. In almost all the major video calling systems, video resolution is a function of current bandwidth (which changes as the rate control system detects differences) and/or constrained by the physical device, but not a function of a user dragging the window size. At an equivalent bitrate, it is better to compress a larger resolution and display it smaller (higher PSNR), then compress a smaller resolution if you are within the codec's effective bitrate for that larger resolution. Aron Rosenberg LifeSize, A Division of Logitech --0015174ff1f4dcda1f04a5ed8743 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jenning= s <fluffy@cisco.co= m> wrote:

Video Size Change.

Alice and Bob are in a video call in their browsers and have negotiate a hi= gh resolution video. Bob decides to change the size of the windows his brow= ser is displaying video to a small size. =A0Bob's browser should be abl= e to regenerate the video codec parameters with Alice's browser to chan= ge the resolution of video Alice sends to match the smaller size.


Changing compression due to a user change in window s= ize is usually not done since it has a bad long term effect on video qualit= y. In almost all the major video calling systems, video resolution is a fun= ction of current bandwidth (which changes as the rate control system detect= s differences) and/or constrained by the physical device, but not a functio= n of a user dragging the window size. At an=A0equivalent=A0bitrate, it is b= etter to compress a larger resolution and display it smaller (higher PSNR),= then compress a smaller resolution if you are within the codec's effec= tive bitrate for that larger resolution.

Aron Rosenberg
LifeSize, A Division of Logite= ch

--0015174ff1f4dcda1f04a5ed8743-- From kundansingh_99@yahoo.com Fri Jun 17 12:47:51 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4579E8042 for ; Fri, 17 Jun 2011 12:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQSDIVurU8Ys for ; Fri, 17 Jun 2011 12:47:51 -0700 (PDT) Received: from nm26-vm0.bullet.mail.bf1.yahoo.com (nm26-vm0.bullet.mail.bf1.yahoo.com [98.139.213.74]) by ietfa.amsl.com (Postfix) with SMTP id ECB289E800A for ; Fri, 17 Jun 2011 12:47:50 -0700 (PDT) Received: from [98.139.212.153] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 17 Jun 2011 19:47:47 -0000 Received: from [98.139.212.220] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 17 Jun 2011 19:47:47 -0000 Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP; 17 Jun 2011 19:47:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 594823.53255.bm@omp1029.mail.bf1.yahoo.com Received: (qmail 57098 invoked by uid 60001); 17 Jun 2011 19:47:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1308340067; bh=QCO57+b+PPczPG8IKMWE3YB/aOu/1byGIvZfvhewoiM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QaCZT69iSxLk44FX3sqw16EZsrsZbd4tNnpOcUU6/Jk3QLBTwJK8llKOd4HSKeiNz0Udwp9KUCUxNOYYkDKerDvlKQFYv3A0TRMHm4unguBtXmzHGL2zVoff9nPMMxT7HqYUkpEHmU5TnpLsdAzIVpwOToaupW37/G2dhIpv9GQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ahiJ3i35PtuSia3A63jzyRzvRI07SxwHOxQ9t8CKUU4906mAgV1zgn7f7Fs6ooEcYGDoBVs5KDjkdkeHA+DhLMHzRfVfhIdM5TIOxIwHWYnKb8qwzVa7Ke6gNy3MCJdtuIyIX2P7TVsMSZX6vNcwijLYpjgER8PSLWmb+nOtZE4=; Message-ID: <378723.50304.qm@web161311.mail.bf1.yahoo.com> X-YMail-OSG: 4sAkmfMVM1lZ_HNodoAxNHo_36PEGvd2SmLMgEqGM.hpqkp _0Mjktu.sUvh8CSRvt7d3O9VP8kh.yFn9utmvhGYeTWC3iK4pcIhopvFVsBx vn1UZtozK.AYZ7buOPpY87SyD0VOdKiU1cQvWaW_Qyr15Ge1c2XsdYMc0ux1 PsPeQz074WnCcwCy3KxJ8RKu1ZZIvSxtXWcYxv6udQl0EMHZLTEZmzzX_99b wB8PKXZ9xBgrUxOCAQO950ozZfNVLYXAGgyCFHwDdxHl9Nxj9gaZU2A5g3qI myFUgVJMKdxMV3AdCVp7Q35VfKyF_MD.pGhHmAy.FMjqarTk6Lc0E52KrLz2 _CDZF86Etv5J0wHyaf0fS4BcPgVknG510BhHca8.oCSwIUPOCwtTQfA-- Received: from [98.207.78.212] by web161311.mail.bf1.yahoo.com via HTTP; Fri, 17 Jun 2011 12:47:47 PDT X-Mailer: YahooMailWebService/0.8.111.304355 References: <4DFAE451.9030105@dcrocker.net> <4DFB8DD3.1020002@alcatel-lucent.com> Date: Fri, 17 Jun 2011 12:47:47 -0700 (PDT) From: Kundan Singh To: "rtcweb@ietf.org" In-Reply-To: <4DFB8DD3.1020002@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [rtcweb] Call for comment on document split X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Kundan Singh List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 19:47:52 -0000 =0A=0AFrom a software developer's point of view, I feel the following will = be most productive:=0A=0A1. One or two complete document that are necessary= and sufficient to implement RTC-Web/WebRTC.=A0=0AEverything else that is n= ot covered by this document must be an existing popular standard with exist= ing popular libraries/APIs.=0A=0A=0A2. Create the documents based on actual= implementation, rather than the reverse. =0A=0APerhaps include pseudo-code= in Internet drafts to avoid ambiguity.=0A=0AIf interaction with external s= tandards are needed, pseudo-code could show how it is done based on interfa= ces of existing popular libraries/APIs for that external standard.=0A=0AHav= ing to read and implement many documents to do one thing=A0 is a recipe for= disaster, e.g., (non) interoperability matrix, frustration, ...=0A=0AIf we= manage to create tens of documents that cover all corner cases, all featur= es, all authors, all existing extensions, but scare away actual developers,= then we haven't learned from our mistakes...=0A=0AJust a thought.=0A=0A--= =0AKundan Singh=0A=0A=0A=0A----- Original Message -----=0A> From: Igor Fayn= berg =0A> To: rtcweb@ietf.org=0A> Cc: =0A= > Sent: Friday, June 17, 2011 10:24 AM=0A> Subject: Re: [rtcweb] Call for c= omment on document split=0A> =0A> I share the concern, but yet no matter ho= w humble the beginning was (e.g., SIP), =0A> things ended up with far too m= any specifications for anyone to grasp (e.g., =0A> ...SIP).=A0 don't think = we will get away with two specifications no matter =0A> what (but I am a re= gistered pessimist).I=0A> =0A> This is why I think that modularity thought = through in the beginning (vs. ad-hoc =0A> additions) will ensure order in t= he future.=A0 In addition, with the controlled =0A> break-up, we could know= in advance whether (and how) change in one document =0A> would affect othe= rs.=0A> =0A> It is true though that a short Informational describing the st= ructure of the =0A> project and references to other documents would be help= ful.=0A> =0A> Igor=0A> =0A> On 6/17/2011 1:21 AM, Dave CROCKER wrote:=0A>> = =0A>> =0A>> On 6/16/2011 9:30 PM, Ted Hardie wrote:=0A>>> We'd like to ha= ve one document which describes the use cases.=0A>>> We'd like to have one= document that gives a system overview and =0A> outlines the=0A>>> overall= model.=0A>>> We'd like to have one document that describes the privacy an= d =0A> security model.=0A>>> We'd like to have one document that=A0 descri= bes the connectivity =0A> model (for NAT=0A>>> traversal etc.).=0A>>> =0A>= >> Later documents will be: signaling and negotiation methods, media =0A> = transports,=0A>>> datagram transport for non-media data, and one or more d= ocuments on =0A> media=0A>>> processing and codecs.=0A>> =0A>> =0A>> If s= omeone wants to implement the simplest, core capability that is useful =0A>= within this context of service, how many docs are they going to have to re= ad?=0A>> =0A>> Which ones? How long before they will be written?=0A>> =0A>= > For classic Web, I think it is still just 2.=A0 Same for email.=0A>> =0A= >> My question is motivated by the usual concern about barriers to adoptio= n =0A> that can stymie new services.=0A>> =0A>> d/=0A> ___________________= ____________________________=0A> rtcweb mailing list=0A> rtcweb@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A> From petithug@acm.org Fri Jun 17 13:11:53 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC889E8068 for ; Fri, 17 Jun 2011 13:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8vOyROswgtQ for ; Fri, 17 Jun 2011 13:11:52 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id AF8779E8065 for ; Fri, 17 Jun 2011 13:11:51 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 7487F2218B; Fri, 17 Jun 2011 22:10:21 +0200 (CEST) Message-ID: <4DFBB500.3020907@acm.org> Date: Fri, 17 Jun 2011 13:11:44 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110606 Iceowl/1.0b2 Icedove/3.1.10 MIME-Version: 1.0 To: Kundan Singh References: <4DFAE451.9030105@dcrocker.net> <4DFB8DD3.1020002@alcatel-lucent.com> <378723.50304.qm@web161311.mail.bf1.yahoo.com> In-Reply-To: <378723.50304.qm@web161311.mail.bf1.yahoo.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for comment on document split X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 20:11:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As a software developer myself, I believe that this approach is wrong. The goal of the IETF is to make the Internet work better, not to make the developers life better. Implementers should contribute running code to help the IETF make the Internet work better, by having multiple implementations of the same protocol and find any interoperability, security and extensibility issue as soon as possible. Documenting one implementation as protocol creates monoculture, and everybody should know better by now than encouraging this. And BTW, I do not think that "scaring away" developers is a bad thing. On 06/17/2011 12:47 PM, Kundan Singh wrote: > > >>From a software developer's point of view, I feel the following will be most productive: > > 1. One or two complete document that are necessary and sufficient to implement RTC-Web/WebRTC. > Everything else that is not covered by this document must be an existing popular standard with existing popular libraries/APIs. > > > 2. Create the documents based on actual implementation, rather than the reverse. > > Perhaps include pseudo-code in Internet drafts to avoid ambiguity. > > If interaction with external standards are needed, pseudo-code could show how it is done based on interfaces of existing popular libraries/APIs for that external standard. > > Having to read and implement many documents to do one thing is a recipe for disaster, e.g., (non) interoperability matrix, frustration, ... > > If we manage to create tens of documents that cover all corner cases, all features, all authors, all existing extensions, but scare away actual developers, then we haven't learned from our mistakes... > > Just a thought. > > -- > Kundan Singh > > > > ----- Original Message ----- >> From: Igor Faynberg >> To: rtcweb@ietf.org >> Cc: >> Sent: Friday, June 17, 2011 10:24 AM >> Subject: Re: [rtcweb] Call for comment on document split >> >> I share the concern, but yet no matter how humble the beginning was (e.g., SIP), >> things ended up with far too many specifications for anyone to grasp (e.g., >> ...SIP). don't think we will get away with two specifications no matter >> what (but I am a registered pessimist).I >> >> This is why I think that modularity thought through in the beginning (vs. ad-hoc >> additions) will ensure order in the future. In addition, with the controlled >> break-up, we could know in advance whether (and how) change in one document >> would affect others. >> >> It is true though that a short Informational describing the structure of the >> project and references to other documents would be helpful. >> >> Igor >> >> On 6/17/2011 1:21 AM, Dave CROCKER wrote: >>> >>> >>> On 6/16/2011 9:30 PM, Ted Hardie wrote: >>>> We'd like to have one document which describes the use cases. >>>> We'd like to have one document that gives a system overview and >> outlines the >>>> overall model. >>>> We'd like to have one document that describes the privacy and >> security model. >>>> We'd like to have one document that describes the connectivity >> model (for NAT >>>> traversal etc.). >>>> >>>> Later documents will be: signaling and negotiation methods, media >> transports, >>>> datagram transport for non-media data, and one or more documents on >> media >>>> processing and codecs. >>> >>> >>> If someone wants to implement the simplest, core capability that is useful >> within this context of service, how many docs are they going to have to read? >>> >>> Which ones? How long before they will be written? >>> >>> For classic Web, I think it is still just 2. Same for email. >>> >>> My question is motivated by the usual concern about barriers to adoption >> that can stymie new services. >>> >>> d/ >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk37tP8ACgkQ9RoMZyVa61cgwgCeNPkF5g0Q99L6DTlKawxUv8s3 1vYAn1sUE+Q+LSX5JbHAMfU0jMi0hIO3 =snqx -----END PGP SIGNATURE----- From harald@alvestrand.no Mon Jun 20 01:20:52 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA63B11E8076 for ; Mon, 20 Jun 2011 01:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukWSOePUf6Le for ; Mon, 20 Jun 2011 01:20:52 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2CC11E807C for ; Mon, 20 Jun 2011 01:20:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3DEB339E123 for ; Mon, 20 Jun 2011 10:19:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fi8NINlEtT18 for ; Mon, 20 Jun 2011 10:19:51 +0200 (CEST) Received: from [192.168.1.53] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 6DF0B39E03C for ; Mon, 20 Jun 2011 10:19:51 +0200 (CEST) Message-ID: <4DFF02E3.20407@alvestrand.no> Date: Mon, 20 Jun 2011 10:20:51 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4DFB09AC.1090001@ericsson.com> In-Reply-To: <4DFB09AC.1090001@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] WG adoption for Use Case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 08:20:52 -0000 I agree with adopting the document as a WG starting point. Naturally, I expect multiple use cases to be added (and perhaps even some use cases marked up with "RTCWEB can't do this") before we're finished. Harald On 06/17/11 10:00, Magnus Westerlund wrote: > WG, > > We would like to adopt a WG document with the purpose for describing use > cases for the RTCWEB work. This document would be targeted as > publication as an Inforamtional RFC eventually. > > The candidate document for this is: > Web Real-Time Communication Use-cases and Requirements > https://datatracker.ietf.org/doc/draft-holmberg-rtcweb-ucreqs/ > > Based on our interim last week it was clear that there are some use > cases that clearly needs development. However, the WG chairs believe > that future development of the document can be done as WG item. > > WG participants please indicate if you agree in adopting this document > as a basis, or if not, what the short comings you would like to see > addressed prior to adoption. Once more, the document will be continued > to be developed under the WG control and this is far from any final > version. > > Please provide your view no later than Friday the 24th. > > Best Regards > > Magnus Westerlund > WG chair > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From harald@alvestrand.no Mon Jun 20 01:30:35 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7867C11E807C for ; Mon, 20 Jun 2011 01:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPCM0uzWK7on for ; Mon, 20 Jun 2011 01:30:34 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8B39E11E8076 for ; Mon, 20 Jun 2011 01:30:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A405839E123; Mon, 20 Jun 2011 10:29:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNhA-JMboHfg; Mon, 20 Jun 2011 10:29:34 +0200 (CEST) Received: from [192.168.1.53] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 7895839E03C; Mon, 20 Jun 2011 10:29:34 +0200 (CEST) Message-ID: <4DFF052A.8020202@alvestrand.no> Date: Mon, 20 Jun 2011 10:30:34 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Aron Rosenberg References: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080402000208040607040408" Cc: rtcweb@ietf.org Subject: [rtcweb] Changing video size (Re: use case:) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 08:30:35 -0000 This is a multi-part message in MIME format. --------------080402000208040607040408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/17/11 21:38, Aron Rosenberg wrote: > On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings > wrote: > > > Video Size Change. > > Alice and Bob are in a video call in their browsers and have > negotiate a high resolution video. Bob decides to change the size > of the windows his browser is displaying video to a small size. > Bob's browser should be able to regenerate the video codec > parameters with Alice's browser to change the resolution of video > Alice sends to match the smaller size. > > > Changing compression due to a user change in window size is usually > not done since it has a bad long term effect on video quality. In > almost all the major video calling systems, video resolution is a > function of current bandwidth (which changes as the rate control > system detects differences) and/or constrained by the physical device, > but not a function of a user dragging the window size. At > an equivalent bitrate, it is better to compress a larger resolution > and display it smaller (higher PSNR), then compress a smaller > resolution if you are within the codec's effective bitrate for that > larger resolution. Interesting info, but I don't know if it's true in all cases. If the overall constraint on a conferencing system is bandwidth, the system might find the saving in average bandwidth saving of encoding from a base image of 140x200 for "small" windows rather than "HD" (720x1024?) worth considering, even though the sending of a complete I-frame to reinitialize the video stream might take some effort. I like having the use case of "change recipient video window size, and as a result change sender bandwidth usage"; we might argue about the exact phrasing of the use case. Harald --------------080402000208040607040408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/17/11 21:38, Aron Rosenberg wrote:
On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings <fluffy@cisco.com> wrote:

Video Size Change.

Alice and Bob are in a video call in their browsers and have negotiate a high resolution video. Bob decides to change the size of the windows his browser is displaying video to a small size.  Bob's browser should be able to regenerate the video codec parameters with Alice's browser to change the resolution of video Alice sends to match the smaller size.


Changing compression due to a user change in window size is usually not done since it has a bad long term effect on video quality. In almost all the major video calling systems, video resolution is a function of current bandwidth (which changes as the rate control system detects differences) and/or constrained by the physical device, but not a function of a user dragging the window size. At an equivalent bitrate, it is better to compress a larger resolution and display it smaller (higher PSNR), then compress a smaller resolution if you are within the codec's effective bitrate for that larger resolution.
Interesting info, but I don't know if it's true in all cases.

If the overall constraint on a conferencing system is bandwidth, the system might find the saving in average bandwidth saving of encoding from a base image of 140x200 for "small" windows rather than "HD" (720x1024?) worth considering, even though the sending of a complete I-frame to reinitialize the video stream might take some effort.

I like having the use case of "change recipient video window size, and as a result change sender bandwidth usage"; we might argue about the exact phrasing of the use case.

                   Harald




--------------080402000208040607040408-- From salvatore.loreto@ericsson.com Mon Jun 20 01:30:46 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2835711E8076 for ; Mon, 20 Jun 2011 01:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZOjX2xL-9bg for ; Mon, 20 Jun 2011 01:30:45 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5906811E80D6 for ; Mon, 20 Jun 2011 01:30:45 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e5-4dff0534e538 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0C.E1.20773.4350FFD4; Mon, 20 Jun 2011 10:30:44 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Mon, 20 Jun 2011 10:30:43 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5939B24D8 for ; Mon, 20 Jun 2011 11:30:43 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1FEEF5082C for ; Mon, 20 Jun 2011 11:30:43 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C774450405 for ; Mon, 20 Jun 2011 11:30:42 +0300 (EEST) Message-ID: <4DFF0532.8090903@ericsson.com> Date: Mon, 20 Jun 2011 11:30:42 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4DFB09AC.1090001@ericsson.com> <4DFF02E3.20407@alvestrand.no> In-Reply-To: <4DFF02E3.20407@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] WG adoption for Use Case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 08:30:46 -0000 +1 On 6/20/11 11:20 AM, Harald Alvestrand wrote: > I agree with adopting the document as a WG starting point. > > Naturally, I expect multiple use cases to be added (and perhaps even > some use cases marked up with "RTCWEB can't do this") before we're finished. > > Harald > > > On 06/17/11 10:00, Magnus Westerlund wrote: >> WG, >> >> We would like to adopt a WG document with the purpose for describing use >> cases for the RTCWEB work. This document would be targeted as >> publication as an Inforamtional RFC eventually. >> >> The candidate document for this is: >> Web Real-Time Communication Use-cases and Requirements >> https://datatracker.ietf.org/doc/draft-holmberg-rtcweb-ucreqs/ >> >> Based on our interim last week it was clear that there are some use >> cases that clearly needs development. However, the WG chairs believe >> that future development of the document can be done as WG item. >> >> WG participants please indicate if you agree in adopting this document >> as a basis, or if not, what the short comings you would like to see >> addressed prior to adoption. Once more, the document will be continued >> to be developed under the WG control and this is far from any final >> version. >> >> Please provide your view no later than Friday the 24th. >> >> Best Regards >> >> Magnus Westerlund >> WG chair >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stewe@stewe.org Mon Jun 20 06:52:56 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C312711E80A6 for ; Mon, 20 Jun 2011 06:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD1oANL0UpbA for ; Mon, 20 Jun 2011 06:52:54 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 783F311E808A for ; Mon, 20 Jun 2011 06:52:53 -0700 (PDT) Received: from [172.16.7.218] (unverified [160.79.219.114]) by stewe.org (SurgeMail 3.9e) with ESMTP id 3841-1743317 for multiple; Mon, 20 Jun 2011 15:52:52 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Mon, 20 Jun 2011 06:52:44 -0700 From: Stephan Wenger To: Harald Alvestrand , Aron Rosenberg Message-ID: Thread-Topic: [rtcweb] Changing video size (Re: use case:) In-Reply-To: <4DFF052A.8020202@alvestrand.no> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3391397569_1056160" X-Originating-IP: 160.79.219.114 X-Authenticated-User: stewe@stewe.org Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Changing video size (Re: use case:) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 13:52:56 -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_3391397569_1056160 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Applications requiring (or making desirable) adequate response of the video codec to changes of rendering window sizes are a perfect scenario for the use of spatial scalability. One avoids the waste of sending bits for a high resolution picture that cannot be rendered at high resolution, but has freedom to start sending high resolution, without the delay involved in sending an I frame, at any time. Scalable video is also a useful tool to combat losses and to adapt seamlessly to changes in the channel bandwidth (to combat congestion, for example). Stephan From: Harald Alvestrand Date: Mon, 20 Jun 2011 10:30:34 +0200 To: Aron Rosenberg Cc: Subject: [rtcweb] Changing video size (Re: use case:) On 06/17/11 21:38, Aron Rosenberg wrote: > > On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings wrote: > >> >> Video Size Change. >> >> Alice and Bob are in a video call in their browsers and have negotiate a >> high resolution video. Bob decides to change the size of the windows his >> browser is displaying video to a small size. Bob's browser should be able to >> regenerate the video codec parameters with Alice's browser to change the >> resolution of video Alice sends to match the smaller size. >> >> >> > > Changing compression due to a user change in window size is usually not done > since it has a bad long term effect on video quality. In almost all the major > video calling systems, video resolution is a function of current bandwidth > (which changes as the rate control system detects differences) and/or > constrained by the physical device, but not a function of a user dragging the > window size. At an equivalent bitrate, it is better to compress a larger > resolution and display it smaller (higher PSNR), then compress a smaller > resolution if you are within the codec's effective bitrate for that larger > resolution. > > > Interesting info, but I don't know if it's true in all cases. If the overall constraint on a conferencing system is bandwidth, the system might find the saving in average bandwidth saving of encoding from a base image of 140x200 for "small" windows rather than "HD" (720x1024?) worth considering, even though the sending of a complete I-frame to reinitialize the video stream might take some effort. I like having the use case of "change recipient video window size, and as a result change sender bandwidth usage"; we might argue about the exact phrasing of the use case. Harald _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --B_3391397569_1056160 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Applications requiring (or m= aking desirable) adequate response of the video codec to changes of renderin= g window sizes are a perfect scenario for the use of spatial scalability. &n= bsp;One avoids the waste of sending bits for a high resolution picture that = cannot be rendered at high resolution, but has freedom to start sending high= resolution, without the delay involved in sending an I frame, at any time. =  

Scalable video is also a useful tool to comb= at losses and to adapt seamlessly to changes in the channel bandwidth (to co= mbat congestion, for example).

Stephan
&n= bsp; 

From: Har= ald Alvestrand <harald@alvestrand.n= o>
Date: Mon, 20 Jun 2011 1= 0:30:34 +0200
To: Aron Rosenberg &= lt;arosenberg@logitech.com><= br>Cc: <rtcweb@ietf.org>
Subject: [rtcweb] Changing video size (Re: use case:)

=
On 06/17/11 21:38, Aron Rosenberg wrote:
On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings <fluffy@cisco.com> wrote:

Video Size Change.

Alice and Bob are in a video call in their browsers and have negotiate a high resolution video. Bob decides to change the size of the windows his browser is displaying video to a small size.  Bob's browser should be able to regenerate the video codec parameters with Alice's browser to change the resolution of video Alice sends to match the smaller size.


Changing compression due to a user change in window size is usually not done since it has a bad long term effect on video quality. In almost all the major video calling systems, video resolution is a function of current bandwidth (which changes as the rate control system detects differences) and/or constrained by the physical device, but not a function of a user dragging the window size. At an equivalent bitrate= , it is better to compress a larger resolution and display it smaller (higher PSNR), then compress a smaller resolution if you are within the codec's effective bitrate for that larger resolution.
Interesting info, but I don't know if it's true in all cases.

If the overall constraint on a conferencing system is bandwidth, the system might find the saving in average bandwidth saving of encoding from a base image of 140x200 for "small" windows rather than "HD" (720x1024?) worth considering, even though the sending of a complete I-frame to reinitialize the video stream might take some effort.

I like having the use case of "change recipient video window size, and as a result change sender bandwidth usage"; we might argue about the exact phrasing of the use case.

            = ;       Harald




_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org= /mailman/listinfo/rtcweb --B_3391397569_1056160-- From randell1@jesup.org Mon Jun 20 07:13:59 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412A011E8199 for ; Mon, 20 Jun 2011 07:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XaSL0qCmH2B for ; Mon, 20 Jun 2011 07:13:58 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 50D8011E80BE for ; Mon, 20 Jun 2011 07:13:58 -0700 (PDT) Received: from pool-71-185-223-77.phlapa.fios.verizon.net ([71.185.223.77] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QYfEj-0000y4-Eg for rtcweb@ietf.org; Mon, 20 Jun 2011 09:13:57 -0500 Message-ID: <4DFF550C.2000009@jesup.org> Date: Mon, 20 Jun 2011 10:11:24 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> <4DFF052A.8020202@alvestrand.no> In-Reply-To: <4DFF052A.8020202@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Changing video size (Re: use case:) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 14:13:59 -0000 On 6/20/2011 4:30 AM, Harald Alvestrand wrote: > On 06/17/11 21:38, Aron Rosenberg wrote: >> On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings > > wrote: >> >> >> Video Size Change. >> >> Alice and Bob are in a video call in their browsers and have >> negotiate a high resolution video. Bob decides to change the size >> of the windows his browser is displaying video to a small size. >> Bob's browser should be able to regenerate the video codec >> parameters with Alice's browser to change the resolution of video >> Alice sends to match the smaller size. >> >> >> Changing compression due to a user change in window size is usually >> not done since it has a bad long term effect on video quality. In >> almost all the major video calling systems, video resolution is a >> function of current bandwidth (which changes as the rate control >> system detects differences) and/or constrained by the physical >> device, but not a function of a user dragging the window size. At >> an equivalent bitrate, it is better to compress a larger resolution >> and display it smaller (higher PSNR), then compress a smaller >> resolution if you are within the codec's effective bitrate for that >> larger resolution. Don't use "most current systems" as a guide. Just because they don't do it doesn't mean it's a bad idea (it might be, but more proof than their not doing it is needed). I would assert that in general, it's better to scale before encoding than to scale after decoding; and one scale operation is generally better than two (at camera->encoder, and decoder->display), given a constant bitrate. > Interesting info, but I don't know if it's true in all cases. > > If the overall constraint on a conferencing system is bandwidth, the > system might find the saving in average bandwidth saving of encoding > from a base image of 140x200 for "small" windows rather than "HD" > (720x1024?) worth considering, even though the sending of a complete > I-frame to reinitialize the video stream might take some effort. > > I like having the use case of "change recipient video window size, and > as a result change sender bandwidth usage"; we might argue about the > exact phrasing of the use case. > The more general issue here is one of communication: events such as window resize are of interest to the sender, and may cause the sender to change what they're sending. Events could include bandwidth changes, decode resolution changes, decode framerate changes (probably not common, but perhaps for managing battery use), exposure (decode partly- or fully-obscured, or perhaps the user has zoomed in on one portion of the video), etc. How the encoder reacts to that is largely up to the encoder/app (and input from the decoder app on what it wants); transmission of the information to allow decision-making is what I'm concerned with. Some of these can/should be spoken to in use-cases. -- Randell Jesup randell-ietf@jesup.org From andrew.hutton@siemens-enterprise.com Mon Jun 20 10:11:06 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B7A11E80EB for ; Mon, 20 Jun 2011 10:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r+jocViZyL5 for ; Mon, 20 Jun 2011 10:11:05 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 28FD911E80B5 for ; Mon, 20 Jun 2011 10:11:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: andrew.hutton@siemens-enterprise.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1308589863!22084667!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 24218 invoked from network); 20 Jun 2011 17:11:03 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-4.tower-174.messagelabs.com with SMTP; 20 Jun 2011 17:11:03 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 8B29E1EB83ED; Mon, 20 Jun 2011 19:11:03 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 20 Jun 2011 19:11:03 +0200 From: "Hutton, Andrew" To: Harald Alvestrand , "rtcweb@ietf.org" Date: Mon, 20 Jun 2011 19:11:02 +0200 Thread-Topic: [rtcweb] WG adoption for Use Case document Thread-Index: AcwvIvwRXSnQjxyFRUutTXfAoOZKtwASep3A Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30C22A5FF77@MCHP058A.global-ad.net> References: <4DFB09AC.1090001@ericsson.com> <4DFF02E3.20407@alvestrand.no> In-Reply-To: <4DFF02E3.20407@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] WG adoption for Use Case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 17:11:06 -0000 I also agree with adopting this document and will contribute to the develop= ment of the use cases. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: 20 June 2011 09:21 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] WG adoption for Use Case document >=20 > I agree with adopting the document as a WG starting point. >=20 > Naturally, I expect multiple use cases to be added (and perhaps even > some use cases marked up with "RTCWEB can't do this") before we're > finished. >=20 > Harald >=20 >=20 > On 06/17/11 10:00, Magnus Westerlund wrote: > > WG, > > > > We would like to adopt a WG document with the purpose for describing > use > > cases for the RTCWEB work. This document would be targeted as > > publication as an Inforamtional RFC eventually. > > > > The candidate document for this is: > > Web Real-Time Communication Use-cases and Requirements > > https://datatracker.ietf.org/doc/draft-holmberg-rtcweb-ucreqs/ > > > > Based on our interim last week it was clear that there are some use > > cases that clearly needs development. However, the WG chairs believe > > that future development of the document can be done as WG item. > > > > WG participants please indicate if you agree in adopting this > document > > as a basis, or if not, what the short comings you would like to see > > addressed prior to adoption. Once more, the document will be > continued > > to be developed under the WG control and this is far from any final > > version. > > > > Please provide your view no later than Friday the 24th. > > > > Best Regards > > > > Magnus Westerlund > > WG chair > > > > --------------------------------------------------------------------- > - > > Multimedia Technologies, Ericsson Research EAB/TVM > > --------------------------------------------------------------------- > - > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > --------------------------------------------------------------------- > - > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From vsingh.ietf@gmail.com Tue Jun 21 00:45:50 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E726211E81BE for ; Tue, 21 Jun 2011 00:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9s6hAyWP1NC for ; Tue, 21 Jun 2011 00:45:50 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0A7311E81E4 for ; Tue, 21 Jun 2011 00:45:49 -0700 (PDT) Received: by wyj26 with SMTP id 26so1799172wyj.31 for ; Tue, 21 Jun 2011 00:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type :content-transfer-encoding:content-disposition; bh=/RlxIAIqt/BWclCL5ZZ6IBDSeN/cVblg9f2DVIvNEJs=; b=WxwxxdBQHJvfu2r2lgdrK81q87S409ZRgn+gmqfIuI+vhC4kpEatFiI8E47jYes/+M wVH8cAUebrHddIFyq6gAz/ebUqQ3SMmlod6zN+vETW5xTXNaALnZVtOfRiLIk6aXr3dx Spjh8ewALdG0fI87OnbQtfQjd5TC942G3Y0b4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition; b=vC2hS/9dvnJgiEpKsvrtndINFzB4HPEtK/bfSPDXaTC5w2KLfvqtMFbIa6SU2I3BVJ DfXiq3Kcw2OPPgIrPGJtdwP2BCkVvtvnR02eMfOxPKsSu91ypGUvdejC3/SXKst7auVw TVDDDqHSkapH1AG+vmy5OBX5StpCcK1cgm4dQ= Received: by 10.216.245.4 with SMTP id n4mr428736wer.83.1308642348624; Tue, 21 Jun 2011 00:45:48 -0700 (PDT) Received: from varun.local (guest.imtlucca.it [90.147.23.87]) by mx.google.com with ESMTPS id ge4sm3780693wbb.47.2011.06.21.00.45.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 00:45:47 -0700 (PDT) Date: Tue, 21 Jun 2011 09:45:43 +0200 From: Varun Singh To: rtcweb@ietf.org Message-ID: <2F910F1F060F4EB3979388279209412E@gmail.com> In-Reply-To: <4DFF550C.2000009@jesup.org> References: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> <4DFF052A.8020202@alvestrand.no> <4DFF550C.2000009@jesup.org> X-Mailer: sparrow 1.2.1 (build 767.22) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [rtcweb] Changing video size (Re: use case:) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 07:45:51 -0000 In case of RTP, RTCP carries network level reception statistics and video/voice metrics (RTCP XR etc). However, there is a no standardized congestion control for RTP (http://tools.ietf.org/html/draft-gharai-avtcore-rtp-tfrc-00 uses packet loss and delay not some of the other cues mentioned in the mail). Unless we identify a congestion control, I would suggest that the use-case capture that we need an extensible mechanism to carry this type of information and then the sender implements its own congestion control (best to its ability). -- Varun Singh On Monday, June 20, 2011 at 4:11 PM, Randell Jesup wrote: > On 6/20/2011 4:30 AM, Harald Alvestrand wrote: > > On 06/17/11 21:38, Aron Rosenberg wrote: > > > On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings > > > wrote: > > > > > > > > > Video Size Change. > > > > > > Alice and Bob are in a video call in their browsers and have > > > negotiate a high resolution video. Bob decides to change the size > > > of the windows his browser is displaying video to a small size. > > > Bob's browser should be able to regenerate the video codec > > > parameters with Alice's browser to change the resolution of video > > > Alice sends to match the smaller size. > > > > > > > > > Changing compression due to a user change in window size is usually > > > not done since it has a bad long term effect on video quality. In > > > almost all the major video calling systems, video resolution is a > > > function of current bandwidth (which changes as the rate control > > > system detects differences) and/or constrained by the physical > > > device, but not a function of a user dragging the window size. At > > > an equivalent bitrate, it is better to compress a larger resolution > > > and display it smaller (higher PSNR), then compress a smaller > > > resolution if you are within the codec's effective bitrate for that > > > larger resolution. > > Don't use "most current systems" as a guide. Just because they don't do > it doesn't mean it's a bad idea (it might be, but more proof than their > not doing it is needed). > > I would assert that in general, it's better to scale before encoding > than to scale after decoding; and one scale operation is generally > better than two (at camera->encoder, and decoder->display), given a > constant bitrate. > > > Interesting info, but I don't know if it's true in all cases. > > > > If the overall constraint on a conferencing system is bandwidth, the > > system might find the saving in average bandwidth saving of encoding > > from a base image of 140x200 for "small" windows rather than "HD" > > (720x1024?) worth considering, even though the sending of a complete > > I-frame to reinitialize the video stream might take some effort. > > > > I like having the use case of "change recipient video window size, and > > as a result change sender bandwidth usage"; we might argue about the > > exact phrasing of the use case. > > The more general issue here is one of communication: events such as > window resize are of interest to the sender, and may cause the sender to > change what they're sending. Events could include bandwidth changes, > decode resolution changes, decode framerate changes (probably not > common, but perhaps for managing battery use), exposure (decode partly- > or fully-obscured, or perhaps the user has zoomed in on one portion of > the video), etc. How the encoder reacts to that is largely up to the > encoder/app (and input from the decoder app on what it wants); > transmission of the information to allow decision-making is what I'm > concerned with. > > Some of these can/should be spoken to in use-cases. > > -- > Randell Jesup > randell-ietf@jesup.org (mailto:randell-ietf@jesup.org) > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org (mailto:rtcweb@ietf.org) > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Tue Jun 21 02:48:57 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE6A9E8049 for ; Tue, 21 Jun 2011 02:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lw18hR3nh3rI for ; Tue, 21 Jun 2011 02:48:57 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B7BE69E8046 for ; Tue, 21 Jun 2011 02:48:56 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-7e-4e0069072327 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6F.07.09774.709600E4; Tue, 21 Jun 2011 11:48:55 +0200 (CEST) Received: from [150.132.141.128] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 21 Jun 2011 11:48:52 +0200 Message-ID: <4E006904.9090400@ericsson.com> Date: Tue, 21 Jun 2011 11:48:52 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> <4DFF052A.8020202@alvestrand.no> <4DFF550C.2000009@jesup.org> In-Reply-To: <4DFF550C.2000009@jesup.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Changing video size (Re: use case:) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 09:48:57 -0000 I just want to highlight that changing video display window size is captured already in the very first use case ("Simple Video Communication Service") in http://datatracker.ietf.org/doc/draft-holmberg-rtcweb-ucreqs/?include_text=1. In the preparation of the document we also discussed putting a requirement on that the receiving end should explicitly signal the size or the required codec parameters to the sender but concluded at that time that more discussion is needed. My personal view is that this kind of functionality should be there. After all the suitable codec settings depend a lot on e.g. the display size. But I'm not sure that a requirement is needed. There must be a signaling channel of some kind available to set up streams (to negotiate codecs and codec settings). I think it can be re-used for this purpose. Setting it up this way there could initially be simpler but standard compliant implementations that does not support this, with support added later - with the web application being unaffected. //Stefan On 2011-06-20 16:11, Randell Jesup wrote: > On 6/20/2011 4:30 AM, Harald Alvestrand wrote: >> On 06/17/11 21:38, Aron Rosenberg wrote: >>> On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings>> > wrote: >>> >>> >>> Video Size Change. >>> >>> Alice and Bob are in a video call in their browsers and have >>> negotiate a high resolution video. Bob decides to change the size >>> of the windows his browser is displaying video to a small size. >>> Bob's browser should be able to regenerate the video codec >>> parameters with Alice's browser to change the resolution of video >>> Alice sends to match the smaller size. >>> >>> >>> Changing compression due to a user change in window size is usually >>> not done since it has a bad long term effect on video quality. In >>> almost all the major video calling systems, video resolution is a >>> function of current bandwidth (which changes as the rate control >>> system detects differences) and/or constrained by the physical >>> device, but not a function of a user dragging the window size. At >>> an equivalent bitrate, it is better to compress a larger resolution >>> and display it smaller (higher PSNR), then compress a smaller >>> resolution if you are within the codec's effective bitrate for that >>> larger resolution. > > Don't use "most current systems" as a guide. Just because they don't do > it doesn't mean it's a bad idea (it might be, but more proof than their > not doing it is needed). > > I would assert that in general, it's better to scale before encoding > than to scale after decoding; and one scale operation is generally > better than two (at camera->encoder, and decoder->display), given a > constant bitrate. > >> Interesting info, but I don't know if it's true in all cases. >> >> If the overall constraint on a conferencing system is bandwidth, the >> system might find the saving in average bandwidth saving of encoding >> from a base image of 140x200 for "small" windows rather than "HD" >> (720x1024?) worth considering, even though the sending of a complete >> I-frame to reinitialize the video stream might take some effort. >> >> I like having the use case of "change recipient video window size, and >> as a result change sender bandwidth usage"; we might argue about the >> exact phrasing of the use case. >> > > The more general issue here is one of communication: events such as > window resize are of interest to the sender, and may cause the sender to > change what they're sending. Events could include bandwidth changes, > decode resolution changes, decode framerate changes (probably not > common, but perhaps for managing battery use), exposure (decode partly- > or fully-obscured, or perhaps the user has zoomed in on one portion of > the video), etc. How the encoder reacts to that is largely up to the > encoder/app (and input from the decoder app on what it wants); > transmission of the information to allow decision-making is what I'm > concerned with. > > Some of these can/should be spoken to in use-cases. > From christer.holmberg@ericsson.com Tue Jun 21 05:39:43 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECFC11E80F3 for ; Tue, 21 Jun 2011 05:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vrj5H2ONphxA for ; Tue, 21 Jun 2011 05:39:42 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 555F511E808F for ; Tue, 21 Jun 2011 05:39:42 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-75-4e00910d7ba0 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 90.82.20773.D01900E4; Tue, 21 Jun 2011 14:39:41 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 21 Jun 2011 14:39:39 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Date: Tue, 21 Jun 2011 14:39:38 +0200 Thread-Topic: Use-case grouping Thread-Index: AcwwEEiYPgpJhRA3TdWbCGj02somOw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB5336E53@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05851DB5336E53ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Use-case grouping X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 12:39:43 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05851DB5336E53ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, It's nice to see the amount of use-cases people have submitted :) Now, since many of the use-cases are related to each other, and in order to= get a better and easy-to-read structure of the document, I would like to s= uggest to devide the use-cases into different "use-case groups". Below is a proposed grouping, and examples of use-cases which would be list= ed in each group. I have only used the existing use-cases, and the ones sug= gested by Cullen, but I am aware that more use-cases have been proposed :) Telephony use-cases: - Telephony terminal use-case (draft) - Call fedex use-case (Cullen) Video conferenceing use-cases: - With central server (draft) - Without central server (draft) - Hockey (draft) - Screen re-size (Cullen) Embedded voice communicatoin use-case: - Multiparty on-line game with voice communication (draft) Bandwidth/QoS/mobility use-cases: - NIC Change (Cullen) - QoS Marking (Cullen) Later, we can of course modify/add/remove groups, but I think the grouping = above would be a good start, and I think all the use-cases so far proposed = would fit into one of those groups. Comments? Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05851DB5336E53ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
It's nice to see the amount of use-cases people have = submitted :)
 
 
Now, since many of the use-cases are related to each = other, and in order to get a better and easy-to-read structure of the docum= ent, I would like to suggest to devide the use-cases into different "u= se-case groups".
 
Below is a proposed grouping, and examples of use-cas= es which would be listed in each group. I have only used the existing use-c= ases, and the ones suggested by Cullen, but I am aware that more use-cases = have been proposed :)
 
 
Telephony use-cases:
 
    - Telephony terminal use-case (dra= ft)
    - Call fedex use-case (Cullen)
 
 
Video conferenceing use-cases:
 
    - With central server (draft)
    - Without central server (draft)
    - Hockey (draft)
    - Screen re-size (Cullen)
 
 
Embedded voice communicatoin use-case:
 
   - Multiparty on-line game with voice com= munication (draft)
 
 
Bandwidth/QoS/mobility use-cases:
 
   - NIC Change (Cullen)
   - QoS Marking (Cullen)
 
 
 
Later, we can of course modify/add/remove groups, but= I think the grouping above would be a good start, and I think all the use-= cases so far proposed would fit into one of those groups.
 
Comments?
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05851DB5336E53ESESSCMS0356e_-- From fd@w3.org Tue Jun 21 06:57:51 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5535411E814F for ; Tue, 21 Jun 2011 06:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3mWYROarw4Y for ; Tue, 21 Jun 2011 06:57:50 -0700 (PDT) Received: from lewis.sophia.w3.org (gw.sophia.w3.org [193.51.208.72]) by ietfa.amsl.com (Postfix) with ESMTP id B70F611E80BA for ; Tue, 21 Jun 2011 06:57:50 -0700 (PDT) Received: from 87-231-71-204.rev.numericable.fr ([87.231.71.204] helo=[192.168.0.21]) by lewis.sophia.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QZ1SY-0003AI-IA for rtcweb@ietf.org; Tue, 21 Jun 2011 13:57:42 +0000 Message-ID: <4E00A355.2040309@w3.org> Date: Tue, 21 Jun 2011 15:57:41 +0200 From: Francois Daoust User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] W3C Web Real-Time Communications face-to-face on 23 July 2011 in Quebec City, Canada X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 13:57:51 -0000 Dear participants in the IETF RTCWEB group, The W3C Web Real-Time Communications working group will meet on Saturday 23 July 2011 afternoon, starting at or shortly after 1PM, in Quebec City, Canada, co-located with the IETF Meeting. Exact time range, agenda and location will be announced once known. The choice of the date and place is meant to favor synergies between the W3C WebRTC and the IETF RTCWEB groups. Participants in the IETF RTCWEB group are welcome to attend this W3C face-to-face as meeting guests. To facilitate logistics purpose, I have set up a registration form, available at: http://www.w3.org/2002/09/wbs/47318/webrtc-f2f-quebec/ Anyone can fill out the form. People willing to attend the F2F need to register before 15 July 2011 (the sooner, the better). Please let me know if you have questions. Cheers, Francois Daoust, W3C Team Contact for the W3C WebRTC WG. From magnus.westerlund@ericsson.com Tue Jun 21 08:22:09 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8D411E8176 for ; Tue, 21 Jun 2011 08:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bpw6ZcXixrFK for ; Tue, 21 Jun 2011 08:22:07 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id CE0C311E816A for ; Tue, 21 Jun 2011 08:22:06 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-39-4e00b71de6e0 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1E.30.09774.D17B00E4; Tue, 21 Jun 2011 17:22:05 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 21 Jun 2011 17:22:05 +0200 Message-ID: <4E00B71D.9010502@ericsson.com> Date: Tue, 21 Jun 2011 17:22:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] WG adoption of Architecture and Overview of RTCWEB document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:22:09 -0000 WG, We would like to adopt a document that describes the RTCWEB architecture and provides an overview to the functionality that will be specified in various documents targeted to specific pieces of the functionalities we need for a complete solution. There has been several documents that describes architecture, frame works or overviews. None of them are complete when it comes to covering the different aspects. The documents are: https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-overview/ https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-framework/ https://datatracker.ietf.org/doc/draft-jennings-rtcweb-api/ The WG chairs' proposal is that we adopt one document and then add in aspects that are needed from the other documents. In the process putting together an good editor team for the WG document from the persons that has contributed so far and want to continue. The WG chairs propose that that the WG adopts: https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-overview/ as a WG item to form the core of an Architecture and Overview document. WG participants please provide either support for adoption or provide feedback on any issues you see with this approach. Please provide your view no later than Tuesday the 28th at 17.00 CEST. Magnus Westerlund WG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From harald@alvestrand.no Tue Jun 21 08:26:41 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3D911E819F for ; Tue, 21 Jun 2011 08:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akmprDvDH2mT for ; Tue, 21 Jun 2011 08:26:40 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8A52411E8148 for ; Tue, 21 Jun 2011 08:26:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7BEA139E13B for ; Tue, 21 Jun 2011 17:25:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUfdpMuuSJT1 for ; Tue, 21 Jun 2011 17:25:34 +0200 (CEST) Received: from [192.168.1.53] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id B9F0739E08B for ; Tue, 21 Jun 2011 17:25:34 +0200 (CEST) Message-ID: <4E00B82A.1000908@alvestrand.no> Date: Tue, 21 Jun 2011 17:26:34 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> <4DFF052A.8020202@alvestrand.no> <4DFF550C.2000009@jesup.org> <2F910F1F060F4EB3979388279209412E@gmail.com> In-Reply-To: <2F910F1F060F4EB3979388279209412E@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Changing video size (Re: use case:) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:26:41 -0000 On 06/21/11 09:45, Varun Singh wrote: > In case of RTP, RTCP carries network level reception statistics and video/voice metrics (RTCP XR etc). However, there is a no standardized congestion control for RTP (http://tools.ietf.org/html/draft-gharai-avtcore-rtp-tfrc-00 uses packet loss and delay not some of the other cues mentioned in the mail). > > Unless we identify a congestion control, I would suggest that the use-case capture that we need an extensible mechanism to carry this type of information and then the sender implements its own congestion control (best to its ability). > I think we need to separate the two requirements: - response to network conditions (congestion control) - response to recipient system conditions such as window size, CPU load, window being obscured, and so on. Even though the possible actions to take might be the same, the two are fundamentally different; responses to end system events concern only the sender and the recipient, while responses to congestion events have the requirement that the behavior be globally sensible - that is, works well with the algorithms deployed by other users of the network. Harald From harald@alvestrand.no Tue Jun 21 08:30:01 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B766A11E825B for ; Tue, 21 Jun 2011 08:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knZn70LLaPVy for ; Tue, 21 Jun 2011 08:30:01 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B653B11E8148 for ; Tue, 21 Jun 2011 08:30:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7EE4839E13B for ; Tue, 21 Jun 2011 17:29:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hko3bjN2YYpT for ; Tue, 21 Jun 2011 17:29:00 +0200 (CEST) Received: from [192.168.1.53] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 70C5F39E08B for ; Tue, 21 Jun 2011 17:29:00 +0200 (CEST) Message-ID: <4E00B8F8.4050306@alvestrand.no> Date: Tue, 21 Jun 2011 17:30:00 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336E53@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB5336E53@ESESSCMS0356.eemea.ericsson.se> Content-Type: multipart/alternative; boundary="------------070201030908020204060002" Subject: Re: [rtcweb] Use-case grouping X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:30:01 -0000 This is a multi-part message in MIME format. --------------070201030908020204060002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Seems to me sensible to have groupings. The use case I don't see a place for at the moment is the single point-to-point call; the proposed use case I don't see mentioned below is my suggestion for "interoperable calling". So this might require more tuning. On 06/21/11 14:39, Christer Holmberg wrote: > Hi, > It's nice to see the amount of use-cases people have submitted :) > Now, since many of the use-cases are related to each other, and in > order to get a better and easy-to-read structure of the document, I > would like to suggest to devide the use-cases into different "use-case > groups". > Below is a proposed grouping, and examples of use-cases which would be > listed in each group. I have only used the existing use-cases, and the > ones suggested by Cullen, but I am aware that more use-cases have been > proposed :) > Telephony use-cases: > - Telephony terminal use-case (draft) > - Call fedex use-case (Cullen) > Video conferenceing use-cases: > - With central server (draft) > - Without central server (draft) > - Hockey (draft) > - Screen re-size (Cullen) > Embedded voice communicatoin use-case: > - Multiparty on-line game with voice communication (draft) > Bandwidth/QoS/mobility use-cases: > - NIC Change (Cullen) > - QoS Marking (Cullen) > Later, we can of course modify/add/remove groups, but I think the > grouping above would be a good start, and I think all the use-cases so > far proposed would fit into one of those groups. > Comments? > Regards, > Christer > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------070201030908020204060002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Seems to me sensible to have groupings.

The use case I don't see a place for at the moment is the single point-to-point call; the proposed use case I don't see mentioned below is my suggestion for "interoperable calling".

So this might require more tuning.

On 06/21/11 14:39, Christer Holmberg wrote:
 
Hi,
 
It's nice to see the amount of use-cases people have submitted :)
 
 
Now, since many of the use-cases are related to each other, and in order to get a better and easy-to-read structure of the document, I would like to suggest to devide the use-cases into different "use-case groups".
 
Below is a proposed grouping, and examples of use-cases which would be listed in each group. I have only used the existing use-cases, and the ones suggested by Cullen, but I am aware that more use-cases have been proposed :)
 
 
Telephony use-cases:
 
    - Telephony terminal use-case (draft)
    - Call fedex use-case (Cullen)
 
 
Video conferenceing use-cases:
 
    - With central server (draft)
    - Without central server (draft)
    - Hockey (draft)
    - Screen re-size (Cullen)
 
 
Embedded voice communicatoin use-case:
 
   - Multiparty on-line game with voice communication (draft)
 
 
Bandwidth/QoS/mobility use-cases:
 
   - NIC Change (Cullen)
   - QoS Marking (Cullen)
 
 
 
Later, we can of course modify/add/remove groups, but I think the grouping above would be a good start, and I think all the use-cases so far proposed would fit into one of those groups.
 
Comments?
 
Regards,
 
Christer
 
 

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

--------------070201030908020204060002-- From stefan.lk.hakansson@ericsson.com Tue Jun 21 08:36:12 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6DA11E8266 for ; Tue, 21 Jun 2011 08:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSxH3E+rRgO0 for ; Tue, 21 Jun 2011 08:36:12 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2B711E8267 for ; Tue, 21 Jun 2011 08:36:10 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-7b-4e00ba5b15fb Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C8.23.09774.B5AB00E4; Tue, 21 Jun 2011 17:35:56 +0200 (CEST) Received: from [153.88.44.59] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 21 Jun 2011 17:35:55 +0200 Message-ID: <4E00BA5A.5080005@ericsson.com> Date: Tue, 21 Jun 2011 17:35:54 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> <4DFF052A.8020202@alvestrand.no> <4DFF550C.2000009@jesup.org> <2F910F1F060F4EB3979388279209412E@gmail.com> <4E00B82A.1000908@alvestrand.no> In-Reply-To: <4E00B82A.1000908@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Changing video size (Re: use case:) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:36:12 -0000 +1 On 2011-06-21 17:26, Harald Alvestrand wrote: > On 06/21/11 09:45, Varun Singh wrote: >> In case of RTP, RTCP carries network level reception statistics and video/voice metrics (RTCP XR etc). However, there is a no standardized congestion control for RTP (http://tools.ietf.org/html/draft-gharai-avtcore-rtp-tfrc-00 uses packet loss and delay not some of the other cues mentioned in the mail). >> >> Unless we identify a congestion control, I would suggest that the use-case capture that we need an extensible mechanism to carry this type of information and then the sender implements its own congestion control (best to its ability). >> > I think we need to separate the two requirements: > > - response to network conditions (congestion control) > - response to recipient system conditions such as window size, CPU load, > window being obscured, and so on. > > Even though the possible actions to take might be the same, the two are > fundamentally different; responses to end system events concern only the > sender and the recipient, while responses to congestion events have the > requirement that the behavior be globally sensible - that is, works well > with the algorithms deployed by other users of the network. > > Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Tue Jun 21 08:59:15 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A87511E828C for ; Tue, 21 Jun 2011 08:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpqpbLtAHGXH for ; Tue, 21 Jun 2011 08:59:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B1AD311E8276 for ; Tue, 21 Jun 2011 08:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1773; q=dns/txt; s=iport; t=1308671954; x=1309881554; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=jLgHnsOIlHWSbrT8X4E/y/d+eYs6bIEiMyj5W8ftuAA=; b=iG0x3uTFtkMBlqM/xJY/vX1HB/dfAA2RawgTt2QAsxEFr/sxIJwcu7Wp s0B83oeFArhbSoxMDVkfDhMosh+jXeri47LwWqXPFYHjNfe35Kn46K+u4 XBXJF6TYDnUoW4utpL6NO7b4VrA5JADmTd8XwlfzFqFvzpzxWM91cbBEa 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALe+AE5Io8UR/2dsb2JhbABUpnF3iHOhN55GhioEhyKKRJAm X-IronPort-AV: E=Sophos;i="4.65,402,1304294400"; d="scan'208";a="95529472" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 21 Jun 2011 15:59:13 +0000 Received: from dhcp-171-68-21-107.cisco.com (dhcp-171-68-21-107.cisco.com [171.68.21.107]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5LFwDgk029565; Tue, 21 Jun 2011 15:59:11 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB5336E53@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 21 Jun 2011 08:59:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336E53@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Use-case grouping X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:59:15 -0000 Yes, I like this grouping. On Jun 21, 2011, at 5:39 , Christer Holmberg wrote: > =20 > Hi, > =20 > It's nice to see the amount of use-cases people have submitted :) > =20 > =20 > Now, since many of the use-cases are related to each other, and in = order to get a better and easy-to-read structure of the document, I = would like to suggest to devide the use-cases into different "use-case = groups". > =20 > Below is a proposed grouping, and examples of use-cases which would be = listed in each group. I have only used the existing use-cases, and the = ones suggested by Cullen, but I am aware that more use-cases have been = proposed :) > =20 > =20 > Telephony use-cases: > =20 > - Telephony terminal use-case (draft) > - Call fedex use-case (Cullen) > =20 > =20 > Video conferenceing use-cases: > =20 > - With central server (draft) > - Without central server (draft) > - Hockey (draft) > - Screen re-size (Cullen) > =20 > =20 > Embedded voice communicatoin use-case: > =20 > - Multiparty on-line game with voice communication (draft) > =20 > =20 > Bandwidth/QoS/mobility use-cases: > =20 > - NIC Change (Cullen) > - QoS Marking (Cullen) > =20 > =20 > =20 > Later, we can of course modify/add/remove groups, but I think the = grouping above would be a good start, and I think all the use-cases so = far proposed would fit into one of those groups. > =20 > Comments? > =20 > Regards, > =20 > Christer > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From stewe@stewe.org Tue Jun 21 09:10:14 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936EC11E826D for ; Tue, 21 Jun 2011 09:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45W71GH7d54U for ; Tue, 21 Jun 2011 09:10:12 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id CDE9111E829F for ; Tue, 21 Jun 2011 09:10:10 -0700 (PDT) Received: from [172.16.7.218] (unverified [160.79.219.114]) by stewe.org (SurgeMail 3.9e) with ESMTP id 4436-1743317 for multiple; Tue, 21 Jun 2011 18:10:09 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Tue, 21 Jun 2011 09:10:00 -0700 From: Stephan Wenger To: Magnus Westerlund , "rtcweb@ietf.org" Message-ID: Thread-Topic: [rtcweb] WG adoption of Architecture and Overview of RTCWEB document In-Reply-To: <4E00B71D.9010502@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 160.79.219.114 X-Authenticated-User: stewe@stewe.org Subject: Re: [rtcweb] WG adoption of Architecture and Overview of RTCWEB document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 16:10:14 -0000 Magnus' proposal of picking Harald's draft is fine with me. Stephan On 6.21.2011 08:22 , "Magnus Westerlund" wrote: >WG, > >We would like to adopt a document that describes the RTCWEB architecture >and provides an overview to the functionality that will be specified in >various documents targeted to specific pieces of the functionalities we >need for a complete solution. > >There has been several documents that describes architecture, frame >works or overviews. None of them are complete when it comes to covering >the different aspects. The documents are: > >https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-overview/ >https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-framework/ >https://datatracker.ietf.org/doc/draft-jennings-rtcweb-api/ > >The WG chairs' proposal is that we adopt one document and then add in >aspects that are needed from the other documents. In the process putting >together an good editor team for the WG document from the persons that >has contributed so far and want to continue. > >The WG chairs propose that that the WG adopts: >https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-overview/ >as a WG item to form the core of an Architecture and Overview document. > >WG participants please provide either support for adoption or provide >feedback on any issues you see with this approach. > >Please provide your view no later than Tuesday the 28th at 17.00 CEST. > >Magnus Westerlund >WG Chair > >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Tue Jun 21 09:11:21 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D4C11E8280 for ; Tue, 21 Jun 2011 09:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YN8ihhf0Bab for ; Tue, 21 Jun 2011 09:11:20 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B717D11E816F for ; Tue, 21 Jun 2011 09:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1875; q=dns/txt; s=iport; t=1308672679; x=1309882279; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=QTztOyePuZc4VXX5kTNMfiOg2wnvpsPLBhId1pnnc5M=; b=NlK7YrNg3ZfAgCy6uvEOySeMSlsYekNnfoILI/bVZ9jaTcMjS+RmWD5N tsCKQ3NsTC0qHx+5pvwW2d4/xnogmUUltmC4JyR6UhzuEiNNMGi9dfbo/ +nE+bOtDDO97tL5WFUmNv0xGpaV3ZbdWJ3B5EuVqOnnHrx56PrAjXz05x g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADnCAE5Io8US/2dsb2JhbABUpnF3iHOhO55IhioEhyKKRJAm X-IronPort-AV: E=Sophos;i="4.65,402,1304294400"; d="scan'208";a="95535726" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 21 Jun 2011 16:11:17 +0000 Received: from dhcp-171-68-21-107.cisco.com (dhcp-171-68-21-107.cisco.com [171.68.21.107]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5LGBEeN021718; Tue, 21 Jun 2011 16:11:15 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4DFF052A.8020202@alvestrand.no> Date: Tue, 21 Jun 2011 09:11:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <01A17A75-0700-416E-A4D4-C6EB97265F8B@cisco.com> References: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> <4DFF052A.8020202@alvestrand.no> To: Aron Rosenberg X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Changing video size (Re: use case:) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 16:11:21 -0000 On Jun 20, 2011, at 1:30 , Harald Alvestrand wrote: > On 06/17/11 21:38, Aron Rosenberg wrote: >> On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings = wrote: >>=20 >> Video Size Change. >>=20 >> Alice and Bob are in a video call in their browsers and have = negotiate a high resolution video. Bob decides to change the size of the = windows his browser is displaying video to a small size. Bob's browser = should be able to regenerate the video codec parameters with Alice's = browser to change the resolution of video Alice sends to match the = smaller size. >>=20 >>=20 >> Changing compression due to a user change in window size is usually = not done since it has a bad long term effect on video quality. In almost = all the major video calling systems, video resolution is a function of = current bandwidth (which changes as the rate control system detects = differences) and/or constrained by the physical device, but not a = function of a user dragging the window size. At an equivalent bitrate, = it is better to compress a larger resolution and display it smaller = (higher PSNR), then compress a smaller resolution if you are within the = codec's effective bitrate for that larger resolution. Consider two different video flows using the same codec ... Stream A is 640 x 480 at 1mbps which is this scaled to 320x240 and = displayed Stream B is 320 x 240 at 1mbps which is displayed at 320x240.=20 My experience has been with modern video codecs that stream B will look = better than stream A. As well as looking better, it will typically also = have a better PSNR. There's a bunch of reasons why which are probably = not worth going into here but give it a try and you will see what I = mean. The key point is both streams where 1mbps. If stream B was sent at = 256 kbps, then A would look better.=20 From fluffy@cisco.com Tue Jun 21 09:17:12 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2861321F8470 for ; Tue, 21 Jun 2011 09:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjopF5GgGvob for ; Tue, 21 Jun 2011 09:17:11 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id BFA6521F843D for ; Tue, 21 Jun 2011 09:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1994; q=dns/txt; s=iport; t=1308673030; x=1309882630; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cT+AAzo/m+HT4JimxPw3Unp3E6ymOZbQQfMz/01aC38=; b=ZWc30gDcFudrJkhcH3dV6H/bG8kpFkbCml24PdMKpcDv1m4QIN8HFGyR NAcC6PBUsEjlEAUZHPpbDuVJmdY8/yYoT7SDFq4g3UVAj/793kCxn5bpb M7ro/OY5s2N3/r3Q5aT+27yzuAfD6v1yrGMZY541bj733OiDu7PVA8fLi k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGvDAE6rRDoH/2dsb2JhbABGDqZxd6oqnkeDHYMNBIciikSQJg X-IronPort-AV: E=Sophos;i="4.65,402,1304294400"; d="scan'208";a="382327053" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 21 Jun 2011 16:16:27 +0000 Received: from dhcp-171-68-21-107.cisco.com (dhcp-171-68-21-107.cisco.com [171.68.21.107]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5LGGRGf025843; Tue, 21 Jun 2011 16:16:27 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <4E00BA5A.5080005@ericsson.com> Date: Tue, 21 Jun 2011 09:16:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> <4DFF052A.8020202@alvestrand.no> <4DFF550C.2000009@jesup.org> <2F910F1F060F4EB3979388279209412E@gmail.com> <4E00B82A.1000908@alvestrand.no> <4E00BA5A.5080005@ericsson.com> To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Changing video size (Re: use case:) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 16:17:12 -0000 On Jun 21, 2011, at 8:35 , Stefan H=E5kansson LK wrote: > +1 > On 2011-06-21 17:26, Harald Alvestrand wrote: >> On 06/21/11 09:45, Varun Singh wrote: >>> In case of RTP, RTCP carries network level reception statistics and = video/voice metrics (RTCP XR etc). However, there is a no standardized = congestion control for RTP = (http://tools.ietf.org/html/draft-gharai-avtcore-rtp-tfrc-00 uses packet = loss and delay not some of the other cues mentioned in the mail). >>>=20 >>> Unless we identify a congestion control, I would suggest that the = use-case capture that we need an extensible mechanism to carry this type = of information and then the sender implements its own congestion control = (best to its ability). >>>=20 >> I think we need to separate the two requirements: >>=20 >> - response to network conditions (congestion control) >> - response to recipient system conditions such as window size, CPU = load, >> window being obscured, and so on. >>=20 >> Even though the possible actions to take might be the same, the two = are >> fundamentally different; responses to end system events concern only = the >> sender and the recipient, while responses to congestion events have = the >> requirement that the behavior be globally sensible - that is, works = well >> with the algorithms deployed by other users of the network. >>=20 >> Harald +1 It seems to me that what resolution video you send often is the = largest size that is smaller than several constraints. The constraints = include what you have bandwidth to transports, what the receiver is = capable of displaying, and the desires of the two users involved. No one = argues we should send 1080P video to a systems that is only capable of = decoding 720P. I think what I was trying to get at in the use case is = that these things depend on the desires of both the sending and = receiving systems and they change dynamically during the session.=20 From stewe@stewe.org Tue Jun 21 09:23:48 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8F311E8121 for ; Tue, 21 Jun 2011 09:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9vRHkcFxug0 for ; Tue, 21 Jun 2011 09:23:47 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6203A11E8160 for ; Tue, 21 Jun 2011 09:23:47 -0700 (PDT) Received: from [172.16.7.218] (unverified [160.79.219.114]) by stewe.org (SurgeMail 3.9e) with ESMTP id 4448-1743317 for multiple; Tue, 21 Jun 2011 18:23:45 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Tue, 21 Jun 2011 09:23:41 -0700 From: Stephan Wenger To: Cullen Jennings , Aron Rosenberg Message-ID: Thread-Topic: [rtcweb] Changing video size (Re: use case:) In-Reply-To: <01A17A75-0700-416E-A4D4-C6EB97265F8B@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 160.79.219.114 X-Authenticated-User: stewe@stewe.org Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Changing video size (Re: use case:) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 16:23:48 -0000 What Cullen writes below matches my experience. And, its not even limited to "modern" codecs. I would suggest that the observed behavior is true for any video codec that has sub-pel motion compensation, i.e. any video compression standard developed since H.263 (1998). Stephan On 6.21.2011 09:11 , "Cullen Jennings" wrote: >[...] > >Consider two different video flows using the same codec ... > >Stream A is 640 x 480 at 1mbps which is this scaled to 320x240 and >displayed > >Stream B is 320 x 240 at 1mbps which is displayed at 320x240. > >My experience has been with modern video codecs that stream B will look >better than stream A. As well as looking better, it will typically also >have a better PSNR. There's a bunch of reasons why which are probably not >worth going into here but give it a try and you will see what I mean. The >key point is both streams where 1mbps. If stream B was sent at 256 kbps, >then A would look better. > > > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Tue Jun 21 10:11:41 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B969511E8091 for ; Tue, 21 Jun 2011 10:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcUJlrM6SPfo for ; Tue, 21 Jun 2011 10:11:41 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B948C11E808B for ; Tue, 21 Jun 2011 10:11:40 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-58-4e00d0cb8b4c Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 06.0D.20773.BC0D00E4; Tue, 21 Jun 2011 19:11:39 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 21 Jun 2011 19:11:37 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Date: Tue, 21 Jun 2011 19:10:44 +0200 Thread-Topic: [rtcweb] Use-case grouping Thread-Index: AcwwKBkpm2xc+n+GQ1Gb7cU29D+/KgADg67b Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29A@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336E53@ESESSCMS0356.eemea.ericsson.se>, <4E00B8F8.4050306@alvestrand.no> In-Reply-To: <4E00B8F8.4050306@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Use-case grouping X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 17:11:41 -0000 Hi Harald, We could add a "Point-to-point", or "Browser-to-browser", use-case group. Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Harald= Alvestrand [harald@alvestrand.no] Sent: Tuesday, June 21, 2011 6:30 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] Use-case grouping Seems to me sensible to have groupings. The use case I don't see a place for at the moment is the single point-to-p= oint call; the proposed use case I don't see mentioned below is my suggesti= on for "interoperable calling". So this might require more tuning. On 06/21/11 14:39, Christer Holmberg wrote: Hi, It's nice to see the amount of use-cases people have submitted :) Now, since many of the use-cases are related to each other, and in order to= get a better and easy-to-read structure of the document, I would like to s= uggest to devide the use-cases into different "use-case groups". Below is a proposed grouping, and examples of use-cases which would be list= ed in each group. I have only used the existing use-cases, and the ones sug= gested by Cullen, but I am aware that more use-cases have been proposed :) Telephony use-cases: - Telephony terminal use-case (draft) - Call fedex use-case (Cullen) Video conferenceing use-cases: - With central server (draft) - Without central server (draft) - Hockey (draft) - Screen re-size (Cullen) Embedded voice communicatoin use-case: - Multiparty on-line game with voice communication (draft) Bandwidth/QoS/mobility use-cases: - NIC Change (Cullen) - QoS Marking (Cullen) Later, we can of course modify/add/remove groups, but I think the grouping = above would be a good start, and I think all the use-cases so far proposed = would fit into one of those groups. Comments? Regards, Christer _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From Bert.Greevenbosch@huawei.com Tue Jun 21 20:20:00 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9F921F8486 for ; Tue, 21 Jun 2011 20:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgDwvMW9sMik for ; Tue, 21 Jun 2011 20:19:59 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6916B21F8481 for ; Tue, 21 Jun 2011 20:19:59 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN6004MJ9994K@szxga04-in.huawei.com> for rtcweb@ietf.org; Wed, 22 Jun 2011 11:19:58 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN600JLV998UM@szxga04-in.huawei.com> for rtcweb@ietf.org; Wed, 22 Jun 2011 11:19:57 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml205-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ABZ49277; Wed, 22 Jun 2011 11:19:57 +0800 (CST) Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 22 Jun 2011 11:19:49 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.140]) by szxeml409-hub.china.huawei.com ([169.254.57.252]) with mapi id 14.01.0270.001; Wed, 22 Jun 2011 11:19:43 +0800 Date: Wed, 22 Jun 2011 03:19:42 +0000 From: Bert Greevenbosch In-reply-to: <01A17A75-0700-416E-A4D4-C6EB97265F8B@cisco.com> X-Originating-IP: [10.70.109.57] To: Cullen Jennings , Aron Rosenberg Message-id: <46A1DF3F04371240B504290A071B4DB601301A2E@SZXEML501-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [rtcweb] Changing video size (Re: use case:) Thread-index: AQHMLyRYJEN5T0e70kekdx+83OJoNpTHd0uAgAE1ukA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> <4DFF052A.8020202@alvestrand.no> <01A17A75-0700-416E-A4D4-C6EB97265F8B@cisco.com> Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Changing video size (Re: use case:) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 03:20:00 -0000 Hi Cullen, all, Consider two different video flows using the same codec ... Stream A is 640 x 480 at 1mbps which is this scaled to 320x240 and displayed Stream B is 320 x 240 at 1mbps which is displayed at 320x240. My experience has been with modern video codecs that stream B will look better than stream A. As well as looking better, it will typically also have a better PSNR. There's a bunch of reasons why which are probably not worth going into here but give it a try and you will see what I mean. The key point is both streams where 1mbps. If stream B was sent at 256 kbps, then A would look better. Can I ask what you mean with "both streams where 1mbps"? Do you refer to the capacity of the channel (i.e. how much data the channel can transport), or to the actually codec bitrate (i.e. how much data is sent from the streaming server). In the first case, assuming that the size of stream B is considerably less than the size of stream A, the quality of Stream B can be expected to be higher than the quality of Stream A, since a higher capacity of the channel results in less packet loss. In the second case, assuming both streams are coded at the same bitrate, the quality of Stream B can also be expected to be higher than the quality of Stream A, due to the availability of more bits per pixel (though similar packet loss). However, if we reduce the capacity of the channel, it becomes more complicated. I think this highly depends on which codec is being used. For example, I am not sure whether Stream B with 25% channel capacity would look better than Stream A (after scaling) with 100% channel capacity. I think this highly depends on the codec and scaling algorithm, and saturation of the channel. To come to the question on whether negotiation of the video size is needed: I feel that it could be a useful feature. Even if the channel allows streaming the 640x480 version without congestion problems now, where is the guarantee that it will not happen later? Probably there will be multiple video streams (at least partially) using the same path. If congestion happens later, the codec bitrate of multiple streams may need to be reduced. How to know from which streams the bitrate needs to be reduced? It seems to be better to prevent this and use a reduced codec bitrate from the start for those streams that are known not to require a higher bitrate. However, whether we can cater for this also depends on the actual technical solution for negotiation and which codec to use. If adding video size negotiation will not increase complexity too much, I see no reason not to do it. However, if it adds much complexity to the solution, we might need to consider whether it is worth it. Therefore, maybe it should not be a requirement, but something weaker; i.e. it could be phrased as a SHOULD rather than a MUST. Best regards, Bert -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: 22 June 2011 00:11 To: Aron Rosenberg Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Changing video size (Re: use case:) On Jun 20, 2011, at 1:30 , Harald Alvestrand wrote: > On 06/17/11 21:38, Aron Rosenberg wrote: >> On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings wrote: >> >> Video Size Change. >> >> Alice and Bob are in a video call in their browsers and have negotiate a high resolution video. Bob decides to change the size of the windows his browser is displaying video to a small size. Bob's browser should be able to regenerate the video codec parameters with Alice's browser to change the resolution of video Alice sends to match the smaller size. >> >> >> Changing compression due to a user change in window size is usually not done since it has a bad long term effect on video quality. In almost all the major video calling systems, video resolution is a function of current bandwidth (which changes as the rate control system detects differences) and/or constrained by the physical device, but not a function of a user dragging the window size. At an equivalent bitrate, it is better to compress a larger resolution and display it smaller (higher PSNR), then compress a smaller resolution if you are within the codec's effective bitrate for that larger resolution. Consider two different video flows using the same codec ... Stream A is 640 x 480 at 1mbps which is this scaled to 320x240 and displayed Stream B is 320 x 240 at 1mbps which is displayed at 320x240. My experience has been with modern video codecs that stream B will look better than stream A. As well as looking better, it will typically also have a better PSNR. There's a bunch of reasons why which are probably not worth going into here but give it a try and you will see what I mean. The key point is both streams where 1mbps. If stream B was sent at 256 kbps, then A would look better. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From likepeng@huawei.com Tue Jun 21 20:50:15 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F34F11E8101 for ; Tue, 21 Jun 2011 20:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNE0DOw13YHf for ; Tue, 21 Jun 2011 20:50:15 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2146111E80FA for ; Tue, 21 Jun 2011 20:50:10 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN600K8IAM0A2@szxga03-in.huawei.com> for rtcweb@ietf.org; Wed, 22 Jun 2011 11:49:12 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN60072PALUQX@szxga03-in.huawei.com> for rtcweb@ietf.org; Wed, 22 Jun 2011 11:49:12 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml205-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ABZ51694; Wed, 22 Jun 2011 11:49:09 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 22 Jun 2011 11:49:07 +0800 Received: from SZXEML506-MBX.china.huawei.com ([169.254.4.112]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Wed, 22 Jun 2011 11:49:08 +0800 Date: Wed, 22 Jun 2011 03:49:07 +0000 From: Likepeng In-reply-to: X-Originating-IP: [10.70.109.110] To: Stephan Wenger , Magnus Westerlund , "rtcweb@ietf.org" Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F22B71E5@szxeml506-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: zh-CN, en-US Thread-topic: [rtcweb] WG adoption of Architecture and Overview of RTCWEB document Thread-index: AQHMMCcABvTwtDYu6kuhNKfwv0xilJTHdO0AgAEbQ3A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E00B71D.9010502@ericsson.com> Subject: Re: [rtcweb] WG adoption of Architecture and Overview of RTCWEB document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 03:50:15 -0000 I am fine with the proposal, but should the overview draft be informational= , instead of standard track? Thanks, Kind Regards Kepeng -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Stephan Wenger Sent: Wednesday, June 22, 2011 12:10 AM To: Magnus Westerlund; rtcweb@ietf.org Subject: Re: [rtcweb] WG adoption of Architecture and Overview of RTCWEB do= cument Magnus' proposal of picking Harald's draft is fine with me. Stephan On 6.21.2011 08:22 , "Magnus Westerlund" wrote: >WG, > >We would like to adopt a document that describes the RTCWEB architecture >and provides an overview to the functionality that will be specified in >various documents targeted to specific pieces of the functionalities we >need for a complete solution. > >There has been several documents that describes architecture, frame >works or overviews. None of them are complete when it comes to covering >the different aspects. The documents are: > >https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-overview/ >https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-framework/ >https://datatracker.ietf.org/doc/draft-jennings-rtcweb-api/ > >The WG chairs' proposal is that we adopt one document and then add in >aspects that are needed from the other documents. In the process putting >together an good editor team for the WG document from the persons that >has contributed so far and want to continue. > >The WG chairs propose that that the WG adopts: >https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-overview/ >as a WG item to form the core of an Architecture and Overview document. > >WG participants please provide either support for adoption or provide >feedback on any issues you see with this approach. > >Please provide your view no later than Tuesday the 28th at 17.00 CEST. > >Magnus Westerlund >WG Chair > >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- From juberti@google.com Tue Jun 21 20:59:42 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973B311E80FA for ; Tue, 21 Jun 2011 20:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.143 X-Spam-Level: X-Spam-Status: No, score=-105.143 tagged_above=-999 required=5 tests=[AWL=0.833, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciX6nh-9uKvj for ; Tue, 21 Jun 2011 20:59:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id B6EAF11E80DA for ; Tue, 21 Jun 2011 20:59:41 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p5M3xe5G018267 for ; Tue, 21 Jun 2011 20:59:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308715180; bh=08T7r2H2f1tGHVEpgny/dtnVKn0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Sh1eqKId0uOWd2MFEefnuo99KVXZtX2QHhi8Yn9yBH4jxbLt2mefxPNLcp+GpslSc iBokWGLc13fITbcMMziIw== Received: from iyi20 (iyi20.prod.google.com [10.241.51.20]) by kpbe14.cbf.corp.google.com with ESMTP id p5M3xder001045 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 21 Jun 2011 20:59:39 -0700 Received: by iyi20 with SMTP id 20so424641iyi.7 for ; Tue, 21 Jun 2011 20:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=o/eOPdukRQRsgRRy/m8m52wAqJZYuOGWQIzjdFuPhJk=; b=TJqYD8jEbNADWRITmW9ReBAjNf66rfhA5aN8qbCtPpYaCbqFuHmGclhWk5czV1VFZC cRupB9GUJDdj+YNt8b6Q== 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=VkJhvBzfIPtdYiiEWMNldVWYLV3WmCcZST+1y6weSra+tccp0TEyCANzqEX/uo0Gwl 8E00JskYoYAinWRK4DfA== Received: by 10.231.68.202 with SMTP id w10mr207360ibi.63.1308715179129; Tue, 21 Jun 2011 20:59:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.34.6 with HTTP; Tue, 21 Jun 2011 20:59:19 -0700 (PDT) In-Reply-To: <46A1DF3F04371240B504290A071B4DB601301A2E@SZXEML501-MBS.china.huawei.com> References: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> <4DFF052A.8020202@alvestrand.no> <01A17A75-0700-416E-A4D4-C6EB97265F8B@cisco.com> <46A1DF3F04371240B504290A071B4DB601301A2E@SZXEML501-MBS.china.huawei.com> From: Justin Uberti Date: Tue, 21 Jun 2011 20:59:19 -0700 Message-ID: To: Bert Greevenbosch Content-Type: multipart/alternative; boundary=0015177407d05d3b9404a644ff1f X-System-Of-Record: true Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Changing video size (Re: use case:) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 03:59:42 -0000 --0015177407d05d3b9404a644ff1f Content-Type: text/plain; charset=UTF-8 Given the fact that this request for a video size change is an optimization (either of resources or user experience), I think that SHOULD is probably the strongest label we can put on it. Consider the case of a middlebox; if it has no capacity to scale the stream, due to compute or codec restrictions, there's not much it can do with this request. > However, whether we can cater for this also depends on the actual technical > solution for negotiation and which codec to use. If adding video size > negotiation will not increase complexity too much, I see no reason not to do > it. However, if it adds much complexity to the solution, we might need to > consider whether it is worth it. Therefore, maybe it should not be a > requirement, but something weaker; i.e. it could be phrased as a SHOULD > rather than a MUST. > > Best regards, > Bert > > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Cullen Jennings > Sent: 22 June 2011 00:11 > To: Aron Rosenberg > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Changing video size (Re: use case:) > > > On Jun 20, 2011, at 1:30 , Harald Alvestrand wrote: > > > On 06/17/11 21:38, Aron Rosenberg wrote: > >> On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings > wrote: > >> > >> Video Size Change. > >> > >> Alice and Bob are in a video call in their browsers and have negotiate a > high resolution video. Bob decides to change the size of the windows his > browser is displaying video to a small size. Bob's browser should be able > to regenerate the video codec parameters with Alice's browser to change the > resolution of video Alice sends to match the smaller size. > >> > >> > >> Changing compression due to a user change in window size is usually not > done since it has a bad long term effect on video quality. In almost all the > major video calling systems, video resolution is a function of current > bandwidth (which changes as the rate control system detects differences) > and/or constrained by the physical device, but not a function of a user > dragging the window size. At an equivalent bitrate, it is better to compress > a larger resolution and display it smaller (higher PSNR), then compress a > smaller resolution if you are within the codec's effective bitrate for that > larger resolution. > > Consider two different video flows using the same codec ... > > Stream A is 640 x 480 at 1mbps which is this scaled to 320x240 and > displayed > > Stream B is 320 x 240 at 1mbps which is displayed at 320x240. > > My experience has been with modern video codecs that stream B will look > better than stream A. As well as looking better, it will typically also have > a better PSNR. There's a bunch of reasons why which are probably not worth > going into here but give it a try and you will see what I mean. The key > point is both streams where 1mbps. If stream B was sent at 256 kbps, then A > would look better. > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0015177407d05d3b9404a644ff1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Given the fact that this request for a vide= o size change is an optimization (either of resources or user experience), = I think that SHOULD is probably the strongest label we can put on it. Consi= der the case of a middlebox; if it has no capacity to scale the stream, due= to compute or codec restrictions, there's not much it can do with this= request.


However, whether we can cater for this also depends on the actual technical= solution for negotiation and which codec to use. If adding video size nego= tiation will not increase complexity too much, I see no reason not to do it= . However, if it adds much complexity to the solution, we might need to con= sider whether it is worth it. Therefore, maybe it should not be a requireme= nt, but something weaker; i.e. it could be phrased as a SHOULD rather than = a MUST.

Best regards,
Bert


-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.or= g] On Behalf Of Cullen Jennings
Sent: 22 June 2011 00:11
To: Aron Rosenberg
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Changing vide= o size (Re: use case:)


On Jun 20, 2011, at 1:30 , Harald Alvestrand wrote:

> On 06/17/11 21:38, Aron Rosenberg wrote:
>> On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings <fluffy@cisco.com> wrote:
>>
>> Video Size Change.
>>
>> Alice and Bob are in a video call in their browsers and have negot= iate a high resolution video. Bob decides to change the size of the windows= his browser is displaying video to a small size. =C2=A0Bob's browser s= hould be able to regenerate the video codec parameters with Alice's bro= wser to change the resolution of video Alice sends to match the smaller siz= e.
>>
>>
>> Changing compression due to a user change in window size is usuall= y not done since it has a bad long term effect on video quality. In almost = all the major video calling systems, video resolution is a function of curr= ent bandwidth (which changes as the rate control system detects differences= ) and/or constrained by the physical device, but not a function of a user d= ragging the window size. At an equivalent bitrate, it is better to compress= a larger resolution and display it smaller (higher PSNR), then compress a = smaller resolution if you are within the codec's effective bitrate for = that larger resolution.

Consider two different video flows using the same codec ...

Stream A is 640 x 480 at 1mbps which is this scaled to 320x240 and displaye= d

Stream B is 320 x 240 at 1mbps which is displayed at 320x240.

My experience has been with modern video codecs that stream B will look bet= ter than stream A. As well as looking better, it will typically also have a= better PSNR. There's a bunch of reasons why which are probably not wor= th going into here but give it a try and you will see what I mean. The key = point is both streams where 1mbps. If stream B was sent at 256 kbps, then A= would look better.




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

--0015177407d05d3b9404a644ff1f-- From Bert.Greevenbosch@huawei.com Tue Jun 21 22:57:17 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264FA21F853E for ; Tue, 21 Jun 2011 22:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aur0AnmryNy for ; Tue, 21 Jun 2011 22:57:16 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id C99B921F853D for ; Tue, 21 Jun 2011 22:57:15 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN600HFGGH6PG@szxga03-in.huawei.com> for rtcweb@ietf.org; Wed, 22 Jun 2011 13:55:54 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN600NSMGH62K@szxga03-in.huawei.com> for rtcweb@ietf.org; Wed, 22 Jun 2011 13:55:54 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ABZ58700; Wed, 22 Jun 2011 13:55:54 +0800 (CST) Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 22 Jun 2011 13:55:48 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.140]) by szxeml407-hub.china.huawei.com ([169.254.34.53]) with mapi id 14.01.0270.001; Wed, 22 Jun 2011 13:55:53 +0800 Date: Wed, 22 Jun 2011 05:55:52 +0000 From: Bert Greevenbosch In-reply-to: X-Originating-IP: [10.70.109.57] To: Justin Uberti Message-id: <46A1DF3F04371240B504290A071B4DB601301A8D@SZXEML501-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_HLujjynSqZ8FOvu42JXk9w)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: [rtcweb] Changing video size (Re: use case:) Thread-index: AQHMMJDVCKk8354El0yZhe0D7WlXTJTI3I3Q X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> <4DFF052A.8020202@alvestrand.no> <01A17A75-0700-416E-A4D4-C6EB97265F8B@cisco.com> <46A1DF3F04371240B504290A071B4DB601301A2E@SZXEML501-MBS.china.huawei.com> Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Changing video size (Re: use case:) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 05:57:17 -0000 --Boundary_(ID_HLujjynSqZ8FOvu42JXk9w) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Hi Justin, all, Yes, that is a second issue. Even if the receiving end can signal its current display size, the streaming source might not be able to provide it. Therefore flexibility would be needed for the source on how to handle the display size information. Best regards, Bert From: Justin Uberti [mailto:juberti@google.com] Sent: 22 June 2011 11:59 To: Bert Greevenbosch Cc: Cullen Jennings; Aron Rosenberg; rtcweb@ietf.org Subject: Re: [rtcweb] Changing video size (Re: use case:) Given the fact that this request for a video size change is an optimization (either of resources or user experience), I think that SHOULD is probably the strongest label we can put on it. Consider the case of a middlebox; if it has no capacity to scale the stream, due to compute or codec restrictions, there's not much it can do with this request. However, whether we can cater for this also depends on the actual technical solution for negotiation and which codec to use. If adding video size negotiation will not increase complexity too much, I see no reason not to do it. However, if it adds much complexity to the solution, we might need to consider whether it is worth it. Therefore, maybe it should not be a requirement, but something weaker; i.e. it could be phrased as a SHOULD rather than a MUST. Best regards, Bert -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: 22 June 2011 00:11 To: Aron Rosenberg Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Changing video size (Re: use case:) On Jun 20, 2011, at 1:30 , Harald Alvestrand wrote: > On 06/17/11 21:38, Aron Rosenberg wrote: >> On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings > wrote: >> >> Video Size Change. >> >> Alice and Bob are in a video call in their browsers and have negotiate a high resolution video. Bob decides to change the size of the windows his browser is displaying video to a small size. Bob's browser should be able to regenerate the video codec parameters with Alice's browser to change the resolution of video Alice sends to match the smaller size. >> >> >> Changing compression due to a user change in window size is usually not done since it has a bad long term effect on video quality. In almost all the major video calling systems, video resolution is a function of current bandwidth (which changes as the rate control system detects differences) and/or constrained by the physical device, but not a function of a user dragging the window size. At an equivalent bitrate, it is better to compress a larger resolution and display it smaller (higher PSNR), then compress a smaller resolution if you are within the codec's effective bitrate for that larger resolution. Consider two different video flows using the same codec ... Stream A is 640 x 480 at 1mbps which is this scaled to 320x240 and displayed Stream B is 320 x 240 at 1mbps which is displayed at 320x240. My experience has been with modern video codecs that stream B will look better than stream A. As well as looking better, it will typically also have a better PSNR. There's a bunch of reasons why which are probably not worth going into here but give it a try and you will see what I mean. The key point is both streams where 1mbps. If stream B was sent at 256 kbps, then A would look better. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --Boundary_(ID_HLujjynSqZ8FOvu42JXk9w) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KIC8qIFN0eWxl IERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6 U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IlNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkhp IEp1c3RpbiwgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPlllcywgdGhhdCBpcyBhIHNlY29uZCBpc3N1ZS4g RXZlbiBpZiB0aGUgcmVjZWl2aW5nIGVuZCBjYW4gc2lnbmFsIGl0cyBjdXJyZW50IGRpc3BsYXkg c2l6ZSwgdGhlIHN0cmVhbWluZyBzb3VyY2UgbWlnaHQgbm90IGJlIGFibGUgdG8gcHJvdmlkZSBp dC4gVGhlcmVmb3JlDQogZmxleGliaWxpdHkgd291bGQgYmUgbmVlZGVkIGZvciB0aGUgc291cmNl IG9uIGhvdyB0byBoYW5kbGUgdGhlIGRpc3BsYXkgc2l6ZSBpbmZvcm1hdGlvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0 OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+QmVydDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBn b29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDIyIEp1bmUgMjAxMSAxMTo1OTxicj4NCjxi PlRvOjwvYj4gQmVydCBHcmVldmVuYm9zY2g8YnI+DQo8Yj5DYzo8L2I+IEN1bGxlbiBKZW5uaW5n czsgQXJvbiBSb3NlbmJlcmc7IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3J0Y3dlYl0gQ2hhbmdpbmcgdmlkZW8gc2l6ZSAoUmU6IHVzZSBjYXNlOik8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HaXZlbiB0aGUgZmFj dCB0aGF0IHRoaXMgcmVxdWVzdCBmb3IgYSB2aWRlbyBzaXplIGNoYW5nZSBpcyBhbiBvcHRpbWl6 YXRpb24gKGVpdGhlciBvZiByZXNvdXJjZXMgb3IgdXNlciBleHBlcmllbmNlKSwgSSB0aGluayB0 aGF0IFNIT1VMRCBpcyBwcm9iYWJseSB0aGUgc3Ryb25nZXN0IGxhYmVsIHdlIGNhbiBwdXQgb24g aXQuIENvbnNpZGVyIHRoZSBjYXNlIG9mIGEgbWlkZGxlYm94OyBpZiBpdCBoYXMgbm8gY2FwYWNp dHkNCiB0byBzY2FsZSB0aGUgc3RyZWFtLCBkdWUgdG8gY29tcHV0ZSBvciBjb2RlYyByZXN0cmlj dGlvbnMsIHRoZXJlJ3Mgbm90IG11Y2ggaXQgY2FuIGRvIHdpdGggdGhpcyByZXF1ZXN0LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7DQpt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCkhvd2V2ZXIsIHdoZXRoZXIgd2UgY2FuIGNhdGVyIGZvciB0aGlzIGFsc28gZGVwZW5k cyBvbiB0aGUgYWN0dWFsIHRlY2huaWNhbCBzb2x1dGlvbiBmb3IgbmVnb3RpYXRpb24gYW5kIHdo aWNoIGNvZGVjIHRvIHVzZS4gSWYgYWRkaW5nIHZpZGVvIHNpemUgbmVnb3RpYXRpb24gd2lsbCBu b3QgaW5jcmVhc2UgY29tcGxleGl0eSB0b28gbXVjaCwgSSBzZWUgbm8gcmVhc29uIG5vdCB0byBk byBpdC4gSG93ZXZlciwgaWYgaXQgYWRkcyBtdWNoIGNvbXBsZXhpdHkNCiB0byB0aGUgc29sdXRp b24sIHdlIG1pZ2h0IG5lZWQgdG8gY29uc2lkZXIgd2hldGhlciBpdCBpcyB3b3J0aCBpdC4gVGhl cmVmb3JlLCBtYXliZSBpdCBzaG91bGQgbm90IGJlIGEgcmVxdWlyZW1lbnQsIGJ1dCBzb21ldGhp bmcgd2Vha2VyOyBpLmUuIGl0IGNvdWxkIGJlIHBocmFzZWQgYXMgYSBTSE9VTEQgcmF0aGVyIHRo YW4gYSBNVVNULjxicj4NCjxicj4NCkJlc3QgcmVnYXJkcyw8YnI+DQo8c3BhbiBzdHlsZT0iY29s b3I6Izg4ODg4OCI+QmVydDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZy b206IDxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZyI+cnRjd2ViLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnIj5ydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBDdWxsZW4g SmVubmluZ3M8YnI+DQpTZW50OiAyMiBKdW5lIDIwMTEgMDA6MTE8YnI+DQpUbzogQXJvbiBSb3Nl bmJlcmc8YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGll dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlN1YmplY3Q6IFJlOiBbcnRjd2ViXSBDaGFuZ2luZyB2aWRlbyBzaXplIChS ZTogdXNlIGNhc2U6KTxicj4NCjxicj4NCjxicj4NCk9uIEp1biAyMCwgMjAxMSwgYXQgMTozMCAs IEhhcmFsZCBBbHZlc3RyYW5kIHdyb3RlOjxicj4NCjxicj4NCiZndDsgT24gMDYvMTcvMTEgMjE6 MzgsIEFyb24gUm9zZW5iZXJnIHdyb3RlOjxicj4NCiZndDsmZ3Q7IE9uIEZyaSwgSnVuIDE3LCAy MDExIGF0IDExOjA5IEFNLCBDdWxsZW4gSmVubmluZ3MgJmx0OzxhIGhyZWY9Im1haWx0bzpmbHVm ZnlAY2lzY28uY29tIj5mbHVmZnlAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBWaWRlbyBTaXplIENoYW5nZS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IEFsaWNlIGFuZCBCb2IgYXJlIGluIGEgdmlkZW8gY2FsbCBpbiB0aGVpciBicm93c2Vy cyBhbmQgaGF2ZSBuZWdvdGlhdGUgYSBoaWdoIHJlc29sdXRpb24gdmlkZW8uIEJvYiBkZWNpZGVz IHRvIGNoYW5nZSB0aGUgc2l6ZSBvZiB0aGUgd2luZG93cyBoaXMgYnJvd3NlciBpcyBkaXNwbGF5 aW5nIHZpZGVvIHRvIGEgc21hbGwgc2l6ZS4gJm5ic3A7Qm9iJ3MgYnJvd3NlciBzaG91bGQgYmUg YWJsZSB0byByZWdlbmVyYXRlIHRoZSB2aWRlbyBjb2RlYyBwYXJhbWV0ZXJzDQogd2l0aCBBbGlj ZSdzIGJyb3dzZXIgdG8gY2hhbmdlIHRoZSByZXNvbHV0aW9uIG9mIHZpZGVvIEFsaWNlIHNlbmRz IHRvIG1hdGNoIHRoZSBzbWFsbGVyIHNpemUuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IENoYW5naW5nIGNvbXByZXNzaW9uIGR1ZSB0byBhIHVzZXIgY2hhbmdlIGlu IHdpbmRvdyBzaXplIGlzIHVzdWFsbHkgbm90IGRvbmUgc2luY2UgaXQgaGFzIGEgYmFkIGxvbmcg dGVybSBlZmZlY3Qgb24gdmlkZW8gcXVhbGl0eS4gSW4gYWxtb3N0IGFsbCB0aGUgbWFqb3Igdmlk ZW8gY2FsbGluZyBzeXN0ZW1zLCB2aWRlbyByZXNvbHV0aW9uIGlzIGEgZnVuY3Rpb24gb2YgY3Vy cmVudCBiYW5kd2lkdGggKHdoaWNoIGNoYW5nZXMgYXMgdGhlIHJhdGUNCiBjb250cm9sIHN5c3Rl bSBkZXRlY3RzIGRpZmZlcmVuY2VzKSBhbmQvb3IgY29uc3RyYWluZWQgYnkgdGhlIHBoeXNpY2Fs IGRldmljZSwgYnV0IG5vdCBhIGZ1bmN0aW9uIG9mIGEgdXNlciBkcmFnZ2luZyB0aGUgd2luZG93 IHNpemUuIEF0IGFuIGVxdWl2YWxlbnQgYml0cmF0ZSwgaXQgaXMgYmV0dGVyIHRvIGNvbXByZXNz IGEgbGFyZ2VyIHJlc29sdXRpb24gYW5kIGRpc3BsYXkgaXQgc21hbGxlciAoaGlnaGVyIFBTTlIp LCB0aGVuIGNvbXByZXNzDQogYSBzbWFsbGVyIHJlc29sdXRpb24gaWYgeW91IGFyZSB3aXRoaW4g dGhlIGNvZGVjJ3MgZWZmZWN0aXZlIGJpdHJhdGUgZm9yIHRoYXQgbGFyZ2VyIHJlc29sdXRpb24u PGJyPg0KPGJyPg0KQ29uc2lkZXIgdHdvIGRpZmZlcmVudCB2aWRlbyBmbG93cyB1c2luZyB0aGUg c2FtZSBjb2RlYyAuLi48YnI+DQo8YnI+DQpTdHJlYW0gQSBpcyA2NDAgeCA0ODAgYXQgMW1icHMg d2hpY2ggaXMgdGhpcyBzY2FsZWQgdG8gMzIweDI0MCBhbmQgZGlzcGxheWVkPGJyPg0KPGJyPg0K U3RyZWFtIEIgaXMgMzIwIHggMjQwIGF0IDFtYnBzIHdoaWNoIGlzIGRpc3BsYXllZCBhdCAzMjB4 MjQwLjxicj4NCjxicj4NCk15IGV4cGVyaWVuY2UgaGFzIGJlZW4gd2l0aCBtb2Rlcm4gdmlkZW8g Y29kZWNzIHRoYXQgc3RyZWFtIEIgd2lsbCBsb29rIGJldHRlciB0aGFuIHN0cmVhbSBBLiBBcyB3 ZWxsIGFzIGxvb2tpbmcgYmV0dGVyLCBpdCB3aWxsIHR5cGljYWxseSBhbHNvIGhhdmUgYSBiZXR0 ZXIgUFNOUi4gVGhlcmUncyBhIGJ1bmNoIG9mIHJlYXNvbnMgd2h5IHdoaWNoIGFyZSBwcm9iYWJs eSBub3Qgd29ydGggZ29pbmcgaW50byBoZXJlIGJ1dCBnaXZlIGl0IGEgdHJ5DQogYW5kIHlvdSB3 aWxsIHNlZSB3aGF0IEkgbWVhbi4gVGhlIGtleSBwb2ludCBpcyBib3RoIHN0cmVhbXMgd2hlcmUg MW1icHMuIElmIHN0cmVhbSBCIHdhcyBzZW50IGF0IDI1NiBrYnBzLCB0aGVuIEEgd291bGQgbG9v ayBiZXR0ZXIuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2Vi IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dGN3ZWI8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dl YkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --Boundary_(ID_HLujjynSqZ8FOvu42JXk9w)-- From stefan.lk.hakansson@ericsson.com Tue Jun 21 23:06:34 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681FD21F8585 for ; Tue, 21 Jun 2011 23:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rARAimbenQJE for ; Tue, 21 Jun 2011 23:06:33 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C598221F857E for ; Tue, 21 Jun 2011 23:06:32 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-4c-4e0186679c9f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2E.4C.20773.766810E4; Wed, 22 Jun 2011 08:06:31 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.208]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 22 Jun 2011 08:06:31 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Bert Greevenbosch , Justin Uberti , "rtcweb@ietf.org" Date: Wed, 22 Jun 2011 08:06:28 +0200 Thread-Topic: [rtcweb] Changing video size (Re: use case:) Thread-Index: AQHMMJDVCKk8354El0yZhe0D7WlXTJTI3I3QgAAF1PA= Message-ID: References: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> <4DFF052A.8020202@alvestrand.no> <01A17A75-0700-416E-A4D4-C6EB97265F8B@cisco.com> <46A1DF3F04371240B504290A071B4DB601301A2E@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB601301A8D@SZXEML501-MBS.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB601301A8D@SZXEML501-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BBF498F2D030E84AB1179E24D1AC41D6147C4DA4CEESESSCMS0362e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Changing video size (Re: use case:) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 06:06:34 -0000 --_000_BBF498F2D030E84AB1179E24D1AC41D6147C4DA4CEESESSCMS0362e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, this RFC could perhaps be useful for this purpose of signaling display size= : http://www.rfc-editor.org/rfc/rfc6236.txt Stefan ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Bert Greevenbosch Sent: den 22 juni 2011 07:56 To: Justin Uberti Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Changing video size (Re: use case:) Hi Justin, all, Yes, that is a second issue. Even if the receiving end can signal its curre= nt display size, the streaming source might not be able to provide it. Ther= efore flexibility would be needed for the source on how to handle the displ= ay size information. Best regards, Bert From: Justin Uberti [mailto:juberti@google.com] Sent: 22 June 2011 11:59 To: Bert Greevenbosch Cc: Cullen Jennings; Aron Rosenberg; rtcweb@ietf.org Subject: Re: [rtcweb] Changing video size (Re: use case:) Given the fact that this request for a video size change is an optimization= (either of resources or user experience), I think that SHOULD is probably = the strongest label we can put on it. Consider the case of a middlebox; if = it has no capacity to scale the stream, due to compute or codec restriction= s, there's not much it can do with this request. However, whether we can cater for this also depends on the actual technical= solution for negotiation and which codec to use. If adding video size nego= tiation will not increase complexity too much, I see no reason not to do it= . However, if it adds much complexity to the solution, we might need to con= sider whether it is worth it. Therefore, maybe it should not be a requireme= nt, but something weaker; i.e. it could be phrased as a SHOULD rather than = a MUST. Best regards, Bert -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Cullen Jen= nings Sent: 22 June 2011 00:11 To: Aron Rosenberg Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Changing video size (Re: use case:) On Jun 20, 2011, at 1:30 , Harald Alvestrand wrote: > On 06/17/11 21:38, Aron Rosenberg wrote: >> On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings > wrote: >> >> Video Size Change. >> >> Alice and Bob are in a video call in their browsers and have negotiate a= high resolution video. Bob decides to change the size of the windows his b= rowser is displaying video to a small size. Bob's browser should be able t= o regenerate the video codec parameters with Alice's browser to change the = resolution of video Alice sends to match the smaller size. >> >> >> Changing compression due to a user change in window size is usually not = done since it has a bad long term effect on video quality. In almost all th= e major video calling systems, video resolution is a function of current ba= ndwidth (which changes as the rate control system detects differences) and/= or constrained by the physical device, but not a function of a user draggin= g the window size. At an equivalent bitrate, it is better to compress a lar= ger resolution and display it smaller (higher PSNR), then compress a smalle= r resolution if you are within the codec's effective bitrate for that large= r resolution. Consider two different video flows using the same codec ... Stream A is 640 x 480 at 1mbps which is this scaled to 320x240 and displaye= d Stream B is 320 x 240 at 1mbps which is displayed at 320x240. My experience has been with modern video codecs that stream B will look bet= ter than stream A. As well as looking better, it will typically also have a= better PSNR. There's a bunch of reasons why which are probably not worth g= oing into here but give it a try and you will see what I mean. The key poin= t is both streams where 1mbps. If stream B was sent at 256 kbps, then A wou= ld look better. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_BBF498F2D030E84AB1179E24D1AC41D6147C4DA4CEESESSCMS0362e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
All,
 
this RFC could perhaps be useful for this purpose = of=20 signaling display size: http://www.rfc-editor.or= g/rfc/rfc6236.txt
 
Stefan

From: rtcweb-bounces@ietf.org=20 [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bert=20 Greevenbosch
Sent: den 22 juni 2011 07:56
To: Justin= =20 Uberti
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Chan= ging=20 video size (Re: use case:)

Hi=20 Justin, all,

 

Yes,=20 that is a second issue. Even if the receiving end can signal its current= =20 display size, the streaming source might not be able to provide it. There= fore=20 flexibility would be needed for the source on how to handle the display s= ize=20 information.

 

Best=20 regards,

Bert

 

 

From:


However, whether we can cater for this also de= pends=20 on the actual technical solution for negotiation and which codec to use= . If=20 adding video size negotiation will not increase complexity too much, I = see=20 no reason not to do it. However, if it adds much complexity to the solu= tion,=20 we might need to consider whether it is worth it. Therefore, maybe it s= hould=20 not be a requirement, but something weaker; i.e. it could be phrased as= a=20 SHOULD rather than a MUST.

Best regards,
Bert



-----Original Message-----
From: rtcweb-bounces@ietf.org [ma= ilto:rtcweb-bounces@ietf.org] On= Behalf=20 Of Cullen Jennings
Sent: 22 June 2011 00:11
To: Aron RosenbergCc:=20 rtcweb@ietf.org

Subject: Re: [rtcweb] Changing video size (Re: use= =20 case:)


On Jun 20, 2011, at 1:30 , Harald Alvestrand=20 wrote:

> On 06/17/11 21:38, Aron Rosenberg wrote:
>>= On=20 Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings <fluffy@cisco.com>=20 wrote:
>>
>> Video Size Change.
>>
>&g= t;=20 Alice and Bob are in a video call in their browsers and have negotiate = a=20 high resolution video. Bob decides to change the size of the windows hi= s=20 browser is displaying video to a small size.  Bob's browser should= be=20 able to regenerate the video codec parameters with Alice's browser to c= hange=20 the resolution of video Alice sends to match the smaller=20 size.
>>
>>
>> Changing compression due to a= user=20 change in window size is usually not done since it has a bad long term= =20 effect on video quality. In almost all the major video calling systems,= =20 video resolution is a function of current bandwidth (which changes as t= he=20 rate control system detects differences) and/or constrained by the phys= ical=20 device, but not a function of a user dragging the window size. At an=20 equivalent bitrate, it is better to compress a larger resolution and di= splay=20 it smaller (higher PSNR), then compress a smaller resolution if you are= =20 within the codec's effective bitrate for that larger=20 resolution.

Consider two different video flows using the same co= dec=20 ...

Stream A is 640 x 480 at 1mbps which is this scaled to 320x2= 40=20 and displayed

Stream B is 320 x 240 at 1mbps which is displayed = at=20 320x240.

My experience has been with modern video codecs that st= ream=20 B will look better than stream A. As well as looking better, it will=20 typically also have a better PSNR. There's a bunch of reasons why which= are=20 probably not worth going into here but give it a try and you will see w= hat I=20 mean. The key point is both streams where 1mbps. If stream B was sent a= t 256=20 kbps, then A would look=20 better.




____________________________________________= ___
rtcweb=20 mailing list
rtcweb@ietf.org<= BR>https://www.ietf.org/mailman/listinfo/rtcweb
___= ____________________________________________
rtcweb=20 mailing list
rtcweb@ietf.org<= BR>https://www.ietf.org/mailman/listinfo/rtcweb

 

--_000_BBF498F2D030E84AB1179E24D1AC41D6147C4DA4CEESESSCMS0362e_-- From magnus.westerlund@ericsson.com Wed Jun 22 00:15:09 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC64811E809B for ; Wed, 22 Jun 2011 00:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8uwSyeF7GpP for ; Wed, 22 Jun 2011 00:15:07 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0108711E8083 for ; Wed, 22 Jun 2011 00:15:06 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f5-4e0196791348 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 50.3A.20773.976910E4; Wed, 22 Jun 2011 09:15:05 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Wed, 22 Jun 2011 09:15:05 +0200 Message-ID: <4E01966D.1090602@ericsson.com> Date: Wed, 22 Jun 2011 09:14:53 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Likepeng References: <4E00B71D.9010502@ericsson.com> <34966E97BE8AD64EAE9D3D6E4DEE36F22B71E5@szxeml506-mbx.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F22B71E5@szxeml506-mbx.china.huawei.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG adoption of Architecture and Overview of RTCWEB document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 07:15:09 -0000 On 2011-06-22 05:49, Likepeng wrote: > I am fine with the proposal, but should the overview draft be > informational, instead of standard track? I think that is an open question. It depends on how this document is written. If it in fact mandates which functionality block that must be implemented it is a standards track. If it becomes written in a more informal way it could be informational. The milestone says: Sep 2011 Architecture and Security, Privacy, and Threat Model document(s) to IESG as Informational Milestones can be changed if the WG feels it has a preference for a standards track document. From my perspective, this is a question we can delay. Cheers Magnus Westerlund WG chair > > Thanks, Kind Regards Kepeng -----Original Message----- From: > rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of > Stephan Wenger Sent: Wednesday, June 22, 2011 12:10 AM To: Magnus > Westerlund; rtcweb@ietf.org Subject: Re: [rtcweb] WG adoption of > Architecture and Overview of RTCWEB document > > Magnus' proposal of picking Harald's draft is fine with me. Stephan > > On 6.21.2011 08:22 , "Magnus Westerlund" > wrote: > >> WG, >> >> We would like to adopt a document that describes the RTCWEB >> architecture and provides an overview to the functionality that >> will be specified in various documents targeted to specific pieces >> of the functionalities we need for a complete solution. >> >> There has been several documents that describes architecture, >> frame works or overviews. None of them are complete when it comes >> to covering the different aspects. The documents are: >> >> https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-overview/ >> https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-framework/ >> https://datatracker.ietf.org/doc/draft-jennings-rtcweb-api/ >> >> The WG chairs' proposal is that we adopt one document and then add >> in aspects that are needed from the other documents. In the process >> putting together an good editor team for the WG document from the >> persons that has contributed so far and want to continue. >> >> The WG chairs propose that that the WG adopts: >> https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-overview/ >> as a WG item to form the core of an Architecture and Overview >> document. >> >> WG participants please provide either support for adoption or >> provide feedback on any issues you see with this approach. >> >> Please provide your view no later than Tuesday the 28th at 17.00 >> CEST. >> >> Magnus Westerlund WG Chair >> >> ---------------------------------------------------------------------- >> >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 SE-164 80 >> Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- > >> -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From huilan.lu@alcatel-lucent.com Wed Jun 22 07:25:39 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD6011E8108 for ; Wed, 22 Jun 2011 07:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GfTB0D6X7-8 for ; Wed, 22 Jun 2011 07:25:38 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id F2AA711E80BA for ; Wed, 22 Jun 2011 07:25:37 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p5MEPVNY022914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Jun 2011 09:25:32 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5MEPVoI025069 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 Jun 2011 09:25:31 -0500 Received: from USNAVSXCHMBSB3.ndc.alcatel-lucent.com ([135.3.39.137]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 22 Jun 2011 09:25:31 -0500 From: "Lu, Hui-Lan (Huilan)" To: "'Christer Holmberg'" , Harald Alvestrand , "rtcweb@ietf.org" Date: Wed, 22 Jun 2011 09:25:30 -0500 Thread-Topic: [rtcweb] Use-case grouping Thread-Index: AcwwKBkpm2xc+n+GQ1Gb7cU29D+/KgADg67bACwFU3A= Message-ID: <0E96A74B7DFCF844A9BE2A0BBE2C425F058E625BB2@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336E53@ESESSCMS0356.eemea.ericsson.se>, <4E00B8F8.4050306@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29A@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [rtcweb] Use-case grouping X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 14:25:39 -0000 "Point-to-point" seems more flexible. Such a group would allow us to addres= s use cases invovling devices (such as IP phones or mobile phones) which do= n't have a browser. Huilan=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Tuesday, June 21, 2011 1:11 PM > To: Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] Use-case grouping >=20 > Hi Harald, >=20 > We could add a "Point-to-point", or "Browser-to-browser",=20 > use-case group. >=20 > Regards, >=20 > Christer >=20 > ________________________________ > From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On=20 > Behalf Of Harald Alvestrand [harald@alvestrand.no] > Sent: Tuesday, June 21, 2011 6:30 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Use-case grouping >=20 > Seems to me sensible to have groupings. >=20 > The use case I don't see a place for at the moment is the=20 > single point-to-point call; the proposed use case I don't see=20 > mentioned below is my suggestion for "interoperable calling". >=20 > So this might require more tuning. >=20 > On 06/21/11 14:39, Christer Holmberg wrote: >=20 > Hi, >=20 > It's nice to see the amount of use-cases people have submitted :) >=20 >=20 > Now, since many of the use-cases are related to each other,=20 > and in order to get a better and easy-to-read structure of=20 > the document, I would like to suggest to devide the use-cases=20 > into different "use-case groups". >=20 > Below is a proposed grouping, and examples of use-cases which=20 > would be listed in each group. I have only used the existing=20 > use-cases, and the ones suggested by Cullen, but I am aware=20 > that more use-cases have been proposed :) >=20 >=20 > Telephony use-cases: >=20 > - Telephony terminal use-case (draft) > - Call fedex use-case (Cullen) >=20 >=20 > Video conferenceing use-cases: >=20 > - With central server (draft) > - Without central server (draft) > - Hockey (draft) > - Screen re-size (Cullen) >=20 >=20 > Embedded voice communicatoin use-case: >=20 > - Multiparty on-line game with voice communication (draft) >=20 >=20 > Bandwidth/QoS/mobility use-cases: >=20 > - NIC Change (Cullen) > - QoS Marking (Cullen) >=20 >=20 >=20 > Later, we can of course modify/add/remove groups, but I think=20 > the grouping above would be a good start, and I think all the=20 > use-cases so far proposed would fit into one of those groups. >=20 > Comments? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From csp@csperkins.org Wed Jun 22 07:46:00 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA7E21F852C for ; Wed, 22 Jun 2011 07:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.516 X-Spam-Level: X-Spam-Status: No, score=-103.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RX5fnrAGgor for ; Wed, 22 Jun 2011 07:45:57 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 89EFC21F852B for ; Wed, 22 Jun 2011 07:45:57 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QZOgm-0004dY-hY; Wed, 22 Jun 2011 14:45:56 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4E00B71D.9010502@ericsson.com> Date: Wed, 22 Jun 2011 15:45:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1B53D4FE-2F32-41DB-92B9-8B5F00D4D89F@csperkins.org> References: <4E00B71D.9010502@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG adoption of Architecture and Overview of RTCWEB document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 14:46:00 -0000 This seems reasonable to me. Colin On 21 Jun 2011, at 16:22, Magnus Westerlund wrote: > WG, >=20 > We would like to adopt a document that describes the RTCWEB = architecture > and provides an overview to the functionality that will be specified = in > various documents targeted to specific pieces of the functionalities = we > need for a complete solution. >=20 > There has been several documents that describes architecture, frame > works or overviews. None of them are complete when it comes to = covering > the different aspects. The documents are: >=20 > https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-overview/ > https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-framework/ > https://datatracker.ietf.org/doc/draft-jennings-rtcweb-api/ >=20 > The WG chairs' proposal is that we adopt one document and then add in > aspects that are needed from the other documents. In the process = putting > together an good editor team for the WG document from the persons that > has contributed so far and want to continue. >=20 > The WG chairs propose that that the WG adopts: > https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-overview/ > as a WG item to form the core of an Architecture and Overview = document. >=20 > WG participants please provide either support for adoption or provide > feedback on any issues you see with this approach. >=20 > Please provide your view no later than Tuesday the 28th at 17.00 CEST. >=20 > Magnus Westerlund > WG Chair >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From fluffy@cisco.com Fri Jun 24 07:27:29 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672B022801E for ; Fri, 24 Jun 2011 07:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.041 X-Spam-Level: X-Spam-Status: No, score=-110.041 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruogz2ZCmRFG for ; Fri, 24 Jun 2011 07:27:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 49F9211E80DE for ; Fri, 24 Jun 2011 07:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=368; q=dns/txt; s=iport; t=1308925644; x=1310135244; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=u/5l+F8CdGSepOLi0KZftMCdiLnG84jp91y+ttlIKPc=; b=RhWOQTAt9Kziw0eLakjyeTBnhX4RYkt2O/wQWbCNoHUgjUkXD87uvfe3 sLX6nZIttCY4jMbi3aMYyHZfrdluivaA/GLOSzIEmUAdxmHdGiehxPFqf zrwY99/d9MrNiN1N+RDj1FElaQlcfvpkQhiaA0ZK8IGl+bYnCPR/BeF66 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0OAFeeBE6rRDoJ/2dsb2JhbABSLZgnjmJ3iHOjZJ4Rhi0EhymKUoRoi0o X-IronPort-AV: E=Sophos;i="4.65,419,1304294400"; d="scan'208";a="721676747" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 24 Jun 2011 14:27:03 +0000 Received: from [192.168.4.101] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5OER0KE011402 for ; Fri, 24 Jun 2011 14:27:02 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 23 Jun 2011 21:19:13 -0700 References: <20110623232705.1681D11E817B@ietfa.amsl.com> To: rtcweb@ietf.org Message-Id: <6FEBD0E6-08C9-48AB-8873-219727742E9D@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] RTCWEB - Requested sessions have been scheduled for IETF 81 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 14:27:29 -0000 Tentative times for meetings at IETF 81. Begin forwarded message: > RTCWEB Session 1 (2 hours) > Tuesday, Afternoon Session I 1300-1500 > Room Name: 205 ABC > ---------------------------------------------- > RTCWEB Session 2 (2 hours) > Thursday, Afternoon Session I 1300-1500 > Room Name: 205 ABC > ---------------------------------------------- > From magnus.westerlund@ericsson.com Sat Jun 25 07:51:19 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789CD11E807B for ; Sat, 25 Jun 2011 07:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUMPh8+p6SQE for ; Sat, 25 Jun 2011 07:51:18 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9741411E8070 for ; Sat, 25 Jun 2011 07:51:18 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-8c-4e05f5e539fe Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F9.D8.20773.5E5F50E4; Sat, 25 Jun 2011 16:51:17 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Sat, 25 Jun 2011 16:50:06 +0200 Message-ID: <4E05F59D.90703@ericsson.com> Date: Sat, 25 Jun 2011 16:50:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: References: <4DFB09AC.1090001@ericsson.com> In-Reply-To: <4DFB09AC.1090001@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: =?ISO-8859-1?Q?=22G=F6ran_Eriksson?= =?ISO-8859-1?Q?_AP_=28KI/EAB=29=22?= Subject: Re: [rtcweb] WG adoption for Use Case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 14:51:19 -0000 WG, I have reviewed the input from the WG participants, and there has all been in support for adopting this document as WG item. So hereby I declare https://datatracker.ietf.org/doc/draft-holmberg-rtcweb-ucreqs/ a WG document. At this point the WG chairs request no changes in the document editor team. In addition there has been input on how to improve the document which we request the editors to take into account. Editors, please submit the document as draft-ietf-rtcweb-use-cases-and-requirements-00.txt. Cheers Magnus Westerlund WG chair On 2011-06-17 10:00, Magnus Westerlund wrote: > WG, > > We would like to adopt a WG document with the purpose for describing use > cases for the RTCWEB work. This document would be targeted as > publication as an Inforamtional RFC eventually. > > The candidate document for this is: > Web Real-Time Communication Use-cases and Requirements > https://datatracker.ietf.org/doc/draft-holmberg-rtcweb-ucreqs/ > > Based on our interim last week it was clear that there are some use > cases that clearly needs development. However, the WG chairs believe > that future development of the document can be done as WG item. > > WG participants please indicate if you agree in adopting this document > as a basis, or if not, what the short comings you would like to see > addressed prior to adoption. Once more, the document will be continued > to be developed under the WG control and this is far from any final > version. > > Please provide your view no later than Friday the 24th. > > Best Regards > > Magnus Westerlund > WG chair > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Jun 27 00:36:36 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B6011E8086 for ; Mon, 27 Jun 2011 00:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGzseyRGB3PA for ; Mon, 27 Jun 2011 00:36:35 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2956411E8081 for ; Mon, 27 Jun 2011 00:36:35 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-96-4e083301fe87 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AA.D7.09774.103380E4; Mon, 27 Jun 2011 09:36:33 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 27 Jun 2011 09:36:33 +0200 Message-ID: <4E0832FE.7010401@ericsson.com> Date: Mon, 27 Jun 2011 09:36:30 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 07:36:36 -0000 WG, At the interim it was planned to have a bit discussion on the datagram service for RTCWEB. The first question to try to resolve if there is consensus for including some form of non real-time media (i.e. not audio, video) service between peers. This is a bit tangled with the actual requirements and use cases. But there was views both for it and against it on the mailing list. So lets continue and try to come to a conclusion on this discussion. The use cases mentioned on the mailing list are: - Dynamic meta data for Conference and other real-time services - Gaming data with low latency requirements Does anyone like to add additional use cases? Based on my personal understanding this points to primarily have the RTCWEB provide a unreliable datagram service. This clearly needs additional requirements to be secure and safe to deploy, but more about this below. I still like to ask the WG here a question. Are you supporting the inclusion of a unreliable datagram service directly between peers? Please provide your view and any additional statements of motivation that you desire to provide. Secondly, there is a question if there needs to have something that provides reliable message (of arbitrary size) or byte stream oriented data transport between the peers. I personally foresee that people will build JS libraries for this on top of a unreliable datagram service. If you desire reliable data service as part of the standardized solution please provide motivation and use case and requirements. I also want to take a stab on what I personally see as the requirements that exist on unreliable datagram service in the context of RTCWEB. - Unreliable data transmission - Datagram oriented * Size limited by MTU - Path MTU discovery needed * Fragmentation by the application - Low latency, i.e. Peer to Peer preferable - Congestion Controlled, to be * Network friendly * Not become a Denial of Service tool - Security * Confidentiality * Integrity Protected * Source Authenticated (at least bound to the signalling peer) * Ensure consent to receive data Please debate the above. This is an attempt to ensure that we can establish WG consensus on both data service and any requirements. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Mon Jun 27 02:37:57 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22F121F8679; Mon, 27 Jun 2011 02:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwnDmma-6DZW; Mon, 27 Jun 2011 02:37:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6979F21F8611; Mon, 27 Jun 2011 02:37:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110627093757.9043.40149.idtracker@ietfa.amsl.com> Date: Mon, 27 Jun 2011 02:37:57 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 09:37:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : Web Real-Time Communication Use-cases and Requirements Author(s) : Christer Holmberg Stefan Hakansson Goran AP Eriksson Filename : draft-ietf-rtcweb-use-cases-and-requirements-00.txt Pages : 15 Date : 2011-06-27 This document describes web based real-time communication use-cases. Based on the use-cases, the document also derives requirements related to the browser, and the API used by web applications to request and control media stream services provided by the browser. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-require= ments-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-requirem= ents-00.txt From emil@sip-communicator.org Mon Jun 27 07:26:14 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B528E21F8603 for ; Mon, 27 Jun 2011 07:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tg1D5GakEx+U for ; Mon, 27 Jun 2011 07:26:13 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6442221F8595 for ; Mon, 27 Jun 2011 07:26:13 -0700 (PDT) Received: by wwe5 with SMTP id 5so3194452wwe.13 for ; Mon, 27 Jun 2011 07:26:12 -0700 (PDT) Received: by 10.216.60.203 with SMTP id u53mr923472wec.96.1309178059734; Mon, 27 Jun 2011 05:34:19 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id h43sm2742217wes.35.2011.06.27.05.34.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Jun 2011 05:34:18 -0700 (PDT) Message-ID: <4E0878C8.8000207@jitsi.org> Date: Mon, 27 Jun 2011 14:34:16 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Magnus Westerlund References: <4E0832FE.7010401@ericsson.com> In-Reply-To: <4E0832FE.7010401@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 14:26:14 -0000 =D0=9D=D0=B0 27.06.11 09:36, Magnus Westerlund =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: > WG, >=20 > At the interim it was planned to have a bit discussion on the datagram > service for RTCWEB. The first question to try to resolve if there > is consensus for including some form of non real-time media (i.e. not > audio, video) service between peers. This is a bit tangled with the > actual requirements and use cases. But there was views both for it and > against it on the mailing list. So lets continue and try to come to a > conclusion on this discussion. >=20 > The use cases mentioned on the mailing list are: >=20 > - Dynamic meta data for Conference and other real-time services >=20 > - Gaming data with low latency requirements >=20 > Does anyone like to add additional use cases? - File transfer? Skype, Google Talk, Windows Live, and pretty much any existing service has it so I suppose it is reasonable to assume that people using rtcweb would like to add the feature to their web applicatio= ns. - Transferring input events (e.g. pressed keys and mouse clicks) in desktop sharing applicaitons? > Based on my personal understanding this points to primarily have the > RTCWEB provide a unreliable datagram service. This clearly needs > additional requirements to be secure and safe to deploy, but more about= > this below. I still like to ask the WG here a question. >=20 > Are you supporting the inclusion of a unreliable datagram service > directly between peers? Please provide your view and any additional > statements of motivation that you desire to provide. Yes. Requirements and code necessary to support a generic datagram service would hardly differ from those we have for RTP and it would definitely help a lot in the use cases described above. > Secondly, there is a question if there needs to have something that > provides reliable message (of arbitrary size) or byte stream oriented > data transport between the peers. I personally foresee that people will= > build JS libraries for this on top of a unreliable datagram service. If= > you desire reliable data service as part of the standardized solution > please provide motivation and use case and requirements. I definitely think it would be a great idea for the IETF to specify a datagram based reliable service similar to Google's pseudo TCP. Whether or not this happens in RTCWEB is of course a different matter. As I wrote above many applications are likely to need such a think and I am not sure that the flexibility we'll get by leaving this to JS libs is worth the interoperability nightmare it would imply. Emil >=20 > I also want to take a stab on what I personally see as the requirements= > that exist on unreliable datagram service in the context of RTCWEB. >=20 > - Unreliable data transmission > - Datagram oriented > * Size limited by MTU > - Path MTU discovery needed > * Fragmentation by the application > - Low latency, i.e. Peer to Peer preferable > - Congestion Controlled, to be > * Network friendly > * Not become a Denial of Service tool > - Security > * Confidentiality > * Integrity Protected > * Source Authenticated (at least bound to the signalling peer) > * Ensure consent to receive data >=20 > Please debate the above. This is an attempt to ensure that we can > establish WG consensus on both data service and any requirements. >=20 > cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 http://jitsi.org FAX: +33.1.77.62.47.31 From tedh@ipinfusion.com Mon Jun 27 09:22:19 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9267D11E8118 for ; Mon, 27 Jun 2011 09:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4D2ZGkpm-3f for ; Mon, 27 Jun 2011 09:22:19 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 94BEC11E8111 for ; Mon, 27 Jun 2011 09:22:15 -0700 (PDT) Received: by vxi40 with SMTP id 40so367959vxi.31 for ; Mon, 27 Jun 2011 09:22:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.103 with SMTP id k7mr4699870vdv.210.1309191734462; Mon, 27 Jun 2011 09:22:14 -0700 (PDT) Received: by 10.52.164.166 with HTTP; Mon, 27 Jun 2011 09:22:13 -0700 (PDT) Date: Mon, 27 Jun 2011 09:22:13 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=bcaec501c58c4688ec04a6b3f458 Cc: ted.ietf@gmail.com Subject: [rtcweb] Document split is approved X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 16:22:19 -0000 --bcaec501c58c4688ec04a6b3f458 Content-Type: text/plain; charset=ISO-8859-1 The document split presented seems to have rough consensus, so we will consider it the plan of record for now. As an aside, I seem to be having some trouble with email from the list to my work email, so I will shift back to using ted.ietf@gmail.com for mailing list traffic from now. thanks, Ted --bcaec501c58c4688ec04a6b3f458 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The document split presented seems to have rough consensus, so we will cons= ider it the plan of record for now.

As an aside, I seem = to be having some trouble with email from the list to my work email, so I w= ill shift back to using ted.ietf@gmai= l.com for mailing list traffic from now.

thanks,

Ted
--bcaec501c58c4688ec04a6b3f458-- From bernard_aboba@hotmail.com Mon Jun 27 15:35:18 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBB51F0C49 for ; Mon, 27 Jun 2011 15:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+jjSQbPjM3R for ; Mon, 27 Jun 2011 15:35:14 -0700 (PDT) Received: from blu0-omc3-s18.blu0.hotmail.com (blu0-omc3-s18.blu0.hotmail.com [65.55.116.93]) by ietfa.amsl.com (Postfix) with ESMTP id C5C611F0C43 for ; Mon, 27 Jun 2011 15:35:10 -0700 (PDT) Received: from BLU152-W31 ([65.55.116.74]) by blu0-omc3-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 15:35:10 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_619c0170-1f0c-4026-ba0e-62b9c45533cd_" X-Originating-IP: [131.107.0.111] From: Bernard Aboba To: Date: Mon, 27 Jun 2011 15:35:10 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jun 2011 22:35:10.0661 (UTC) FILETIME=[7940BF50:01CC351A] Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 22:35:18 -0000 --_619c0170-1f0c-4026-ba0e-62b9c45533cd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I do not support an unreliable datagram service that can be used to send ar= bitrary data. =20 For example=2C it seems dangerous for a Web browser under the control of an= attacker to be able to send RIP=2C SNMP or DNS packets to arbitrary destin= ations.=20 For these transactional exchanges the overhead of ICE would be excessive an= d so there will be a very strong temptation to cut corners.=20 Assuming that the goal is not to send arbitrary data=2C then we need to dig= into the transport requirements more.=20 For example=2C is the non-media data to be synchronized with media (e.g. re= al-time text)? Is there a session associated with the non-media data (e.g. XMPP or MSRP ex= changes)?=20 Is there a reliability requirement?=20 Is it congestion-controlled?=20 How long-lived are the flows?=20 --------------------------------------------------- From: magnus.westerlund@ericsson.com To: rtcweb@ietf.org Date: Mon=2C 27 Jun 2011 09:36:30 +0200 Subject: [rtcweb] Non-media data service consensus and requirements WG=2C =20 At the interim it was planned to have a bit discussion on the datagram service for RTCWEB. The first question to try to resolve if there is consensus for including some form of non real-time media (i.e. not audio=2C video) service between peers. This is a bit tangled with the actual requirements and use cases. But there was views both for it and against it on the mailing list. So lets continue and try to come to a conclusion on this discussion. =20 The use cases mentioned on the mailing list are: =20 - Dynamic meta data for Conference and other real-time services =20 - Gaming data with low latency requirements =20 Does anyone like to add additional use cases? =20 Based on my personal understanding this points to primarily have the RTCWEB provide a unreliable datagram service. This clearly needs additional requirements to be secure and safe to deploy=2C but more about this below. I still like to ask the WG here a question. =20 Are you supporting the inclusion of a unreliable datagram service directly between peers? Please provide your view and any additional statements of motivation that you desire to provide. =20 Secondly=2C there is a question if there needs to have something that provides reliable message (of arbitrary size) or byte stream oriented data transport between the peers. I personally foresee that people will build JS libraries for this on top of a unreliable datagram service. If you desire reliable data service as part of the standardized solution please provide motivation and use case and requirements. =20 I also want to take a stab on what I personally see as the requirements that exist on unreliable datagram service in the context of RTCWEB. =20 - Unreliable data transmission - Datagram oriented * Size limited by MTU - Path MTU discovery needed * Fragmentation by the application - Low latency=2C i.e. Peer to Peer preferable - Congestion Controlled=2C to be * Network friendly * Not become a Denial of Service tool - Security * Confidentiality * Integrity Protected * Source Authenticated (at least bound to the signalling peer) * Ensure consent to receive data =20 Please debate the above. This is an attempt to ensure that we can establish WG consensus on both data service and any requirements. =20 cheers =20 Magnus Westerlund =20 ---------------------------------------------------------------------- Multimedia Technologies=2C Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm=2C Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- = --_619c0170-1f0c-4026-ba0e-62b9c45533cd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I do not support an unreliable datagram service that can be used to send ar= bitrary data. =3B

For example=2C it seems dangerous for a Web b= rowser under the control of an attacker to be able to send RIP=2C SNMP or D= NS packets to arbitrary destinations.

For these transactional excha= nges the overhead of ICE would be excessive and so there will be a very str= ong temptation to cut corners.

Assuming that the goal is not to sen= d arbitrary data=2C then we need to dig into the transport requirements mor= e.

For example=2C is the non-media data to be synchronized with med= ia (e.g. real-time text)?

Is there a session associated with the non= -media data (e.g. XMPP or MSRP exchanges)?

Is there a reliability r= equirement?

Is it congestion-controlled?

How long-lived are= the flows?




-------------------------------------------= --------
From: magnus.westerlund@ericsson.com
To: rtcweb@ietf.org
= Date: Mon=2C 27 Jun 2011 09:36:30 +0200
Subject: [rtcweb] Non-media data= service consensus and requirements

WG=2C
 
At the interi=
m it was planned to have a bit discussion on the datagram
service for RT=
CWEB. The first question to try to resolve if there
is consensus for inc=
luding some form of non real-time media (i.e. not
audio=2C video) servic=
e between peers. This is a bit tangled with the
actual requirements and =
use cases. But there was views both for it and
against it on the mailing=
 list. So lets continue and try to come to a
conclusion on this discussi=
on.
 
The use cases mentioned on the mailing list are:
 
- Dyna=
mic meta data for Conference and other real-time services
 
- Gaming =
data with low latency requirements
 
Does anyone like to add addition=
al use cases?
 
Based on my personal understanding this points to pri=
marily have the
RTCWEB provide a unreliable datagram service. This clear=
ly needs
additional requirements to be secure and safe to deploy=2C but =
more about
this below. I still like to ask the WG here a question.
 <=
br>Are you supporting the inclusion of a unreliable datagram service
dir=
ectly between peers? Please provide your view and any additional
stateme=
nts of motivation that you desire to provide.
 
Secondly=2C there is =
a question if there needs to have something that
provides reliable messa=
ge (of arbitrary size) or byte stream oriented
data transport between th=
e peers. I personally foresee that people will
build JS libraries for th=
is on top of a unreliable datagram service. If
you desire reliable data =
service as part of the standardized solution
please provide motivation a=
nd use case and requirements.
 
I also want to take a stab on what I =
personally see as the requirements
that exist on unreliable datagram ser=
vice in the context of RTCWEB.
 
- Unreliable data transmission
- =
Datagram oriented
   * Size limited by MTU
     - Path MTU discovery =
needed
   * Fragmentation by the application
- Low latency=2C i.e. Pe=
er to Peer preferable
- Congestion Controlled=2C to be
   * Network f=
riendly
   * Not become a Denial of Service tool
- Security
  * Co=
nfidentiality
  * Integrity Protected
  * Source Authenticated (at le=
ast bound to the signalling peer)
  * Ensure consent to receive data
=
 
Please debate the above. This is an attempt to ensure that we can
e=
stablish WG consensus on both data service and any requirements.
 
ch=
eers
 
Magnus Westerlund
 
------------------------------------=
----------------------------------
Multimedia Technologies=2C Ericsson R=
esearch EAB/TVM
--------------------------------------------------------=
--------------
Ericsson AB                | Phone  +46 10 7148287
F=
=E4r=F6gatan 6                | Mobile +46 73 0949079
SE-164 80 Stockhol=
m=2C Sweden| mailto: magnus.westerlund@ericsson.com
--------------------=
--------------------------------------------------

= --_619c0170-1f0c-4026-ba0e-62b9c45533cd_-- From emil@sip-communicator.org Mon Jun 27 15:43:18 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F5C1F0C51 for ; Mon, 27 Jun 2011 15:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnwpBjE7uaMm for ; Mon, 27 Jun 2011 15:43:17 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6504B1F0C49 for ; Mon, 27 Jun 2011 15:43:17 -0700 (PDT) Received: by wwg11 with SMTP id 11so2508508wwg.1 for ; Mon, 27 Jun 2011 15:43:16 -0700 (PDT) Received: by 10.216.171.18 with SMTP id q18mr2269866wel.47.1309214596264; Mon, 27 Jun 2011 15:43:16 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id z22sm3010401weq.2.2011.06.27.15.43.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Jun 2011 15:43:15 -0700 (PDT) Message-ID: <4E090781.20308@jitsi.org> Date: Tue, 28 Jun 2011 00:43:13 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 22:43:18 -0000 =D0=9D=D0=B0 28.06.11 00:35, Bernard Aboba =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > I do not support an unreliable datagram service that can be used to sen= d > arbitrary data.=20 >=20 > For example, it seems dangerous for a Web browser under the control of > an attacker to be able to send RIP, SNMP or DNS packets to arbitrary > destinations. >=20 > For these transactional exchanges the overhead of ICE would be excessiv= e > and so there will be a very strong temptation to cut corners. Well, if ICE is part of the browser we could condition sending such data on the successful termination of ICE processing with the intended destination. Same as with RTP. Wouldn't this work? Emil > Assuming that the goal is not to send arbitrary data, then we need to > dig into the transport requirements more. >=20 > For example, is the non-media data to be synchronized with media (e.g. > real-time text)? >=20 > Is there a session associated with the non-media data (e.g. XMPP or MSR= P > exchanges)? >=20 > Is there a reliability requirement? >=20 > Is it congestion-controlled? >=20 > How long-lived are the flows? >=20 >=20 >=20 >=20 > --------------------------------------------------- > From: magnus.westerlund@ericsson.com > To: rtcweb@ietf.org > Date: Mon, 27 Jun 2011 09:36:30 +0200 > Subject: [rtcweb] Non-media data service consensus and requirements >=20 > WG, > =20 > At the interim it was planned to have a bit discussion on the datagram > service for RTCWEB. The first question to try to resolve if there > is consensus for including some form of non real-time media (i.e. not > audio, video) service between peers. This is a bit tangled with the > actual requirements and use cases. But there was views both for it and > against it on the mailing list. So lets continue and try to come to a > conclusion on this discussion. > =20 > The use cases mentioned on the mailing list are: > =20 > - Dynamic meta data for Conference and other real-time services > =20 > - Gaming data with low latency requirements > =20 > Does anyone like to add additional use cases? > =20 > Based on my personal understanding this points to primarily have the > RTCWEB provide a unreliable datagram service. This clearly needs > additional requirements to be secure and safe to deploy, but more about= > this below. I still like to ask the WG here a question. > =20 > Are you supporting the inclusion of a unreliable datagram service > directly between peers? Please provide your view and any additional > statements of motivation that you desire to provide. > =20 > Secondly, there is a question if there needs to have something that > provides reliable message (of arbitrary size) or byte stream oriented > data transport between the peers. I personally foresee that people will= > build JS libraries for this on top of a unreliable datagram service. If= > you desire reliable data service as part of the standardized solution > please provide motivation and use case and requirements. > =20 > I also want to take a stab on what I personally see as the requirements= > that exist on unreliable datagram service in the context of RTCWEB. > =20 > - Unreliable data transmission > - Datagram oriented > * Size limited by MTU > - Path MTU discovery needed > * Fragmentation by the application > - Low latency, i.e. Peer to Peer preferable > - Congestion Controlled, to be > * Network friendly > * Not become a Denial of Service tool > - Security > * Confidentiality > * Integrity Protected > * Source Authenticated (at least bound to the signalling peer) > * Ensure consent to receive data > =20 > Please debate the above. This is an attempt to ensure that we can > establish WG consensus on both data service and any requirements. > =20 > cheers > =20 > Magnus Westerlund > =20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 http://jitsi.org FAX: +33.1.77.62.47.31 From matthew.kaufman@skype.net Mon Jun 27 15:43:47 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82C91F0C58 for ; Mon, 27 Jun 2011 15:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skrOUniAPC65 for ; Mon, 27 Jun 2011 15:43:46 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 96B0D1F0C49 for ; Mon, 27 Jun 2011 15:43:46 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 6870016F0; Tue, 28 Jun 2011 00:43:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=mx; bh=t9qt7ngnczAiEcWp+BsuxPSFRtY=; b=j6GXeNx a90xxMOSc6y8zSODfcazq6cw/pUhxQ2OfoEN4WpLg7h5/R3jep2/iq7FRq9EyzI1 E1aF953oQO83GrsuVrahOEZh2kiFGvxzV8FMO+ACDXQYFGmQHy4+lI5LeUTK6+ln J+3dqLsknhSZfbvcAH0rjx3wjIPI21huS8pY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to; q=dns; s=mx; b=Q24rcNvPwqA8YsRArHffqSIqQrBI6vGtKpRlGNXRHFx0sh7u mV4KV21kvGF5x1d63PHWb4iRJ2qmuPoYUIm88FGU2kerO7rwNj7ulvSxG9IRqvTW WQBB1lLy+2r32Vq6g+I3iGGwHaPX/xT8qGhuX+t69hCw67u2FsMeQGAfH98= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 66AB57F8; Tue, 28 Jun 2011 00:43:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 4BE163507DCF; Tue, 28 Jun 2011 00:43:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZjS-u6f4qOV; Tue, 28 Jun 2011 00:43:44 +0200 (CEST) Received: from [172.17.61.96] (50-0-2-20.static.sonic.net [50.0.2.20]) by zimbra.skype.net (Postfix) with ESMTPSA id 7EDF03507DBA; Tue, 28 Jun 2011 00:43:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-63-194939573 From: Matthew Kaufman In-Reply-To: Date: Mon, 27 Jun 2011 15:43:41 -0700 Message-Id: <665F50A5-580D-47BD-93CB-903DC182F657@skype.net> References: To: Bernard Aboba X-Mailer: Apple Mail (2.1082) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 22:43:47 -0000 --Apple-Mail-63-194939573 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 27, 2011, at 3:35 PM, Bernard Aboba wrote: > I do not support an unreliable datagram service that can be used to = send arbitrary data. =20 Mostly disagree. It should be possible to send arbitrary data from one = browser to another. >=20 > For example, it seems dangerous for a Web browser under the control of = an attacker to be able to send RIP, SNMP or DNS packets to arbitrary = destinations.=20 >=20 Agreed, so the encapsulation must prevent this. > For these transactional exchanges the overhead of ICE would be = excessive and so there will be a very strong temptation to cut corners.=20= >=20 Disagree. Browser vendors will have a strong incentive to not cut = corners. > Assuming that the goal is not to send arbitrary data, then we need to = dig into the transport requirements more.=20 >=20 > For example, is the non-media data to be synchronized with media (e.g. = real-time text)? >=20 Maybe. > Is there a session associated with the non-media data (e.g. XMPP or = MSRP exchanges)?=20 >=20 Maybe. > Is there a reliability requirement?=20 >=20 Maybe. > Is it congestion-controlled?=20 >=20 This must be enforced. > How long-lived are the flows?=20 >=20 Totally depends on the application. Matthew Kaufman --Apple-Mail-63-194939573 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jun 27, 2011, at 3:35 PM, Bernard = Aboba wrote:

I do not support an unreliable datagram service that = can be used to send arbitrary data.  

Mostly disagree. It should be possible to send = arbitrary data from one browser to another.


For example, it seems dangerous for a Web browser = under the control of an attacker to be able to send RIP, SNMP or DNS = packets to arbitrary destinations. 


Agreed, so the encapsulation must prevent = this.

For these transactional exchanges the overhead of ICE = would be excessive and so there will be a very strong temptation to cut = corners. 


Disagree. Browser vendors will have a strong = incentive to not cut corners.

Assuming that the goal is not to send arbitrary data, = then we need to dig into the transport requirements more. 

For example, is the = non-media data to be synchronized with media (e.g. real-time = text)?


Maybe.<= div>
Is there a session associated with the non-media data = (e.g. XMPP or MSRP exchanges)? 


Maybe.

Is there a reliability requirement? 


Maybe.

Is it congestion-controlled? 


This must be = enforced.

How long-lived are the flows? 


Totally depends on the = application.

Matthew = Kaufman

= --Apple-Mail-63-194939573-- From blizzard@mozilla.com Mon Jun 27 16:02:39 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830DB1F0C49 for ; Mon, 27 Jun 2011 16:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85WY6hZlyc1S for ; Mon, 27 Jun 2011 16:02:36 -0700 (PDT) Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF5F1F0C56 for ; Mon, 27 Jun 2011 16:02:36 -0700 (PDT) Received: from [10.250.2.228] (corp-240.mv.mozilla.com [63.245.220.240]) by mail.mozilla.com (Postfix) with ESMTPSA id C9FA6AE64668; Mon, 27 Jun 2011 16:02:35 -0700 (PDT) Message-ID: <4E090C0B.8050304@mozilla.com> Date: Mon, 27 Jun 2011 16:02:35 -0700 From: Christopher Blizzard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Emil Ivov References: <4E090781.20308@jitsi.org> In-Reply-To: <4E090781.20308@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , rtcweb@ietf.org Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 23:02:39 -0000 On 6/27/2011 3:43 PM, Emil Ivov wrote: > Well, if ICE is part of the browser we could condition sending such data > on the successful termination of ICE processing with the intended > destination. Same as with RTP. Wouldn't this work? > > Emil > Yes, assuming that we have an established session I wouldn't support APIs that would allow sending of data until that session was established, and only to the other browser(s) in the session. --Chris From bernard_aboba@hotmail.com Mon Jun 27 16:14:27 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF70221F850F for ; Mon, 27 Jun 2011 16:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-qrHeLNdhiL for ; Mon, 27 Jun 2011 16:14:27 -0700 (PDT) Received: from blu0-omc3-s9.blu0.hotmail.com (blu0-omc3-s9.blu0.hotmail.com [65.55.116.84]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBFC21F8525 for ; Mon, 27 Jun 2011 16:14:27 -0700 (PDT) Received: from BLU152-W40 ([65.55.116.73]) by blu0-omc3-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 16:14:27 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_f00dabe5-1ecf-4a55-a0e0-a6e93dce161f_" X-Originating-IP: [131.107.0.111] From: Bernard Aboba To: Date: Mon, 27 Jun 2011 16:14:26 -0700 Importance: Normal In-Reply-To: <4E090781.20308@jitsi.org> References: , <4E090781.20308@jitsi.org> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jun 2011 23:14:27.0055 (UTC) FILETIME=[F5C5EFF0:01CC351F] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 23:14:28 -0000 --_f00dabe5-1ecf-4a55-a0e0-a6e93dce161f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 > Well=2C if ICE is part of the browser we could condition sending such dat= a > on the successful termination of ICE processing with the intended > destination. Same as with RTP. Wouldn't this work? It depends on the exact requirements.=20 There has already been discussion of relaxing the ICE requirement so as to = better enable backward compatibility with legacy implementations (e.g. usin= g RTCP instead). =20 There is also a potential backward compatibility requirement for non-media = data=2C which will be even more difficult=2C since ICE (or Jingle or SDP) i= s not routinely used today (think online gaming)=2C and the volume is poten= tially quite heavy so that gateways may represent a significant burden. So before saying that ICE would "solve the problem"=2C it's important to un= derstand what exactly the problem is.=20 Are we talking about sending arbitrary data-grams in transactional exchange= s? Or perhaps text encoded in RTP? Or maybe data in a specified encoding= (e.g. not RTP or arbitrary datagrams) so as to prevent spoofing? Are there multiple use cases here=2C each with slightly different requireme= nts? =20 = --_f00dabe5-1ecf-4a55-a0e0-a6e93dce161f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 =3B
>=3B Well=2C if ICE is part of the browser we could cond= ition sending such data
>=3B on the successful termination of ICE proc= essing with the intended
>=3B destination. Same as with RTP. Wouldn't = this work?

It depends on the exact requirements.

There has a= lready been discussion of relaxing the ICE requirement so as to better enab= le backward compatibility with legacy implementations (e.g. using RTCP inst= ead). =3B
There is also a potential backward compatibility requirem= ent for non-media data=2C which will be even more difficult=2C since ICE (o= r Jingle or SDP) is not routinely used today (think online gaming)=2C and t= he volume is potentially quite heavy so that gateways may represent a signi= ficant burden.

So before saying that ICE would "solve the problem"= =2C it's important to understand what exactly the problem is.

Are w= e talking about sending arbitrary data-grams in transactional exchanges?&nb= sp=3B =3B Or perhaps text encoded in RTP? =3B Or maybe data in a sp= ecified encoding (e.g. not RTP or arbitrary datagrams) so as to prevent spo= ofing?

Are there multiple use cases here=2C each with slightly diffe= rent requirements?  =3B
= --_f00dabe5-1ecf-4a55-a0e0-a6e93dce161f_-- From matthew.kaufman@skype.net Mon Jun 27 16:26:22 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B382511E8074 for ; Mon, 27 Jun 2011 16:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joEyIGXrmKkP for ; Mon, 27 Jun 2011 16:26:19 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id D713B9E8008 for ; Mon, 27 Jun 2011 16:26:18 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id EE1E116F0; Tue, 28 Jun 2011 01:26:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=mx; bh=oml6cCUBGCNC1J68FMceCes5kbs=; b=JPag3Kg IHII5T8uDsP+5A/XLsOUu2aoTStO023myDAY5ysFbRvgum2zVfgW2Z9K2z6XRi3n H2lMoGEFOcS0qkkLzhieJqJTQccAqeI2a8RKNjERSzy11MBfYN4OqHknkKaNik16 adOX1DxmTuaFeZYUB7Nr7+xuPm/SZkpRMzAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to; q=dns; s=mx; b=VXXR98gqBNh+RYdWZ0Ku6tQ8BqHl9LiIlljIBFBA0qQ6kWli +k5s1u8x6OJwKQfI1WwJg7/Hhtx3/9QVzrOncSlgFE5ADDFoFefKy7oA0D4PQyA8 IijA6ZewCCXqeYPcFtsgNpKmN0Pjb7z0ybynIPK3wkGyBDmXMIEv6L9Rivk= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id D4EDE7F8; Tue, 28 Jun 2011 01:26:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 8FDC83506E39; Tue, 28 Jun 2011 01:26:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owC-+GQ1-7c1; Tue, 28 Jun 2011 01:26:16 +0200 (CEST) Received: from [172.17.61.96] (50-0-2-20.static.sonic.net [50.0.2.20]) by zimbra.skype.net (Postfix) with ESMTPSA id 1D4473506E0A; Tue, 28 Jun 2011 01:26:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-64-197492284 From: Matthew Kaufman In-Reply-To: Date: Mon, 27 Jun 2011 16:26:13 -0700 Message-Id: References: , <4E090781.20308@jitsi.org> To: Bernard Aboba X-Mailer: Apple Mail (2.1082) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 23:26:22 -0000 --Apple-Mail-64-197492284 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 27, 2011, at 4:14 PM, Bernard Aboba wrote: >=20 > Are there multiple use cases here, each with slightly different = requirements? =20 There's quite a few possible use cases... what we're looking for is the = lowest common denominator use case so we can build solutions for the = rest on top of that, rather than trying to build a dozen different = special-purpose protocols into the browser. Matthew Kaufman --Apple-Mail-64-197492284 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jun 27, 2011, at 4:14 PM, Bernard = Aboba wrote:


Are there multiple use cases here, each with = slightly different requirements?   
=

There's quite a few possible use cases... = what we're looking for is the lowest common denominator use case so we = can build solutions for the rest on top of that, rather than trying to = build a dozen different special-purpose protocols into the = browser.

Matthew = Kaufman

= --Apple-Mail-64-197492284-- From emil@sip-communicator.org Mon Jun 27 23:38:13 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C984321F866B for ; Mon, 27 Jun 2011 23:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHAtd9Nl4TO3 for ; Mon, 27 Jun 2011 23:38:12 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A755221F863E for ; Mon, 27 Jun 2011 23:38:11 -0700 (PDT) Received: by wyj26 with SMTP id 26so4147955wyj.31 for ; Mon, 27 Jun 2011 23:38:10 -0700 (PDT) Received: by 10.227.167.129 with SMTP id q1mr6144828wby.101.1309243089144; Mon, 27 Jun 2011 23:38:09 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id fi5sm4600633wbb.39.2011.06.27.23.38.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Jun 2011 23:38:08 -0700 (PDT) Message-ID: <4E0976CE.5060206@jitsi.org> Date: Tue, 28 Jun 2011 08:38:06 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Bernard Aboba References: , <4E090781.20308@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 06:38:13 -0000 =D0=9D=D0=B0 28.06.11 01:14, Bernard Aboba =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: >> Well, if ICE is part of the browser we could condition sending such da= ta >> on the successful termination of ICE processing with the intended >> destination. Same as with RTP. Wouldn't this work? >=20 > It depends on the exact requirements. >=20 > There has already been discussion of relaxing the ICE requirement so as= > to better enable backward compatibility with legacy implementations I supposed I missed the discussion on dropping ICE. However, I don't quite understand the issue with legacy implementations. If they are not using ICE then they are most probably relying on server-side relaying techniques such as latching. If that's the case then rtcweb clients would establish sessions with a server which would be the one required to do ICE (or ICE lite) rather than talking directly to the remote party.= This does indeed require the server to support ICE (lite) but is this really an issue? > (e.g. using RTCP instead).=20 Not sure I understand. Is someone using RTCP for NAT traversal and connectivity establishment? > There is also a potential backward compatibility requirement for > non-media data, which will be even more difficult, since ICE (or Jingle= > or SDP) is not routinely used today (think online gaming), and the > volume is potentially quite heavy so that gateways may represent a > significant burden. Same as above. If they weren't using ICE before then they were either relaying through a server that can now take care of ICE (lite), or they were using a home-grown ICE variant which wouldn't be compatible anyway. Am I missing something? > So before saying that ICE would "solve the problem", it's important to > understand what exactly the problem is. >=20 > Are we talking about sending arbitrary data-grams in transactional > exchanges? Or perhaps text encoded in RTP? Or maybe data in a > specified encoding (e.g. not RTP or arbitrary datagrams) so as to > prevent spoofing? >=20 > Are there multiple use cases here, each with slightly different > requirements? Right. Can we then agree that most use cases would be similar to a regular VoIP session without the limitation of putting RTP inside packets= ? Emil --=20 http://jitsi.org From igor.faynberg@alcatel-lucent.com Tue Jun 28 05:52:42 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF5A21F85DB for ; Tue, 28 Jun 2011 05:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qektz09CccWw for ; Tue, 28 Jun 2011 05:52:40 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5514B21F8646 for ; Tue, 28 Jun 2011 05:52:40 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p5SCqasI011864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 28 Jun 2011 07:52:36 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5SCqZJa028186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 28 Jun 2011 07:52:35 -0500 Received: from [135.222.134.156] (USMUYN0L055118.mh.lucent.com [135.222.134.156]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5SCqVD6028675; Tue, 28 Jun 2011 07:52:31 -0500 (CDT) Message-ID: <4E09CE8F.8000508@alcatel-lucent.com> Date: Tue, 28 Jun 2011 08:52:31 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E090781.20308@jitsi.org> In-Reply-To: <4E090781.20308@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 12:52:42 -0000 At the interim meeting, there was a strong argument for NOT having ICE as part of the browser, and I remember that no one objected. My reading is that it has been the decision. Igor On 6/27/2011 6:43 PM, Emil Ivov wrote: > ... >> For these transactional exchanges the overhead of ICE would be excessive >> and so there will be a very strong temptation to cut corners. > Well, if ICE is part of the browser we could condition sending such data > on the successful termination of ICE processing with the intended > destination. Same as with RTP. Wouldn't this work? > > Emil > >> Assuming that the goal is not to send arbitrary data, then we need to >> dig into the transport requirements more. >> >> For example, is the non-media data to be synchronized with media (e.g. >> real-time text)? >> >> Is there a session associated with the non-media data (e.g. XMPP or MSRP >> exchanges)? >> >> Is there a reliability requirement? >> >> Is it congestion-controlled? >> >> How long-lived are the flows? >> >> >> >> >> --------------------------------------------------- >> From: magnus.westerlund@ericsson.com >> To: rtcweb@ietf.org >> Date: Mon, 27 Jun 2011 09:36:30 +0200 >> Subject: [rtcweb] Non-media data service consensus and requirements >> >> WG, >> >> At the interim it was planned to have a bit discussion on the datagram >> service for RTCWEB. The first question to try to resolve if there >> is consensus for including some form of non real-time media (i.e. not >> audio, video) service between peers. This is a bit tangled with the >> actual requirements and use cases. But there was views both for it and >> against it on the mailing list. So lets continue and try to come to a >> conclusion on this discussion. >> >> The use cases mentioned on the mailing list are: >> >> - Dynamic meta data for Conference and other real-time services >> >> - Gaming data with low latency requirements >> >> Does anyone like to add additional use cases? >> >> Based on my personal understanding this points to primarily have the >> RTCWEB provide a unreliable datagram service. This clearly needs >> additional requirements to be secure and safe to deploy, but more about >> this below. I still like to ask the WG here a question. >> >> Are you supporting the inclusion of a unreliable datagram service >> directly between peers? Please provide your view and any additional >> statements of motivation that you desire to provide. >> >> Secondly, there is a question if there needs to have something that >> provides reliable message (of arbitrary size) or byte stream oriented >> data transport between the peers. I personally foresee that people will >> build JS libraries for this on top of a unreliable datagram service. If >> you desire reliable data service as part of the standardized solution >> please provide motivation and use case and requirements. >> >> I also want to take a stab on what I personally see as the requirements >> that exist on unreliable datagram service in the context of RTCWEB. >> >> - Unreliable data transmission >> - Datagram oriented >> * Size limited by MTU >> - Path MTU discovery needed >> * Fragmentation by the application >> - Low latency, i.e. Peer to Peer preferable >> - Congestion Controlled, to be >> * Network friendly >> * Not become a Denial of Service tool >> - Security >> * Confidentiality >> * Integrity Protected >> * Source Authenticated (at least bound to the signalling peer) >> * Ensure consent to receive data >> >> Please debate the above. This is an attempt to ensure that we can >> establish WG consensus on both data service and any requirements. >> >> cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From emil@sip-communicator.org Tue Jun 28 06:28:39 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939AF11E8090 for ; Tue, 28 Jun 2011 06:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK2yJLOVjXJ0 for ; Tue, 28 Jun 2011 06:28:38 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EEAA7228014 for ; Tue, 28 Jun 2011 06:28:37 -0700 (PDT) Received: by wwe5 with SMTP id 5so141404wwe.13 for ; Tue, 28 Jun 2011 06:28:37 -0700 (PDT) Received: by 10.227.28.206 with SMTP id n14mr6745247wbc.4.1309267715613; Tue, 28 Jun 2011 06:28:35 -0700 (PDT) Received: from porcinet.u-strasbg.fr (porcinet.u-strasbg.fr [130.79.91.167]) by mx.google.com with ESMTPS id b13sm163225wbh.7.2011.06.28.06.28.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Jun 2011 06:28:34 -0700 (PDT) Message-ID: <4E09D701.4030400@jitsi.org> Date: Tue, 28 Jun 2011 15:28:33 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <4E090781.20308@jitsi.org> <4E09CE8F.8000508@alcatel-lucent.com> In-Reply-To: <4E09CE8F.8000508@alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 13:28:39 -0000 =D0=9D=D0=B0 28.06.11 14:52, Igor Faynberg =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > At the interim meeting, there was a strong argument for NOT having ICE= =20 > as part of the browser, and I remember that no one objected. My readin= g=20 > is that it has been the decision. Well. I did attend the meeting but I remember no such decision or even rough consensus. I actually remember people discussing the fact that properly implementing ICE in javascript might be tricky due to the timer granularity and the pacing requirements in 5245. Have I missed something? Emil >=20 > Igor >=20 >=20 > On 6/27/2011 6:43 PM, Emil Ivov wrote: >> ... >>> For these transactional exchanges the overhead of ICE would be excess= ive >>> and so there will be a very strong temptation to cut corners. >> Well, if ICE is part of the browser we could condition sending such da= ta >> on the successful termination of ICE processing with the intended >> destination. Same as with RTP. Wouldn't this work? >> >> Emil >> >>> Assuming that the goal is not to send arbitrary data, then we need to= >>> dig into the transport requirements more. >>> >>> For example, is the non-media data to be synchronized with media (e.g= =2E >>> real-time text)? >>> >>> Is there a session associated with the non-media data (e.g. XMPP or M= SRP >>> exchanges)? >>> >>> Is there a reliability requirement? >>> >>> Is it congestion-controlled? >>> >>> How long-lived are the flows? >>> >>> >>> >>> >>> --------------------------------------------------- >>> From: magnus.westerlund@ericsson.com >>> To: rtcweb@ietf.org >>> Date: Mon, 27 Jun 2011 09:36:30 +0200 >>> Subject: [rtcweb] Non-media data service consensus and requirements >>> >>> WG, >>> >>> At the interim it was planned to have a bit discussion on the datagra= m >>> service for RTCWEB. The first question to try to resolve if there >>> is consensus for including some form of non real-time media (i.e. not= >>> audio, video) service between peers. This is a bit tangled with the >>> actual requirements and use cases. But there was views both for it an= d >>> against it on the mailing list. So lets continue and try to come to a= >>> conclusion on this discussion. >>> >>> The use cases mentioned on the mailing list are: >>> >>> - Dynamic meta data for Conference and other real-time services >>> >>> - Gaming data with low latency requirements >>> >>> Does anyone like to add additional use cases? >>> >>> Based on my personal understanding this points to primarily have the >>> RTCWEB provide a unreliable datagram service. This clearly needs >>> additional requirements to be secure and safe to deploy, but more abo= ut >>> this below. I still like to ask the WG here a question. >>> >>> Are you supporting the inclusion of a unreliable datagram service >>> directly between peers? Please provide your view and any additional >>> statements of motivation that you desire to provide. >>> >>> Secondly, there is a question if there needs to have something that >>> provides reliable message (of arbitrary size) or byte stream oriented= >>> data transport between the peers. I personally foresee that people wi= ll >>> build JS libraries for this on top of a unreliable datagram service. = If >>> you desire reliable data service as part of the standardized solution= >>> please provide motivation and use case and requirements. >>> >>> I also want to take a stab on what I personally see as the requiremen= ts >>> that exist on unreliable datagram service in the context of RTCWEB. >>> >>> - Unreliable data transmission >>> - Datagram oriented >>> * Size limited by MTU >>> - Path MTU discovery needed >>> * Fragmentation by the application >>> - Low latency, i.e. Peer to Peer preferable >>> - Congestion Controlled, to be >>> * Network friendly >>> * Not become a Denial of Service tool >>> - Security >>> * Confidentiality >>> * Integrity Protected >>> * Source Authenticated (at least bound to the signalling peer) >>> * Ensure consent to receive data >>> >>> Please debate the above. This is an attempt to ensure that we can >>> establish WG consensus on both data service and any requirements. >>> >>> cheers >>> >>> Magnus Westerlund >>> >>> ---------------------------------------------------------------------= - >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> ---------------------------------------------------------------------= - >>> Ericsson AB | Phone +46 10 7148287 >>> F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------= - >>> >>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 http://jitsi.org FAX: +33.1.77.62.47.31 From magnus.westerlund@ericsson.com Tue Jun 28 07:01:07 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE5821F8506 for ; Tue, 28 Jun 2011 07:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ebq5UsnZysxp for ; Tue, 28 Jun 2011 07:01:06 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 42C0121F84DD for ; Tue, 28 Jun 2011 07:01:06 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-96-4e09dea1f531 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F9.BA.20773.1AED90E4; Tue, 28 Jun 2011 16:01:05 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 28 Jun 2011 16:01:04 +0200 Message-ID: <4E09DE9F.5000307@ericsson.com> Date: Tue, 28 Jun 2011 16:01:03 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "igor.faynberg@alcatel-lucent.com" References: <4E090781.20308@jitsi.org> <4E09CE8F.8000508@alcatel-lucent.com> In-Reply-To: <4E09CE8F.8000508@alcatel-lucent.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 14:01:07 -0000 On 2011-06-28 14:52, Igor Faynberg wrote: > At the interim meeting, there was a strong argument for NOT having ICE > as part of the browser, and I remember that no one objected. My reading > is that it has been the decision. Yes, there was no such consensus decision in the interim meeting. We haven't done a call on the list either at this point. There was a clear question if one could implement ICE in a reasonable way in a JS environment and meet the timing needs. There has also been discussion on the mailing list after the Interim that questions interoperability implications of the proposal. So there are open questions. Please continue the various aspects so that we can can come to a conclusion. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From msimoni@gmail.com Tue Jun 28 07:18:46 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F1D21F86A5 for ; Tue, 28 Jun 2011 07:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pu-lc0fqPbG for ; Tue, 28 Jun 2011 07:18:46 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB9121F869B for ; Tue, 28 Jun 2011 07:18:46 -0700 (PDT) Received: by pvh18 with SMTP id 18so128416pvh.31 for ; Tue, 28 Jun 2011 07:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=AT8bAUJC/AbP1T8659thLsfvBwTBaWpMhnNvw8mUY54=; b=oKLqd5dW0rYyrha3GkY1zvxo+CGZSx2Zd/jhDwgxcUivEwzxgNJiL0tCYagLtIUYnn UeawnpAzTRUnZZTsgAKaa/tsUuYo8Ae8kLhit+Hmgj3mhV2Lncwro3Lxi3otfaIBzCX3 J3ATqa3mN7Odf1Iqn+ZJyb9zPwvtzijjtgqCs= MIME-Version: 1.0 Received: by 10.142.132.21 with SMTP id f21mr1427281wfd.277.1309270725801; Tue, 28 Jun 2011 07:18:45 -0700 (PDT) Received: by 10.143.34.1 with HTTP; Tue, 28 Jun 2011 07:18:45 -0700 (PDT) In-Reply-To: <4E0832FE.7010401@ericsson.com> References: <4E0832FE.7010401@ericsson.com> Date: Tue, 28 Jun 2011 16:18:45 +0200 Message-ID: From: Manuel Simoni To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 14:18:46 -0000 On Mon, Jun 27, 2011 at 9:36 AM, Magnus Westerlund wrote: > At the interim it was planned to have a bit discussion on the datagram > service for RTCWEB. The first question to try to resolve if there > is consensus for including some form of non real-time media (i.e. not > audio, video) service between peers. This is a bit tangled with the > actual requirements and use cases. But there was views both for it and > against it on the mailing list. So lets continue and try to come to a > conclusion on this discussion. > > The use cases mentioned on the mailing list are: > > - Dynamic meta data for Conference and other real-time services > > - Gaming data with low latency requirements > > Does anyone like to add additional use cases? Hello, I don't understand the networking details, but I am sure that people will want to transfer files between peers, and if only an unreliable service is provided, people *will* implement it on top of the unreliable service. Badly, probably. Manuel Simoni From magnus.westerlund@ericsson.com Tue Jun 28 07:33:08 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2803F11E80BE for ; Tue, 28 Jun 2011 07:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPI9m7Dkc8KX for ; Tue, 28 Jun 2011 07:33:07 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEB411E80E4 for ; Tue, 28 Jun 2011 07:33:07 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-17-4e09e6226058 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 78.3F.20773.226E90E4; Tue, 28 Jun 2011 16:33:06 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 28 Jun 2011 16:33:05 +0200 Message-ID: <4E09E621.6080109@ericsson.com> Date: Tue, 28 Jun 2011 16:33:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Manuel Simoni References: <4E0832FE.7010401@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 14:33:08 -0000 On 2011-06-28 16:18, Manuel Simoni wrote: > On Mon, Jun 27, 2011 at 9:36 AM, Magnus Westerlund > wrote: >> At the interim it was planned to have a bit discussion on the datagram >> service for RTCWEB. The first question to try to resolve if there >> is consensus for including some form of non real-time media (i.e. not >> audio, video) service between peers. This is a bit tangled with the >> actual requirements and use cases. But there was views both for it and >> against it on the mailing list. So lets continue and try to come to a >> conclusion on this discussion. >> >> The use cases mentioned on the mailing list are: >> >> - Dynamic meta data for Conference and other real-time services >> >> - Gaming data with low latency requirements >> >> Does anyone like to add additional use cases? > > Hello, > > I don't understand the networking details, but I am sure that people > will want to transfer files between peers, and if only an unreliable > service is provided, people *will* implement it on top of the > unreliable service. Badly, probably. Manual, as I asked lower down in the email: > Secondly, there is a question if there needs to have something that > provides reliable message (of arbitrary size) or byte stream oriented > data transport between the peers. I personally foresee that people will > build JS libraries for this on top of a unreliable datagram service. If > you desire reliable data service as part of the standardized solution > please provide motivation and use case and requirements. > When it comes to reliable data I interpret you being a supporter for it. However, can you elaborate on any usages you see for reliable object in web-applications to try to see if there are any requirements we are missing. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From fluffy@cisco.com Tue Jun 28 08:15:44 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FBD21F862D for ; Tue, 28 Jun 2011 08:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSxwTch7eJw1 for ; Tue, 28 Jun 2011 08:15:42 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 9E93B21F862A for ; Tue, 28 Jun 2011 08:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1942; q=dns/txt; s=iport; t=1309274137; x=1310483737; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=cbA/owiy4vqxyCRwIk6wWVKfuAZYF76dlhs7wIn7BuY=; b=hRbUDbHnIEgV4dFFp8BKrMpUqO+QkqejqQ5NVeM85bRysYlLTanKYwYg w0Uhhasn5nmKElLWtD3DMcJdvyPCc+PK5OrAUK33HAZMb4Ns35/tCUbdi VcY4MngWGmXr/eDNNLLB5tuygt5Zzf2cA7/485khne7wIyM7lRTEmt1nt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgHAPDuCU6rRDoJ/2dsb2JhbABSmE+OcnerWZ4yhjAEhzSKXIRui1I X-IronPort-AV: E=Sophos;i="4.65,437,1304294400"; d="scan'208";a="387769673" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 28 Jun 2011 15:15:22 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5SFFKaO009744; Tue, 28 Jun 2011 15:15:21 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jun 2011 09:15:20 -0600 Message-Id: <83D292CA-9B91-40BC-83AD-E1484E025E07@cisco.com> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Ted Hardie Subject: [rtcweb] Request for agenda items ... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 15:15:44 -0000 Here is our rough idea for an agenda. Let us know if you want to present = a draft in one of the section or if you think we need change the = section. This was based off our document split.=20 Thanks - Cullen, Magnus, and Ted=20 Draft Agenda - Version 1 =20 =20 Agenda Bash =20 Status report (Chairs) - 10 min =20 Liaison Report from W3C WebRTC -(WebRTC Chairs) - 10 min The W3C will have just had a meeting the Saturday before =20 Implementation Experience - 20 min - short little update on what people are implementing - discussion of things to help such as an implementors list - do we need an interoperability event later in year - expect to have 5 minute updates from 3 or more groups =20 Use Cases ( 30 min ) - we expect to have a WG draft by the meeting =20 Architecture and System Overview ( 30 min) - expect to have have 1 draft here =20 Security ( 20 min ) - expect to have 1 draft here =20 =20 =20 Start of Session two (Chairs) - 5 min =20 Negotiation & signaling (25 min) - expect to have 1 draft and wide variety of opinions here =20 NAT ( 20 min) - expect to have 1 draft here =20 Media transport (30 min) - would like to to come to a decision on the architecture = approach to number of UDP ports used for media and how, if any, = multiplexing works - expect to have 2 drafts here =20 Datagram transports (20 min) - expect to have 1 to 2 drafts here =20 Media processing & codec (20 min) - expect to have at last 1 draft here =20 =20= From fluffy@cisco.com Tue Jun 28 08:34:32 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C07B21F85B1 for ; Tue, 28 Jun 2011 08:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxM72iYDqARY for ; Tue, 28 Jun 2011 08:34:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 95C6A21F859F for ; Tue, 28 Jun 2011 08:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=8341; q=dns/txt; s=iport; t=1309275268; x=1310484868; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=dTrcpNtkDN3FXpqHxeKaZuZwIClE6jO1cyo6WIFOuCM=; b=Vl/HWRu9FUa8k3er455F5Ylbc2to+P64EMTrN2ye/RT2Ax2lrBlFfDDB EA0vo0y/i4PDtmvOsTNpnFKiCyaXQ335da1e1jBv+IhK49nuhEL8vXAFA BFpYR9zL0lQmIk86h2JZrE79mb3MvkVTaVV1dP10Vrc829asd27unO6co E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJjzCU6rRDoG/2dsb2JhbABFDadAd6tonjWDIIMQBIc0ilyEbotS X-IronPort-AV: E=Sophos;i="4.65,437,1304294400"; d="scan'208";a="723479974" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 28 Jun 2011 15:34:28 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5SFYQ11022452; Tue, 28 Jun 2011 15:34:27 GMT From: Cullen Jennings Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jun 2011 09:34:26 -0600 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] RTCWEB Interim 80.5 Meeting Minutes - June 8, 2011 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 15:34:32 -0000 RTCWEB Interim Meeting Minutes June 8, 2011 Chairs: Magnus, Cullen, Ted Session recording url: Will be provided in later email to list.=20 Jabber: rtcweb@jabber.ietf.org Materials: http://trac.tools.ietf.org/wg/rtcweb/trac/wiki Agenda: Architecture (discussion led by Harald) Use Cases and Solution Requirements (discussion led by Christer) Security (discussion led by EKR and Alan) NAT Traversal (discussion led by Matthew) RTP Usage (discussion led by Colin) Non audio/video data (discussion led by Chairs) Wrap Up Note well reviewed Harald reviewed slides at: = http://trac.tools.ietf.org/wg/rtcweb/trac/attachment/wiki/WikiStart/june-a= rch-preso.pdf Question raised: Harald mentions =93telephone events=94. What does that = mean? Cullen replied that this is DTMF. It is mostly used in PSTN gateway = situations. Andy Hutton: Is interoperability in the motherhood and apple pie slide = set? Harald's response: if we get browser-to-browser running in high quality, = then direct interoperability may not be a requirement (achieving = interoperability with a gateway, rather than =93cluttering up=94 the = browser implementation). Magnus asks whether anyone believes that Gear case 1 is possible to = achieve, or are we looking at Gear case 2? Harald says that this is = theoretically possible by software upgrade or for new phones. Cullen = says that this may happen, but it is likely to be new/newer devices = (capable of supporting ICE and the appropriate codecs). Those two things = are the minimum capabilities, in Cullen's opinion. JDR notes that it is = possible to use RTCP receive report in a way similar to a stun = connectivity check, but Matthew notes that there are security issues = with that substitution. The group agrees that avoiding Voice Hammer and = cross-protocol attacks is required; if there are ways to do that without = ICE, fine, but those are key requirements. Christer presents the slides at: = http://trac.tools.ietf.org/wg/rtcweb/trac/attachment/wiki/WikiStart/RTCWEB= _Presentation_Interim0611.ppt Use case: Simple Video had no objections Use case: Multiparty video had no objection on the core requirement, but = clarification is needed. JDR: to be clear, this use case presumes the browser does audio = mixing Christer: yes, but it does not re-emit the mixed stream. Cullen: is there a protocol difference from Simple Video? Christer: No, not much difference, but important to capture, = because other use cases have more complexity in media streams = (variable size, etc.) Assumption has full mesh of media = connections. Keith Drage: does each browser set up each mesh independently, = or does the protocol do something to set up the mesh? Christer: it is still pairwise set up. Markus Isomaki: Does the browser have a standard API for this? Christer: yes. Magnus: we need to clarify different parts of this use case. = There are no big objections, but the difference between this and = Simple Video is not that clear. EKR: There are transport issues and media issues. =46rom the = transport side, the mesh has characteristics similar to the Simple = Video. The media mixing has more complexity, as it needs to describe how to the streams interact. Magnus: are there objects to the core requirement? None heard. = More discussion of the scope needed. Markus: some kind of audio mixing API is needed. How do we get = the W3C to agree? Christer: there is lots of stuff that has to be communicated. AI: to the chairs to communicate the need for an audio mixing API to the = W3C. Use case: multiparty online game - Comments that this is very similar to previous use case where there = is mixing of other sources of audio (the game in this case)=20 - No objection to this use case=20 Use Case: Video conference system with central server Keith: How does this use case interact with existing IETF centralized = conferencing solutions? How much is the centralized sever in this use = expect to be consistent with existing IETF protocols? Christer: this leads to a discussion about what protocols the browser = might need to support, RTCP, BFCP, XCON, etc ...=20 ??? : The idea of sending two resolutions of video is not a very broad = requirement ???: we need to specify things like how to map SSRC to speakers so we = can see active speakers. We may need things like inter refresh.=20 Conclusion: Need to refine this use case to so that we can get to the = issues of what is key and what is not=20 Usec ase: Hockey - skipped Use case: Telephony terminal=20 Moving on to Security Presentation from Eric Rescorla (at 1:48 in = recording) Comment from Dan Burnett: Need ability to revoke permission (on slide = 13). No disagreement with this.=20 At 2:16 discussion about wiretap support. JDR said some people want to = LI some don=92t. Ted pointed out existing Pen and Wire Tap law were not = retrospective.=20 Mathew - want to clarify slides that we should make it so if you trust = your calling service, then you know your media is OK. (recording 2:28)=20= Point raised that allowing a user to see some sort of fingerprint of the = audio security is fine. If the users has some out of band method to = communicate that to the far side, they can detect MITM. How they might = communicate it to the far side not something we would figure out here.=20= Multiple people argued for support of RTP and SRTP. Then argued for = SDES and DTLS-SRTP. There should be a way to get a string that = fingerprints the media security and a way to display that in the browser = chrome.=20 Need to deal with tabbed browsing - so someone has a conversation open, = switches tab, then forgets some tab is involved with a call.=20 RTCWeb Media Privacy presentation: (starting at 3:02 in recording) Alan, voice is sensitive and important. Also remember that we are = defining the phone sevice for this century. A bit amazed that we are = talking about doing non SRTP. Adds negotiation complexities. Going = through his slides. Kauffman: Can the signal channel authenticate the ZRTP exchange?=20 Alan: Yes, the hash can be passed on the signal channel and verify the = whole exchange. EKR: Why is key-continute work better than a finger print? Alan: Not in itself, with the SAS one can verify the key continuty chain = in that instance. EKR: Still an issue as key continuty will not work if you change = devices. This enables the attacker to insert a new user identity that is = similar and which isn=92t is verified. Thus enabling doing a MITM.=20 The SAS is an exceptionall mechanism for a small user group.=20 Ted: Summarizing that there clearly are interest in the media privacy. = But there are feedback and perceived issues with what can be = accomplished.=20 NAT Traversal Presentation: (Starting at time ~3:17 into session) Kauffman presenting. Magnus: How do you accomplish interoperability if the two end-points are = using different applications?=20 Kauffman: The services that interop needs to agree on what mechanism to = use.=20 Cullen: What about pacing?=20 The pacing between multiple tabs doing pace are independent if there is = ICE or just the proposal.=20 EKR: It is not clearer that a global update is quicker with the = proposal, rather than in the browser deployement.=20 EKR: Can you actually do this accurately enough for this to work?=20 No one has tested it. Harald, show me the java script that can do this = against a regular ICE. Cullen: Moving on=20 RTP Usage: Starting at time 3:35 of the session Colin Perkins presenting. Discussion about multiplexing of audio and video on the same RTP = session.=20 Arguments between keeping the architecture and have interoperability = with legacy and saving port state for flows.=20 If QoS is sacrificable then a explicit shimming layer is a solution that = maintains the session separation.=20 Some arguments for supporting a legacy mode with separate sessions and = the possibility to put both on the same session.=20 If the general issue of allowing multiple RTP sessions on the same = transport flow, then this is a general issue and discussion should be in = AVTCORE and not RTCWEB specific. From ted.ietf@gmail.com Tue Jun 28 09:06:10 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61E821F8652 for ; Tue, 28 Jun 2011 09:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3crmem9hfSmd for ; Tue, 28 Jun 2011 09:06:10 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2495921F864E for ; Tue, 28 Jun 2011 09:06:10 -0700 (PDT) Received: by yxp4 with SMTP id 4so201889yxp.31 for ; Tue, 28 Jun 2011 09:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B2oCB6mU9It5//t56hkRFAlRa+OrhJESTvPd9c+QRZg=; b=vIWQuv5dEyiRQNUq4DVHC0NpBQ+cWV1WGpBD4JqkU8qg7kVycrcIclEjNFCIGzMtq6 4rGH+O6o3rPbwDUHKXFxcIRtOiGjswNX6HyLTXol7IY0q/pLgxxCpKVKmtetLj7cW4z+ 0IqIBtrDtHvUdldkLUlBdqGD00NdiIFzbZvJQ= MIME-Version: 1.0 Received: by 10.236.191.162 with SMTP id g22mr11224145yhn.451.1309277169346; Tue, 28 Jun 2011 09:06:09 -0700 (PDT) Received: by 10.236.180.196 with HTTP; Tue, 28 Jun 2011 09:06:09 -0700 (PDT) In-Reply-To: <83D292CA-9B91-40BC-83AD-E1484E025E07@cisco.com> References: <83D292CA-9B91-40BC-83AD-E1484E025E07@cisco.com> Date: Tue, 28 Jun 2011 09:06:09 -0700 Message-ID: From: Ted Hardie To: Cullen Jennings Content-Type: multipart/alternative; boundary=20cf305642179766f504a6c7d89b Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Request for agenda items ... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 16:06:10 -0000 --20cf305642179766f504a6c7d89b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 28, 2011 at 8:15 AM, Cullen Jennings wrote: > > > Media processing & codec (20 min) > - expect to have at last 1 draft here > > > To clarify what we're looking for here, we would like to have discussion of the technical requirements for real time media (e.g. audio, video, real time text) that arise from the use cases that the group is setting out. Discussion on the mailing list and/or any drafts folks want to write on this are highly encouraged, but should focus on the technical requirements. thanks, Ted, Cullen, and Magnus --20cf305642179766f504a6c7d89b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jun 28, 2011 at 8:15 AM, Cullen Jennings <fluffy@cisco.com> wrote:
<= div class=3D"gmail_quote">


=A0 =A0 =A0 =A0 =A0Media processing & codec (20 min)
=A0 =A0 =A0 =A0 =A0- expect to have at last 1 draft here



To clarify what we're looking for here, w= e would like to have discussion of the technical requirements for real time= media (e.g. audio, video, real time text) that arise from the use cases th= at the group is setting out.=A0 Discussion on the mailing list and/or any d= rafts folks want to write on this are highly encouraged, but should focus o= n the technical requirements.

thanks,

Ted, Cullen, and Magnus
--20cf305642179766f504a6c7d89b-- From igor.faynberg@alcatel-lucent.com Tue Jun 28 09:29:02 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8E011E8124 for ; Tue, 28 Jun 2011 09:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elWissstMEVv for ; Tue, 28 Jun 2011 09:29:01 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0187011E8114 for ; Tue, 28 Jun 2011 09:29:00 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p5SGSwJt015199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Jun 2011 11:28:59 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5SGSwd7025368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Jun 2011 11:28:58 -0500 Received: from [135.222.134.156] (USMUYN0L055118.mh.lucent.com [135.222.134.156]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5SGStQZ020670; Tue, 28 Jun 2011 11:28:57 -0500 (CDT) Message-ID: <4E0A0147.2030402@alcatel-lucent.com> Date: Tue, 28 Jun 2011 12:28:55 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Emil Ivov References: <4E090781.20308@jitsi.org> <4E09CE8F.8000508@alcatel-lucent.com> <4E09D701.4030400@jitsi.org> In-Reply-To: <4E09D701.4030400@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 16:29:02 -0000 No, most likely it was I who missed something... Yes, I remember the timer questions, but I thought Jonathan answered this. (By the way, I do not have a firm opinion on the subject myself, and I don't understand the issues behind the performance model here.) Surely, it is too early for the consensus to be formed, but I expect our esteemed chairmen to declare it at certain point because the matters like that ought to be settled as early as possible. Igor On 6/28/2011 9:28 AM, Emil Ivov wrote: > Ðа 28.06.11 14:52, Igor Faynberg напиÑа: >> At the interim meeting, there was a strong argument for NOT having ICE >> as part of the browser, and I remember that no one objected. My reading >> is that it has been the decision. > Well. I did attend the meeting but I remember no such decision or even > rough consensus. I actually remember people discussing the fact that > properly implementing ICE in javascript might be tricky due to the timer > granularity and the pacing requirements in 5245. > > Have I missed something? > > Emil > >> Igor >> >> >> On 6/27/2011 6:43 PM, Emil Ivov wrote: >>> ... >>>> For these transactional exchanges the overhead of ICE would be excessive >>>> and so there will be a very strong temptation to cut corners. >>> Well, if ICE is part of the browser we could condition sending such data >>> on the successful termination of ICE processing with the intended >>> destination. Same as with RTP. Wouldn't this work? >>> >>> Emil >>> >>>> Assuming that the goal is not to send arbitrary data, then we need to >>>> dig into the transport requirements more. >>>> >>>> For example, is the non-media data to be synchronized with media (e.g. >>>> real-time text)? >>>> >>>> Is there a session associated with the non-media data (e.g. XMPP or MSRP >>>> exchanges)? >>>> >>>> Is there a reliability requirement? >>>> >>>> Is it congestion-controlled? >>>> >>>> How long-lived are the flows? >>>> >>>> >>>> >>>> >>>> --------------------------------------------------- >>>> From: magnus.westerlund@ericsson.com >>>> To: rtcweb@ietf.org >>>> Date: Mon, 27 Jun 2011 09:36:30 +0200 >>>> Subject: [rtcweb] Non-media data service consensus and requirements >>>> >>>> WG, >>>> >>>> At the interim it was planned to have a bit discussion on the datagram >>>> service for RTCWEB. The first question to try to resolve if there >>>> is consensus for including some form of non real-time media (i.e. not >>>> audio, video) service between peers. This is a bit tangled with the >>>> actual requirements and use cases. But there was views both for it and >>>> against it on the mailing list. So lets continue and try to come to a >>>> conclusion on this discussion. >>>> >>>> The use cases mentioned on the mailing list are: >>>> >>>> - Dynamic meta data for Conference and other real-time services >>>> >>>> - Gaming data with low latency requirements >>>> >>>> Does anyone like to add additional use cases? >>>> >>>> Based on my personal understanding this points to primarily have the >>>> RTCWEB provide a unreliable datagram service. This clearly needs >>>> additional requirements to be secure and safe to deploy, but more about >>>> this below. I still like to ask the WG here a question. >>>> >>>> Are you supporting the inclusion of a unreliable datagram service >>>> directly between peers? Please provide your view and any additional >>>> statements of motivation that you desire to provide. >>>> >>>> Secondly, there is a question if there needs to have something that >>>> provides reliable message (of arbitrary size) or byte stream oriented >>>> data transport between the peers. I personally foresee that people will >>>> build JS libraries for this on top of a unreliable datagram service. If >>>> you desire reliable data service as part of the standardized solution >>>> please provide motivation and use case and requirements. >>>> >>>> I also want to take a stab on what I personally see as the requirements >>>> that exist on unreliable datagram service in the context of RTCWEB. >>>> >>>> - Unreliable data transmission >>>> - Datagram oriented >>>> * Size limited by MTU >>>> - Path MTU discovery needed >>>> * Fragmentation by the application >>>> - Low latency, i.e. Peer to Peer preferable >>>> - Congestion Controlled, to be >>>> * Network friendly >>>> * Not become a Denial of Service tool >>>> - Security >>>> * Confidentiality >>>> * Integrity Protected >>>> * Source Authenticated (at least bound to the signalling peer) >>>> * Ensure consent to receive data >>>> >>>> Please debate the above. This is an attempt to ensure that we can >>>> establish WG consensus on both data service and any requirements. >>>> >>>> cheers >>>> >>>> Magnus Westerlund >>>> >>>> ---------------------------------------------------------------------- >>>> Multimedia Technologies, Ericsson Research EAB/TVM >>>> ---------------------------------------------------------------------- >>>> Ericsson AB | Phone +46 10 7148287 >>>> Färögatan 6 | Mobile +46 73 0949079 >>>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From prvs=15388d6cb=tterriberry@mozilla.com Tue Jun 28 10:06:45 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0F211E80C3 for ; Tue, 28 Jun 2011 10:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhuVT2CUyeaZ for ; Tue, 28 Jun 2011 10:06:44 -0700 (PDT) Received: from mxip3i.isis.unc.edu (mxip3i.isis.unc.edu [152.2.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id C781F11E808C for ; Tue, 28 Jun 2011 10:06:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEALcICk6sGgRS/2dsb2JhbABShEmiBYFpiHevN5EfgSuDeYEMBIc0jzwOi1M X-IronPort-AV: E=Sophos;i="4.65,437,1304308800"; d="scan'208";a="103769286" Received: from mr1a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.82]) by mxip3o.isis.unc.edu with ESMTP; 28 Jun 2011 13:06:43 -0400 X-UNC-Auth-As: tterribe X-UNC-Auth-IP: 69.181.137.38 Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id p5SH6bpE004482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 28 Jun 2011 13:06:40 -0400 (EDT) Message-ID: <4E0A0A1C.6060905@mozilla.com> Date: Tue, 28 Jun 2011 10:06:36 -0700 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 CC: rtcweb@ietf.org References: <4E090781.20308@jitsi.org> <4E09CE8F.8000508@alcatel-lucent.com> <4E09D701.4030400@jitsi.org> <4E0A0147.2030402@alcatel-lucent.com> In-Reply-To: <4E0A0147.2030402@alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 17:06:45 -0000 > No, most likely it was I who missed something... Yes, I remember the > timer questions, but I thought Jonathan answered this. IIRC, Harald suggested that the best way to decide if this was actually feasible was with "running code", at least at the proof-of-concept level. This seemed like a very good idea to me. The resolution of JS timers is not the only issue. One also has to deal with other pages with long-running JS scripts that prevent your timers from firing. Various advertisers do this on a semi-regular basis, though I don't have good numbers on how frequent this is, or how much of a problem it would really pose. Running code could be used to actually measure the connectivity success rate, for those that want to know. I don't think the compatibility concerns have been addressed, either. With ICE in the browser, you have four or five implementations total that have to interoperate, vs. (potentially) one for each website. Updates to browsers can be deployed, at scale, to hundreds of millions of users in the span of a few weeks (at least with Firefox and Chrome, Safari and IE also have well-established short-term update mechanisms, though they're usually for security issues rather than new features), vs. trying to get each and every website to update their JS library. An individual website may be able to deploy updates more quickly than the browser vendors, but interoperability isn't about the individual. And now there are the security concerns with sending datagrams after trying to short-cut the ICE process. I don't know if mandating STUN requests before sending data to a remote peer is sufficient to address these, but clearly some others see a potential problem. Personally, I think having p2p datagram support is a much more important feature to end users than being able to change the connection handshake protocol in JS. Everything above is an argument I've heard someone else raise at some point. I haven't heard a lot of good responses to these arguments. From jdrosen@jdrosen.net Tue Jun 28 12:46:05 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C1A11E81A7 for ; Tue, 28 Jun 2011 12:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXE1hi2p2lIp for ; Tue, 28 Jun 2011 12:46:04 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [69.174.48.15]) by ietfa.amsl.com (Postfix) with ESMTP id 27C8411E818F for ; Tue, 28 Jun 2011 12:46:04 -0700 (PDT) Received: from pool-173-63-59-84.nwrknj.fios.verizon.net ([173.63.59.84] helo=[192.168.1.14]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QbeEU-0000bJ-Sy for rtcweb@ietf.org; Tue, 28 Jun 2011 15:46:02 -0400 Message-ID: <4E0A2F70.9040305@jdrosen.net> Date: Tue, 28 Jun 2011 15:45:52 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E0832FE.7010401@ericsson.com> In-Reply-To: <4E0832FE.7010401@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 19:46:05 -0000 Here are some thoughts on additional use cases: * information on congestion and receiver side environment for purposes of improved sender rate adaptation * active speaker indications * real-time text (along the lines of http://datatracker.ietf.org/doc/rfc5194/) * video controls - application driven intra-frame requests, for example * floor control requests/grants All of these share the common property of being latency sensitive, and thus more appropraite for p2p vs. server mediated. The other driver for p2p data transport is cost reduction, to avoid the need for server mediation for transfer of data. File transfer is the main example of this. I view the latency-sensitive use cases as a higher priority for us and a better match to the work we're doing here. Thanks, Jonathan R. On 6/27/2011 3:36 AM, Magnus Westerlund wrote: > WG, > > At the interim it was planned to have a bit discussion on the datagram > service for RTCWEB. The first question to try to resolve if there > is consensus for including some form of non real-time media (i.e. not > audio, video) service between peers. This is a bit tangled with the > actual requirements and use cases. But there was views both for it and > against it on the mailing list. So lets continue and try to come to a > conclusion on this discussion. > > The use cases mentioned on the mailing list are: > > - Dynamic meta data for Conference and other real-time services > > - Gaming data with low latency requirements > > Does anyone like to add additional use cases? > > Based on my personal understanding this points to primarily have the > RTCWEB provide a unreliable datagram service. This clearly needs > additional requirements to be secure and safe to deploy, but more about > this below. I still like to ask the WG here a question. > > Are you supporting the inclusion of a unreliable datagram service > directly between peers? Please provide your view and any additional > statements of motivation that you desire to provide. > > Secondly, there is a question if there needs to have something that > provides reliable message (of arbitrary size) or byte stream oriented > data transport between the peers. I personally foresee that people will > build JS libraries for this on top of a unreliable datagram service. If > you desire reliable data service as part of the standardized solution > please provide motivation and use case and requirements. > > I also want to take a stab on what I personally see as the requirements > that exist on unreliable datagram service in the context of RTCWEB. > > - Unreliable data transmission > - Datagram oriented > * Size limited by MTU > - Path MTU discovery needed > * Fragmentation by the application > - Low latency, i.e. Peer to Peer preferable > - Congestion Controlled, to be > * Network friendly > * Not become a Denial of Service tool > - Security > * Confidentiality > * Integrity Protected > * Source Authenticated (at least bound to the signalling peer) > * Ensure consent to receive data > > Please debate the above. This is an attempt to ensure that we can > establish WG consensus on both data service and any requirements. > > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Skype Chief Technology Strategist jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From dzonatas@gmail.com Tue Jun 28 13:14:02 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABA511E80CA for ; Tue, 28 Jun 2011 13:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.745 X-Spam-Level: X-Spam-Status: No, score=-4.745 tagged_above=-999 required=5 tests=[AWL=-1.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvZ9w3c4dD+C for ; Tue, 28 Jun 2011 13:14:01 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 492C211E8140 for ; Tue, 28 Jun 2011 13:14:01 -0700 (PDT) Received: by pwj5 with SMTP id 5so478496pwj.31 for ; Tue, 28 Jun 2011 13:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MLhTTbCyCyNVRx29gwr5vtgZHV9A5Qog5vgY1GBMvK8=; b=lIL5lNvD0JdcCc+9WRYrZ4AnZzvkVGp3w86zOiWdYDCLwGa2Xvxisx3Cjpj+9DD4+s ZTqWEvbaXbHbCHZVJCG79G5qsL0NnPrxNS86p48ary2gsGODYiYgqzjxxuylt6XDpVxd 1TqSebNzWy/Zqd7EehupMug+HtVbncVvuSGvk= Received: by 10.68.23.100 with SMTP id l4mr3931248pbf.358.1309292040980; Tue, 28 Jun 2011 13:14:00 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id x1sm358810pbb.50.2011.06.28.13.13.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Jun 2011 13:14:00 -0700 (PDT) Message-ID: <4E0A35E3.2040307@gmail.com> Date: Tue, 28 Jun 2011 13:13:23 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTCWEB Interim 80.5 Meeting Minutes - June 8, 2011 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:14:02 -0000 On 06/28/2011 08:34 AM, Cullen Jennings wrote: > [...] The group agrees that avoiding Voice Hammer and cross-protocol attacks is required; if there are ways to do that without ICE, fine, but those are key requirements. > If ICE relates to X11's ICE (which I doubt on specific screens and drivers), then may I hint at the mote method of IPv4 "land" inside IPv6 (or other protocol) "mote". The concept is ridiculous in single core systems with centralized-peripheral, yet may be cents for those that keep hardwired bridges. The key point is the is-"land" only knows IPv4, so remains unaffected by its float among IPv6. I wouldn't doubt the mechanics of ICE-walls continue to stretch so far into court to quietly determine "this" is the same as "this" in the business or not (i.e. stationary battery industry and mobile drive systems, or mobile battery industry and stationary drive systems, ... endless). -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From dzonatas@gmail.com Tue Jun 28 13:49:17 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5901C11E81BC for ; Tue, 28 Jun 2011 13:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.363 X-Spam-Level: X-Spam-Status: No, score=-4.363 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu1MtwrLyouC for ; Tue, 28 Jun 2011 13:49:16 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99D1911E814D for ; Tue, 28 Jun 2011 13:49:16 -0700 (PDT) Received: by pwj5 with SMTP id 5so502201pwj.31 for ; Tue, 28 Jun 2011 13:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=yD7ouvdQQV4DmQRvR+VqkYHPjrhKrLu+FKzi8PuVnLk=; b=llk+Wnuoena5kUpxk/Ysz14JqJgrkiYnc6eHxcSLoNOkVZs2FWaKo/Ky28Mj2KQ6XZ hadykXgcE/+5Z9WZo/0kIT9A/E/vcbEeZcaMkpuD55o3CCr9sb1KoEtosV9kX6hzRms4 RqOHU8z6vfHzg2NzFstZnrJyo6p8CisJKFIVM= Received: by 10.68.35.2 with SMTP id d2mr3867743pbj.454.1309294156350; Tue, 28 Jun 2011 13:49:16 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id o2sm384335pbj.1.2011.06.28.13.49.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Jun 2011 13:49:15 -0700 (PDT) Message-ID: <4E0A3E1A.7070104@gmail.com> Date: Tue, 28 Jun 2011 13:48:26 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E0832FE.7010401@ericsson.com> <4E0A2F70.9040305@jdrosen.net> In-Reply-To: <4E0A2F70.9040305@jdrosen.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:49:17 -0000 Please consider something like "augmented waypoints" for evacuation systems (might help resolve stampedes). On 06/28/2011 12:45 PM, Jonathan Rosenberg wrote: > Here are some thoughts on additional use cases: > > * information on congestion and receiver side environment for purposes > of improved sender rate adaptation > > * active speaker indications > > * real-time text (along the lines of > http://datatracker.ietf.org/doc/rfc5194/) > > * video controls - application driven intra-frame requests, for example > > * floor control requests/grants > > > All of these share the common property of being latency sensitive, and > thus more appropraite for p2p vs. server mediated. The other driver > for p2p data transport is cost reduction, to avoid the need for server > mediation for transfer of data. File transfer is the main example of > this. > > I view the latency-sensitive use cases as a higher priority for us and > a better match to the work we're doing here. > > Thanks, > Jonathan R. > > On 6/27/2011 3:36 AM, Magnus Westerlund wrote: >> WG, >> >> At the interim it was planned to have a bit discussion on the datagram >> service for RTCWEB. The first question to try to resolve if there >> is consensus for including some form of non real-time media (i.e. not >> audio, video) service between peers. This is a bit tangled with the >> actual requirements and use cases. But there was views both for it and >> against it on the mailing list. So lets continue and try to come to a >> conclusion on this discussion. >> >> The use cases mentioned on the mailing list are: >> >> - Dynamic meta data for Conference and other real-time services >> >> - Gaming data with low latency requirements >> >> Does anyone like to add additional use cases? >> >> Based on my personal understanding this points to primarily have the >> RTCWEB provide a unreliable datagram service. This clearly needs >> additional requirements to be secure and safe to deploy, but more about >> this below. I still like to ask the WG here a question. >> >> Are you supporting the inclusion of a unreliable datagram service >> directly between peers? Please provide your view and any additional >> statements of motivation that you desire to provide. >> >> Secondly, there is a question if there needs to have something that >> provides reliable message (of arbitrary size) or byte stream oriented >> data transport between the peers. I personally foresee that people will >> build JS libraries for this on top of a unreliable datagram service. If >> you desire reliable data service as part of the standardized solution >> please provide motivation and use case and requirements. >> >> I also want to take a stab on what I personally see as the requirements >> that exist on unreliable datagram service in the context of RTCWEB. >> >> - Unreliable data transmission >> - Datagram oriented >> * Size limited by MTU >> - Path MTU discovery needed >> * Fragmentation by the application >> - Low latency, i.e. Peer to Peer preferable >> - Congestion Controlled, to be >> * Network friendly >> * Not become a Denial of Service tool >> - Security >> * Confidentiality >> * Integrity Protected >> * Source Authenticated (at least bound to the signalling peer) >> * Ensure consent to receive data >> >> Please debate the above. This is an attempt to ensure that we can >> establish WG consensus on both data service and any requirements. >> >> cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F�r�gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From dzonatas@gmail.com Tue Jun 28 14:10:26 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305AB21F86C0 for ; Tue, 28 Jun 2011 14:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.172 X-Spam-Level: X-Spam-Status: No, score=-4.172 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8sJ8T-SmtD3 for ; Tue, 28 Jun 2011 14:10:25 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 574D611E80B0 for ; Tue, 28 Jun 2011 14:10:25 -0700 (PDT) Received: by pzk5 with SMTP id 5so519526pzk.31 for ; Tue, 28 Jun 2011 14:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=sF7rfl63ipkNENaR6P60+JQhmcggOfhhFv2PmLdvr1k=; b=nvxC70xzyic0H0vlWa0IEt5gkQIRBUZGm9EgfwLa/T5jp8ELoS0Bmg2EInSXtU6ihM J5hlhvtRod8F1ooRNQuQEAGZMHY9GAEW0B6LrIF13sxj4hqgbGebynk9twhIRRZ2JQKG dYrjsJ7KAc/9heDpjWO5CQht4xZmpKDn5YKMs= Received: by 10.142.192.8 with SMTP id p8mr4590wff.322.1309295416044; Tue, 28 Jun 2011 14:10:16 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id z39sm340307wfd.23.2011.06.28.14.10.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Jun 2011 14:10:15 -0700 (PDT) Message-ID: <4E0A4312.7040008@gmail.com> Date: Tue, 28 Jun 2011 14:09:38 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E090781.20308@jitsi.org> <4E09CE8F.8000508@alcatel-lucent.com> <4E09D701.4030400@jitsi.org> <4E0A0147.2030402@alcatel-lucent.com> <4E0A0A1C.6060905@mozilla.com> In-Reply-To: <4E0A0A1C.6060905@mozilla.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 21:10:26 -0000 On 06/28/2011 10:06 AM, Timothy B. Terriberry wrote: > > And now there are the security concerns with sending datagrams after > trying to short-cut the ICE process. > What happens is that the application (of ICE systems) creates the delusion the previous path is no longer of need. The ICE system itself doesn't do that, as newer adapters are unfamiliar with the previous path. The security concern is in the question to end the previous path. Some defaulted the previous path "off" after application, which made related evolution harder... proven human error when that kind of security level (prevent evolution?) is not needed. It works best to distinguish versions and with things meant-for standardization (towards hardware, or towards plasma-stasis in quantum physics). -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From fluffy@cisco.com Tue Jun 28 20:28:32 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6296011E808F for ; Tue, 28 Jun 2011 20:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qrc9PRPvshQ for ; Tue, 28 Jun 2011 20:28:31 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 81D5011E808C for ; Tue, 28 Jun 2011 20:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=604; q=dns/txt; s=iport; t=1309318111; x=1310527711; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=CPDmfjFGWYB1Z8J4e4Tbxggbw+IWMXpeUJ09fNx54kE=; b=ekKLbRAq9UZefTYDTboK9hAl24SzoCfINc/jDfPgL2QQ+5yvZYHZL21b RGdCcBd4YwDm59PMy6Ar89+pFvObdXv+OkDymjzUhAse50zA+JJN+DwMS WOeff8CZxUCiMy0nmlacRDAFBj+ocBe0JMaQnZeKS0hbAcQ/KQghKXdaV g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIHAD2bCk6rRDoJ/2dsb2JhbABSmFiOd3epYIEengaGMASHNophhHSLVA X-IronPort-AV: E=Sophos;i="4.65,441,1304294400"; d="scan'208";a="388170791" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 29 Jun 2011 03:28:31 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5T3SUIU004185 for ; Wed, 29 Jun 2011 03:28:30 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jun 2011 21:28:30 -0600 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Recordings from last interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 03:28:32 -0000 Here are the recordings from the last interim meeting. The first half of = the meeting before the break is in the "PartA" files while the second = half of the meeting after the break is in the "PartB" files. YMMV but = mac users will probably haver better luck using the .mov files while = windows users will probably do better with the .mp4 files. http://dl.dropbox.com/u/17089001/IETF-RTCWeb-80.5-PartA.mov http://dl.dropbox.com/u/17089001/IETF-RTCWeb-80.5-PartA.mp4 http://dl.dropbox.com/u/17089001/IETF-RTCWeb-80.5-partB.mov http://dl.dropbox.com/u/17089001/IETF-RTCWeb-80.5-partB.mp4 From randell1@jesup.org Tue Jun 28 21:15:14 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F30D21F8527 for ; Tue, 28 Jun 2011 21:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IM1WoMNdsGcF for ; Tue, 28 Jun 2011 21:15:13 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4574321F84DA for ; Tue, 28 Jun 2011 21:15:13 -0700 (PDT) Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QbmBD-0001LI-Q2 for rtcweb@ietf.org; Tue, 28 Jun 2011 23:15:11 -0500 Message-ID: <4E0AA623.9090601@jesup.org> Date: Wed, 29 Jun 2011 00:12:19 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E0832FE.7010401@ericsson.com> <4E0A2F70.9040305@jdrosen.net> In-Reply-To: <4E0A2F70.9040305@jdrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 04:15:14 -0000 On 6/28/2011 3:45 PM, Jonathan Rosenberg wrote: > Here are some thoughts on additional use cases: > > * information on congestion and receiver side environment for purposes > of improved sender rate adaptation Aka active bandwidth adaptation. This will generally be better over RTCP or other unreliable-but-low-latency channel. One thing we may want to address is handling congestion across a set of streams, instead of only a single stream. Current mechanisms are stream-oriented, which both can cause unexpected conflicts between related streams (audio and video for example), and also allows "cheating" congestion rules by opening multiple 'connections' (streams). This was one thing that RTMFP got right, along with allowing reliable datagram services. As mentioned, if it's not provided then N*M people will try to implement reliable transport over whatever streams we give them (including random RTP streams), and as someone said, they'll make mistakes. > > * active speaker indications > > * real-time text (along the lines of > http://datatracker.ietf.org/doc/rfc5194/) > > * video controls - application driven intra-frame requests, for example I suspect these should be dealt with using normal rtcpfb mechanisms, there there may be needs for a reliable transport of this request. > > * floor control requests/grants > And as was mentioned user input events in a VNC/RDP-type remote browser-sharing. (and yes, there are security issues here!) These are both latency-sensitive and must be reliable (or at least a subset of events must be reliable, and probably all do). > > All of these share the common property of being latency sensitive, and > thus more appropraite for p2p vs. server mediated. The other driver > for p2p data transport is cost reduction, to avoid the need for server > mediation for transfer of data. File transfer is the main example of > this. > > I view the latency-sensitive use cases as a higher priority for us and > a better match to the work we're doing here. To be clear: I'm in favor of considering non-media unreliable and reliable transports. -- Randell Jesup randell-ietf@jesup.org From gonzalo.camarillo@ericsson.com Tue Jun 28 23:47:50 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5949E8027 for ; Tue, 28 Jun 2011 23:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sl1QNnmi5xoN for ; Tue, 28 Jun 2011 23:47:49 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id EE3389E8026 for ; Tue, 28 Jun 2011 23:47:48 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-73-4e0aca93bb43 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 25.2A.20773.39ACA0E4; Wed, 29 Jun 2011 08:47:48 +0200 (CEST) Received: from [131.160.126.185] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Wed, 29 Jun 2011 08:47:47 +0200 Message-ID: <4E0ACA93.8050500@ericsson.com> Date: Wed, 29 Jun 2011 09:47:47 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Francois Daoust References: <4E00A355.2040309@w3.org> In-Reply-To: <4E00A355.2040309@w3.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] W3C Web Real-Time Communications face-to-face on 23 July 2011 in Quebec City, Canada X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 06:47:50 -0000 Hi, we have scheduled this meeting on the Saturday before the IETF (July 23rd) from 14:00 to 18:00. The meeting will take place at the Quebec City Convention Center (i.e., the IETF venue). Please, register early so that we can accurately estimate how many attendees we will have in order to book an appropriate meeting room. Tentatively, we have reserved room 2103, which seems to be able to seat around 60 people. Cheers, Gonzalo On 21/06/2011 4:57 PM, Francois Daoust wrote: > Dear participants in the IETF RTCWEB group, > > The W3C Web Real-Time Communications working group will meet on Saturday 23 July 2011 afternoon, starting at or shortly after 1PM, in Quebec City, Canada, co-located with the IETF Meeting. Exact time range, agenda and location will be announced once known. > > The choice of the date and place is meant to favor synergies between the W3C WebRTC and the IETF RTCWEB groups. Participants in the IETF RTCWEB group are welcome to attend this W3C face-to-face as meeting guests. > > To facilitate logistics purpose, I have set up a registration form, available at: > http://www.w3.org/2002/09/wbs/47318/webrtc-f2f-quebec/ > > Anyone can fill out the form. > People willing to attend the F2F need to register before 15 July 2011 (the sooner, the better). > > Please let me know if you have questions. > > Cheers, > Francois Daoust, > W3C Team Contact for the W3C WebRTC WG. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From magnus.westerlund@ericsson.com Wed Jun 29 00:39:28 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C1B21F86E4 for ; Wed, 29 Jun 2011 00:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.446 X-Spam-Level: X-Spam-Status: No, score=-106.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BAN6l4N2bn7 for ; Wed, 29 Jun 2011 00:39:27 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5753B21F85AD for ; Wed, 29 Jun 2011 00:39:27 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f9-4e0ad6ae0a00 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5B.D1.20773.EA6DA0E4; Wed, 29 Jun 2011 09:39:26 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 29 Jun 2011 09:39:25 +0200 Message-ID: <4E0AD6AD.5050705@ericsson.com> Date: Wed, 29 Jun 2011 09:39:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E0832FE.7010401@ericsson.com> <4E0A2F70.9040305@jdrosen.net> In-Reply-To: <4E0A2F70.9040305@jdrosen.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 07:39:28 -0000 Hi, As an individual. On 2011-06-28 21:45, Jonathan Rosenberg wrote: > Here are some thoughts on additional use cases: > > * information on congestion and receiver side environment for purposes > of improved sender rate adaptation I believe it is important that we have congestion control for the point to point flows for both RTP and non-media data that are implemented and enforced in the browser. This is a pure security and personal hygien question. A rouge application should not be able to consume completely unproportional bit-rates between two peers and be able to starve out applications sharing the bottleneck. Having said that there can clearly be need for application level signals for changing behavior and adopting to what bit-rate or delay characteristics that are available. Especially if you have star or other multi-hop topologies in the application interconnections. For RTP we already propose some such signals like TMMBR [RFC5104] in our RTP for RTCWEB document. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Jun 29 00:39:54 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC48D21F86B4 for ; Wed, 29 Jun 2011 00:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.463 X-Spam-Level: X-Spam-Status: No, score=-106.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2t3ws62aHQB for ; Wed, 29 Jun 2011 00:39:54 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C692D21F85AD for ; Wed, 29 Jun 2011 00:39:53 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-df-4e0ad6c866df Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 31.B5.09774.8C6DA0E4; Wed, 29 Jun 2011 09:39:52 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Wed, 29 Jun 2011 09:39:52 +0200 Message-ID: <4E0AD6C8.8030301@ericsson.com> Date: Wed, 29 Jun 2011 09:39:52 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E00B71D.9010502@ericsson.com> In-Reply-To: <4E00B71D.9010502@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] WG adoption of Architecture and Overview of RTCWEB document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 07:39:54 -0000 WG, we have received no objections against our proposal and hereby adopt https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-overview/ as a WG item. Cheers Magnus Westerlund WG chair On 2011-06-21 17:22, Magnus Westerlund wrote: > WG, > > We would like to adopt a document that describes the RTCWEB architecture > and provides an overview to the functionality that will be specified in > various documents targeted to specific pieces of the functionalities we > need for a complete solution. > > There has been several documents that describes architecture, frame > works or overviews. None of them are complete when it comes to covering > the different aspects. The documents are: > > https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-overview/ > https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-framework/ > https://datatracker.ietf.org/doc/draft-jennings-rtcweb-api/ > > The WG chairs' proposal is that we adopt one document and then add in > aspects that are needed from the other documents. In the process putting > together an good editor team for the WG document from the persons that > has contributed so far and want to continue. > > The WG chairs propose that that the WG adopts: > https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-overview/ > as a WG item to form the core of an Architecture and Overview document. > > WG participants please provide either support for adoption or provide > feedback on any issues you see with this approach. > > Please provide your view no later than Tuesday the 28th at 17.00 CEST. > > Magnus Westerlund > WG Chair > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From stefan.lk.hakansson@ericsson.com Wed Jun 29 03:50:30 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DEB9E8029 for ; Wed, 29 Jun 2011 03:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.072 X-Spam-Level: X-Spam-Status: No, score=-6.072 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eU7OwzBHofUY for ; Wed, 29 Jun 2011 03:50:29 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 586FF9E801F for ; Wed, 29 Jun 2011 03:50:29 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-ac-4e0b0374070d Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.77.09774.4730B0E4; Wed, 29 Jun 2011 12:50:28 +0200 (CEST) Received: from [150.132.141.128] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 29 Jun 2011 12:50:28 +0200 Message-ID: <4E0B0373.3040509@ericsson.com> Date: Wed, 29 Jun 2011 12:50:27 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Comments to use-cases/reqs document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 10:50:30 -0000 All, some comments to (yes, I am one of the authors, but the document now reflects what had been discussed on mail list up to last week) 1. The "Simple video communication service with inter-operator calling" use case derives the requirement "F25: The browser MUST support a baseline audio and video codec". While I think this requirement makes sense it seems a bit odd in this context. To me it rather belongs to a case where the users use different browsers (and perhaps different communication devices using different OSes). 2. Some clarifications should be added to "Multiparty video communication" and "Video conferencing system with central server" (as pointed out in the Minutes from the interim). 3. The "Video Size Change" use case derives F22; but that is already derived in "Simple Video Communication Service". I propose to remove the "Video Size Change" use case. 4. The "Fedex Call" use case derives the DTMF req F19 "The browser must be able to insert DTMF signals in a media stream". I think we made a mistake here, what Cullen said was "there should be a way to navigate the IVR". I think this is a more relevant requirement at this stage. I think the API reg A16 should be removed as it is not clear if this would be done via an API. 5. To me it would make sense to add the NIC change and QoS use cases as extensions to the "Simple video communication service" use case (as is done with "inter-operator calling". 6. I think the structure is a bit strange. E.g. the "Multiparty on-line game with voice communication" use case is not under browser-to-browser even though it is clearly browser-to-browser. So, this is what I propose the structure to look like: 4. Use-cases 4.1. Introduction 4.2. Browser-to-browser use-cases 4.2.1. Simple Video Communication Service 4.2.2. Simple Video Communication Service, access change 4.2.3. Simple Video Communication Service, QoS 4.2.4. Simple video communication service with inter-operator calling 4.2.5. Hockey Game Viewer 4.2.6. Multiparty video communication 4.2.7. Multiparty on-line game with voice communication 4.3. Browser - GW/Server use cases 4.3.1. Telephony terminal 4.3.2. Fedex Call 4.3.3. Video conferencing system with central server With the following changes: 4.2.1 Extended to say that different browsers (and perhaps operating systems) are used, F25 derived here 4.2.6 Clarifications in text 4.3.3 Clarifications in text F19 Changed to talk about navigating in IVR. A16 (DTMF API) removed. F23 (change netw I/F) derived in 4.2.2 F21 (QoS) derived in 4.2.3 F24 (SIP able to carry session setup data) derived in 4.2.4 Comments? Stefan From msimoni@gmail.com Wed Jun 29 05:52:39 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D90811E8075 for ; Wed, 29 Jun 2011 05:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhEcYseNu+qY for ; Wed, 29 Jun 2011 05:52:38 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id ACFDE11E8070 for ; Wed, 29 Jun 2011 05:52:38 -0700 (PDT) Received: by iye7 with SMTP id 7so1325550iye.31 for ; Wed, 29 Jun 2011 05:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=cM23K4MeTkkEhBoy6bzDeREShwWyKnbp9vr+aR94x5Y=; b=gBlWoNSH7JKDl9X4/u5WFW2S1on6FB3akvvc6o2DPPs2GVpRyOyIPmL9bka+RFRPx1 xOamTsvV6Ka81w7FWn4Jd8Jc8M2WZksIEEt7u63+/1lgJ8kLz3Ra2gB2ARjBg1e3G3dL uqlF+HcWk1o5QGAH5NWborPaVVjhYzv8W1GYU= MIME-Version: 1.0 Received: by 10.42.155.4 with SMTP id s4mr779140icw.32.1309351958054; Wed, 29 Jun 2011 05:52:38 -0700 (PDT) Received: by 10.42.222.74 with HTTP; Wed, 29 Jun 2011 05:52:37 -0700 (PDT) In-Reply-To: <4E09E621.6080109@ericsson.com> References: <4E0832FE.7010401@ericsson.com> <4E09E621.6080109@ericsson.com> Date: Wed, 29 Jun 2011 14:52:37 +0200 Message-ID: From: Manuel Simoni To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 12:52:39 -0000 On Tue, Jun 28, 2011 at 4:33 PM, Magnus Westerlund wrote: > When it comes to reliable data I interpret you being a supporter for it. Yes. > However, can you elaborate on any usages you see for reliable object in > web-applications to try to see if there are any requirements we are > missing. A use case would be an audio/video chat program, with the ability to transfer files/documents between peers without needing server-side storage. From dzonatas@gmail.com Wed Jun 29 07:28:17 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A189E800D for ; Wed, 29 Jun 2011 07:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.058 X-Spam-Level: X-Spam-Status: No, score=-4.058 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5XfPOoChjFM for ; Wed, 29 Jun 2011 07:28:14 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 22B4A9E800B for ; Wed, 29 Jun 2011 07:28:14 -0700 (PDT) Received: by pvh18 with SMTP id 18so1090780pvh.31 for ; Wed, 29 Jun 2011 07:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=op4X44A+WWOlry3dcygWF1p4qtoZ3/FF7PhZH311uUU=; b=uI4ZYSrUOBi18emHSfDI78k1b0rmgNYGrUHXi6YP+IyfveyeezOs7O3xcW8QBh9hup XWEyJ7Al4dAIb22ISh0Kdk9FiYgxmj0xu9B2GkmEnE1oWyIaJ/uThDbBCkOhsfsbyzZn G5dFzfm8Y0gpS6a6vBvh5wma21qadLR0x90N8= Received: by 10.68.35.136 with SMTP id h8mr1213381pbj.159.1309357693612; Wed, 29 Jun 2011 07:28:13 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id m7sm930547pbk.86.2011.06.29.07.28.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Jun 2011 07:28:11 -0700 (PDT) Message-ID: <4E0B3658.1080706@gmail.com> Date: Wed, 29 Jun 2011 07:27:36 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E0832FE.7010401@ericsson.com> <4E0A2F70.9040305@jdrosen.net> <4E0AD6AD.5050705@ericsson.com> In-Reply-To: <4E0AD6AD.5050705@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 14:28:17 -0000 On 06/29/2011 12:39 AM, Magnus Westerlund wrote: > Hi, > > As an individual. > > On 2011-06-28 21:45, Jonathan Rosenberg wrote: > >> Here are some thoughts on additional use cases: >> >> * information on congestion and receiver side environment for purposes >> of improved sender rate adaptation >> > I believe it is important that we have congestion control for the point > to point flows for both RTP and non-media data that are implemented and > enforced in the browser. This is a pure security and personal hygien > question. A rouge application should not be able to consume completely > unproportional bit-rates between two peers and be able to starve out > applications sharing the bottleneck. > I would suggest instead of "for purposes of improved sender rate adaption" to "for purposes of manifold adaption", yet that may confuse people that relate usage outside such interface topology. > Having said that there can clearly be need for application level signals > for changing behavior and adopting to what bit-rate or delay > characteristics that are available. Especially if you have star or other > multi-hop topologies in the application interconnections. For RTP we > already propose some such signals like TMMBR [RFC5104] in our RTP for > RTCWEB document. > I couldn't find the link off-hand, yet there exists successful non-stop busy intersection simulations. The downfall with those simulations happens when they assume every vehicle is signal aware. Such simulations do not include trains or multi-trailers. This relates, however, in multi-hop when viewed from intersection to intersection. One may want to demand multi-hop to relieve traffic congestion, which may involve disconnection from star-topologies. What star-topologies want is how to keep-alive the physical tether (simulated or not) through such temporal disconnection. Each star-topology has one centralized physical tether no matter how they divide the coverage (cellular). Besides credit systems for that temporary digital-divide (gap), the best use-case I have seen for such physical tether is games that require centralized physic simulation to avoid cheaters (or train wrecks). The law of conservation is the alternative for less-than-best credit conversion (since the size of each bit is unknown to the observer) while disconnected. ;) -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From fluffy@cisco.com Wed Jun 29 08:07:58 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD119E800D for ; Wed, 29 Jun 2011 08:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyctPwuZCegA for ; Wed, 29 Jun 2011 08:07:57 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC219E800C for ; Wed, 29 Jun 2011 08:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1744; q=dns/txt; s=iport; t=1309360077; x=1310569677; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=lSJmDQHche+8vUSuV9dsj0/fY0YjiDtF/HILNDds3FM=; b=nF3skvZJVUorU9aRz9XxmeAKm5cFCm9ZAkHmgRmbBCXnGxW4G0cWahkc YDO3miZo58Wcbef+a3hWw/2Bubns9V+xNwPwqyHeHiVmqZ7K4ZzKBRjTE N0HlSVrm7vhq/rorBC+kCl9V9vfSLnT9m+5tmBFQQgCwo7HWMEe8NHE0j 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoHAPg+C06rRDoI/2dsb2JhbABSmGSOeHerGYEenhGGMASHNophhHWLVA X-IronPort-AV: E=Sophos;i="4.65,443,1304294400"; d="scan'208";a="472061076" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 29 Jun 2011 15:07:55 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5TF7sVZ021522 for ; Wed, 29 Jun 2011 15:07:54 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Jun 2011 09:07:53 -0600 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Media negeotiation and signalling archatecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 15:07:58 -0000 One of the complicated architectural issues for this WG is what path the = signaling information gets passed over, and in the parts of that that = path that need to be standardized, what does the signaling information = looks like. To help get discussion going on that, I have described 3 = models of how the information could flow in the some pictures in the = following PDF.=20 = http://trac.tools.ietf.org/wg/rtcweb/trac/raw-attachment/wiki/WikiStart/RT= CWeb-Signaling.pdf I split these up into 3 models that I call High, Mid, and Low based on = the path the signaling information goes. There has been a fair amount of = discussion of High and Mid models in the past in this WG thought pretty = much no discussion of the Low model. The interesting things is that when = I look at what is getting implemented and prototyped, a lot of it is the = low model.=20 It certainly possible to support more than one of these but I'm = interested in the pro and cons of all these but from my point of view, = one of the key issues is how hard is for people to use. If you look at = what things have succeeded in HTML, it is typically the things that in = there simplest form provide a very simple interface to use them. Yes, = they might have a more complex form that allows richer control but the = basics are simple. Take the HTML5 video tag for streaming video media = for example. There are zillion things that could have been passed and = controlled to this flag yet the proposals that one out were the ones = that provided something that was incredibly simple to use. Another = example is the iPhone interface to make a phone call from the browser = has been very successful from an adoption point of view.=20 From dzonatas@gmail.com Wed Jun 29 09:16:57 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8CE9E804C for ; Wed, 29 Jun 2011 09:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.981 X-Spam-Level: X-Spam-Status: No, score=-3.981 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smPRMtc-xqA4 for ; Wed, 29 Jun 2011 09:16:55 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6009E8044 for ; Wed, 29 Jun 2011 09:16:55 -0700 (PDT) Received: by pzk27 with SMTP id 27so1533116pzk.27 for ; Wed, 29 Jun 2011 09:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VABBm5pAsd4YYScmwEJQy+482PzUHncPQHzuOHHVuyg=; b=WFmSiHWvVe0unRjpnmZGow5CyZiqJ1L9oBN0KAsAymJrGfF+yWl+hMr4ef6pti3TPY E2aNmJAMiLoqJM1tyOT1Q6qmGkv1JyiPB3pZfV4OhkQ34Tdg1wlrK+n3NVquqGosHmlC 8uCjOYhtK5HKxEXscFhqnO78N7Ebyrbmr3VFc= Received: by 10.68.66.69 with SMTP id d5mr1384392pbt.250.1309364214770; Wed, 29 Jun 2011 09:16:54 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id z7sm1015183pbk.51.2011.06.29.09.16.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Jun 2011 09:16:51 -0700 (PDT) Message-ID: <4E0B4FD0.4020003@gmail.com> Date: Wed, 29 Jun 2011 09:16:16 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Media negeotiation and signalling archatecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 16:16:57 -0000 On 06/29/2011 08:07 AM, Cullen Jennings wrote: > > http://trac.tools.ietf.org/wg/rtcweb/trac/raw-attachment/wiki/WikiStart/RTCWeb-Signaling.pdf > > The computer-mouse with built-in printer provides proof of technology in usage. The graph paper delegates units of space, bits. I'm surprised people have not used the optic-computer-mouse to align what they draw on graph paper (to have the process in reverse from screen to paper). Scalability, so scientists find the scalars and business patents the flow to the engineers. Software patents are not bad for such standardization, yet this begs the question if low, medium, and high are patentable in real-time based on localization. Should we consider the word throttle as one scalar? "Materials" is an easier word as macro-economies and then micro- prefix means essentially low in such relation, without materials. -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From matthew.kaufman@skype.net Wed Jun 29 16:23:34 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6026011E80B9 for ; Wed, 29 Jun 2011 16:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM2LXiuAFxHy for ; Wed, 29 Jun 2011 16:23:33 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6026D11E80B7 for ; Wed, 29 Jun 2011 16:23:33 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 042171715; Thu, 30 Jun 2011 01:23:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mx; bh=k7 FabaQdc49a4Im7G/UZppzA5v4=; b=n3DE+ruwJGlCF8vWSqovB7qnQVNW06+2xQ oWwdtjcD84x14i1C6CYLpiUYNdkdTUeHngW6CaTNsEULY2MEcYHszszYMn7qaQTy 1phej6FXVXONZS9RVELoHZiqDSCjQ60s7k20T1SecehjLQ6kQZRlQHjE/uqH8+F+ aViLMe2N0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=mx; b=vzZdch+FB7GrpsGNCZ/SnA Kh23uvC2rhw0DbiKAttXIEEd29sAxCRm2oEo7ZVmz1X5gi+ryPzU4oRX3pq7gLQA 9Ec4wrYCYrygNzmDx5gr1+vn4dCkOI4XpkSqhQqPdyFJpSBnzeTINPVIe/wtTdcd Riv/K3OmXFoF23YF+ApgA= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id EF26A7F8; Thu, 30 Jun 2011 01:23:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id CAE0C3506E3F; Thu, 30 Jun 2011 01:23:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNFSP2WSjoSt; Thu, 30 Jun 2011 01:23:30 +0200 (CEST) Received: from [172.17.61.96] (50-0-2-20.static.sonic.net [50.0.2.20]) by zimbra.skype.net (Postfix) with ESMTPSA id B65CC3506E2D; Thu, 30 Jun 2011 01:23:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: Date: Wed, 29 Jun 2011 16:23:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <48045F08-B230-4BB8-BD8C-6D65E9EF215D@skype.net> References: To: Cullen Jennings X-Mailer: Apple Mail (2.1082) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Media negeotiation and signalling archatecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 23:23:34 -0000 On Jun 29, 2011, at 8:07 AM, Cullen Jennings wrote: >=20 > One of the complicated architectural issues for this WG is what path = the signaling information gets passed over, and in the parts of that = that path that need to be standardized, what does the signaling = information looks like. To help get discussion going on that, I have = described 3 models of how the information could flow in the some = pictures in the following PDF.=20 >=20 > = http://trac.tools.ietf.org/wg/rtcweb/trac/raw-attachment/wiki/WikiStart/RT= CWeb-Signaling.pdf >=20 > I split these up into 3 models that I call High, Mid, and Low based on = the path the signaling information goes. There has been a fair amount of = discussion of High and Mid models in the past in this WG thought pretty = much no discussion of the Low model. The interesting things is that when = I look at what is getting implemented and prototyped, a lot of it is the = low model.=20 I think this deck is a bit in two ways. First, in the first slide you say (and I agree) that we agree that if = there's >1 web server we don't care how they talk to each other (I'm = suspecting something like SIP in most cases)... but then in the "high = path" you say it "gets complicated to define what happens on the orange = line"... but I disagree here. If we agree that it is SIP and SDP on the = orange line then clearly the things that are needed to do NAT traversal = (ICE) and codec negotiation are all able to be carried in SDP. As = another alternative you could simply carry something that the browser = understood natively on that orange path.=20 In fact in the "low path" slide, you talk about the current Chrome = implementation and the WhatWG proposal, but both of those are actually = suggesting transporting a JSON blob via the "high path" to do the ICE = negotiation... and there's no reason to believe that if you can send the = blob needed to do ICE that you couldn't also do the media type = negotiation via the same path. Second, the "high path" is still needed to do the actual call = signaling... you can't even get the two browsers connected to the two = different web services interested in setting up a session using ICE if = there hasn't been communication over the "high path" to set up a call. Matthew Kaufman From matthew.kaufman@skype.net Wed Jun 29 16:38:20 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494DB21F85D9 for ; Wed, 29 Jun 2011 16:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4eSV7kWapbw for ; Wed, 29 Jun 2011 16:38:19 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB9B21F85D8 for ; Wed, 29 Jun 2011 16:38:19 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id A70071715 for ; Thu, 30 Jun 2011 01:38:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=from :content-type:subject:date:references:to:message-id:mime-version ; s=mx; bh=3tJbqm5MRSOUPPqDAO0wRS4CQdQ=; b=ChqdbU4TqcR6EYx807ahG pQhyPwJ5Q47tsgI61dGRpYMbP3/zF7dNZv657ruItVRlGkzy+1uZvnswVLFlA/KP Nd78mCSWI2ENRaI8jMlJVL7FDPIQx2Xc9ArV8Kbim3iC/CSpjh0oaJDMBbwTZE+Q sSJIlDogJL2IyKfMaxBjqE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=from:content-type :subject:date:references:to:message-id:mime-version; q=dns; s=mx ; b=JToN5WKO+kX30Nnn8QAh82jKkguTiOMRDUUdR+g+8jCjIUoA+BIIbYheCDnE vccM3ImtZri+NvNnshC0ESj8xbu2RcymD3d/2u2Mfxj9Q7qTyEbYqacPjfpih96w C6n7+6KKeXxoTv06Nc6zB4vdyTlK774EQ3jRA0xouR1ifr4= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id A5938170F for ; Thu, 30 Jun 2011 01:38:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 868F73506EA1 for ; Thu, 30 Jun 2011 01:38:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqZmqiwhinag for ; Thu, 30 Jun 2011 01:38:17 +0200 (CEST) Received: from [172.17.61.96] (50-0-2-20.static.sonic.net [50.0.2.20]) by zimbra.skype.net (Postfix) with ESMTPSA id DAEB33506E8C for ; Thu, 30 Jun 2011 01:38:16 +0200 (CEST) From: Matthew Kaufman Content-Type: multipart/alternative; boundary=Apple-Mail-7-371012902 Date: Wed, 29 Jun 2011 16:38:14 -0700 References: <20110629233542.25579.52406.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org Message-Id: <9D227A73-B310-4226-90C8-AFD9963C5022@skype.net> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [rtcweb] Fwd: New Version Notification for draft-kaufman-rtcweb-security-ui-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 23:38:20 -0000 --Apple-Mail-7-371012902 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I wrote up a first pass at browser requirements for a media security = inspector in browsers. Matthew Kaufman Begin forwarded message: > From: internet-drafts@ietf.org > Date: June 29, 2011 4:35:42 PM PDT > To: matthew.kaufman@skype.net > Cc: matthew.kaufman@skype.net > Subject: New Version Notification for = draft-kaufman-rtcweb-security-ui-00.txt >=20 > A new version of I-D, draft-kaufman-rtcweb-security-ui-00.txt has been = successfully submitted by Matthew Kaufman and posted to the IETF = repository. >=20 > Filename: draft-kaufman-rtcweb-security-ui > Revision: 00 > Title: Client Security User Interface Requirements for = RTCWEB > Creation date: 2011-06-30 > WG ID: Individual Submission > Number of pages: 4 >=20 > Abstract: > This document calls for a requirement to be imposed on RTCWEB client > user interfaces whereby the user may inspect the current media > security status. >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail-7-371012902 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = wrote up a first pass at browser requirements for a media security = inspector in browsers.

Matthew = Kaufman

Begin forwarded message:

Date: June 29, 2011 4:35:42 PM PDT
Subject: New Version Notification for = draft-kaufman-rtcweb-security-ui-00.txt

A = new version of I-D, draft-kaufman-rtcweb-security-ui-00.txt has been = successfully submitted by Matthew Kaufman and posted to the IETF = repository.

Filename: = draft-kaufman-rtcweb-security-ui
Revision: = 00
Title: = = Client Security User Interface Requirements for = RTCWEB
Creation date: 2011-06-30
WG ID: = Individual Submission
Number of pages: 4

Abstract:
=   This document calls for a requirement to be imposed on = RTCWEB client
  user interfaces whereby the user may = inspect the current media
  security = status.




The IETF = Secretariat

= --Apple-Mail-7-371012902-- From matthew.kaufman@skype.net Wed Jun 29 17:50:14 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889D111E80C6 for ; Wed, 29 Jun 2011 17:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppXWgl3IqY1Q for ; Wed, 29 Jun 2011 17:50:13 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3E74411E80BA for ; Wed, 29 Jun 2011 17:50:13 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 86A311715 for ; Thu, 30 Jun 2011 02:50:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=from :content-type:subject:date:references:to:message-id:mime-version ; s=mx; bh=6578rx8ItpeSp1odfmZCvPGpqag=; b=J4GC19zxOW2VYb1B4FR5D AZD2LxNVLZxg0zEUxSuFzIkTbDoTEC97pUN7dC+asTFiBFo0KOFavWqtiL/x7MJv M8kx5/BJ2zQG0eK6PPr7vj68E2qbgPR9HNOlpxNl7LCJFsRSEsgU3Dk77w+6+UcB dqQCo/WvpO0FvTiQv4IWLw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=from:content-type :subject:date:references:to:message-id:mime-version; q=dns; s=mx ; b=bNwubBxOJIjDdwEzT2cGyZpPV3oNr4qc4mXUdr6vRr0eCagRoXT8FB836/Ka CfiVxtGIhxOGcpCejOMwO8E0WUtUk8EgWYSu6Kv51CcS84VNaOn2rjKfDOrwZxZ4 1SXEpJdtS6Wyv3v7B+9Sre4Bnjl/wno40ibiTf+DPax5SzY= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 81B507F8 for ; Thu, 30 Jun 2011 02:50:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 641A53506E09 for ; Thu, 30 Jun 2011 02:50:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehEuK79uahHB for ; Thu, 30 Jun 2011 02:50:11 +0200 (CEST) Received: from [172.17.61.96] (50-0-2-20.static.sonic.net [50.0.2.20]) by zimbra.skype.net (Postfix) with ESMTPSA id E0AF83506D9C for ; Thu, 30 Jun 2011 02:50:10 +0200 (CEST) From: Matthew Kaufman Content-Type: multipart/alternative; boundary=Apple-Mail-8-375326899 Date: Wed, 29 Jun 2011 17:50:08 -0700 References: <20110630004852.10947.88695.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org Message-Id: <910D1894-3B1D-49CA-BAEF-9F50FF2B4ADB@skype.net> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [rtcweb] Fwd: New Version Notification for draft-kaufman-rtp-compatible-data-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 00:50:14 -0000 --Apple-Mail-8-375326899 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I wrote up a method for sending unreliable datagrams to the same port as = is being used for RTP, RTCP and STUN that does not conflict with this = usage. It also addresses the security issues involved in allowing = arbitrary datagrams to be sent. Matthew Kaufman Begin forwarded message: > From: internet-drafts@ietf.org > Date: June 29, 2011 5:48:52 PM PDT > To: matthew.kaufman@skype.net > Cc: matthew.kaufman@skype.net > Subject: New Version Notification for = draft-kaufman-rtp-compatible-data-00.txt >=20 > A new version of I-D, draft-kaufman-rtp-compatible-data-00.txt has = been successfully submitted by Matthew Kaufman and posted to the IETF = repository. >=20 > Filename: draft-kaufman-rtp-compatible-data > Revision: 00 > Title: =20 > Creation date: 2011-06-30 > WG ID: Individual Submission > Number of pages: 5 >=20 > Abstract: > This document describes a method for sending unreliable datagrams > that are "compatible" with RTP and RTCP, and STUN usage of = a shared > UDP address and port. >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail-8-375326899 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = wrote up a method for sending unreliable datagrams to the same port as = is being used for RTP, RTCP and STUN that does not conflict with this = usage. It also addresses the security issues involved in allowing = arbitrary datagrams to be sent.

Matthew = Kaufman

Begin forwarded message:

Date: June 29, 2011 5:48:52 PM PDT
Subject: New Version Notification for = draft-kaufman-rtp-compatible-data-00.txt

A = new version of I-D, draft-kaufman-rtp-compatible-data-00.txt has been = successfully submitted by Matthew Kaufman and posted to the IETF = repository.

Filename: = draft-kaufman-rtp-compatible-data
Revision: = 00
Title: = =
Creation date: 2011-06-30
WG ID: = Individual Submission
Number of pages: 5

Abstract:
=   This document describes a method for sending unreliable = datagrams
  that are &quot;compatible&quot; with = RTP and RTCP, and STUN usage of a shared
  UDP address and = port.




The IETF = Secretariat

= --Apple-Mail-8-375326899-- From igor.faynberg@alcatel-lucent.com Wed Jun 29 20:22:53 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C932C11E80D0 for ; Wed, 29 Jun 2011 20:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxfBnUWMdAei for ; Wed, 29 Jun 2011 20:22:52 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id B459011E80E0 for ; Wed, 29 Jun 2011 20:22:52 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p5U3MnjH012490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 29 Jun 2011 22:22:49 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5U3Mn2O020341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 29 Jun 2011 22:22:49 -0500 Received: from [135.244.32.101] (faynberg.lra.lucent.com [135.244.32.101]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5U3MfXZ004091; Wed, 29 Jun 2011 22:22:44 -0500 (CDT) Message-ID: <4E0BEC01.4090809@alcatel-lucent.com> Date: Wed, 29 Jun 2011 23:22:41 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E00A355.2040309@w3.org> <4E0ACA93.8050500@ericsson.com> In-Reply-To: <4E0ACA93.8050500@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [rtcweb] W3C Web Real-Time Communications face-to-face on 23 July 2011 in Quebec City, Canada X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 03:22:53 -0000 Gonzalo, I (and other people in my company) had bought a ticket to Quebec in advance, according to company policy, with the IETF meeting dates in mind. Changing this now is prohibitively expensive. I understand that this is a joint meeting with the W3C (and I do think it is a very good idea to have it). But can this be set up on Sunday or any other day? If not, can we have some conferencing arrangements? With thanks, Igor On 6/29/2011 2:47 AM, Gonzalo Camarillo wrote: > Hi, > > we have scheduled this meeting on the Saturday before the IETF (July > 23rd) from 14:00 to 18:00. The meeting will take place at the Quebec > City Convention Center (i.e., the IETF venue). > > Please, register early so that we can accurately estimate how many > attendees we will have in order to book an appropriate meeting room. > Tentatively, we have reserved room 2103, which seems to be able to seat > around 60 people. > > Cheers, > > Gonzalo > > > On 21/06/2011 4:57 PM, Francois Daoust wrote: >> Dear participants in the IETF RTCWEB group, >> >> The W3C Web Real-Time Communications working group will meet on Saturday 23 July 2011 afternoon, starting at or shortly after 1PM, in Quebec City, Canada, co-located with the IETF Meeting. Exact time range, agenda and location will be announced once known. >> >> The choice of the date and place is meant to favor synergies between the W3C WebRTC and the IETF RTCWEB groups. Participants in the IETF RTCWEB group are welcome to attend this W3C face-to-face as meeting guests. >> >> To facilitate logistics purpose, I have set up a registration form, available at: >> http://www.w3.org/2002/09/wbs/47318/webrtc-f2f-quebec/ >> >> Anyone can fill out the form. >> People willing to attend the F2F need to register before 15 July 2011 (the sooner, the better). >> >> Please let me know if you have questions. >> >> Cheers, >> Francois Daoust, >> W3C Team Contact for the W3C WebRTC WG. >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From blizzard@mozilla.com Wed Jun 29 22:48:19 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CD811E8116 for ; Wed, 29 Jun 2011 22:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21diJOX0GPdU for ; Wed, 29 Jun 2011 22:48:19 -0700 (PDT) Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by ietfa.amsl.com (Postfix) with ESMTP id 22C9911E8096 for ; Wed, 29 Jun 2011 22:48:18 -0700 (PDT) Received: from [192.168.1.3] (173-228-106-53.dsl.dynamic.sonic.net [173.228.106.53]) by mail.mozilla.com (Postfix) with ESMTPSA id EA515AE64643 for ; Wed, 29 Jun 2011 22:48:17 -0700 (PDT) Message-ID: <4E0C0E32.5060806@mozilla.com> Date: Wed, 29 Jun 2011 22:48:34 -0700 From: Christopher Blizzard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E0832FE.7010401@ericsson.com> In-Reply-To: <4E0832FE.7010401@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Non-media data service consensus and requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 05:48:19 -0000 On 6/27/2011 12:36 AM, Magnus Westerlund wrote: > WG, > > At the interim it was planned to have a bit discussion on the datagram > service for RTCWEB. The first question to try to resolve if there > is consensus for including some form of non real-time media (i.e. not > audio, video) service between peers. This is a bit tangled with the > actual requirements and use cases. But there was views both for it and > against it on the mailing list. So lets continue and try to come to a > conclusion on this discussion. > > The use cases mentioned on the mailing list are: > > - Dynamic meta data for Conference and other real-time services > > - Gaming data with low latency requirements > > Does anyone like to add additional use cases? For web browsers we'd (Mozilla) like to see it as a more generic transport service for applications. As part of our web-as-applications work we'd like to break some of the assumptions about how applications are built. In particular, having standalone apps that are downloaded and installed, but built on web technologies where clients can connect with each other is something that's interesting. (HTTP and WebSockets both require connecting via a server intermediary.) If we had a peer to peer connection service, with or without video services, we would be able to connect applications together without servers involved, aside from initial set-up. Bringing back the end to end principle actually matters for our apps strategy. And yes, this is different than what other people are doing. But it's one of the reasons why I've been insistent on data transmission as part of the peer to peer APIs and protocols. So if I put my use case down it would be: - Baselevel communications protocol for application to application communication in browsers. And yes, that's vague. I could use better words there. > > Based on my personal understanding this points to primarily have the > RTCWEB provide a unreliable datagram service. This clearly needs > additional requirements to be secure and safe to deploy, but more about > this below. I still like to ask the WG here a question. > > Are you supporting the inclusion of a unreliable datagram service > directly between peers? Please provide your view and any additional > statements of motivation that you desire to provide. > > Secondly, there is a question if there needs to have something that > provides reliable message (of arbitrary size) or byte stream oriented > data transport between the peers. I personally foresee that people will > build JS libraries for this on top of a unreliable datagram service. If > you desire reliable data service as part of the standardized solution > please provide motivation and use case and requirements. I think that for the app to app case I have to imagine that the most common use case will be reliable transport with both messages and entities being sent back and forth. But the file transfer use case, as well as trying to provide some level of congestion control around audio & video sessions would seem to indicate that we might want to have both, tbh. But I haven't thought deeply on this particular aspect of the discussion. So I'm easily swayed. --Chris From stefan.lk.hakansson@ericsson.com Wed Jun 29 23:41:21 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4593B11E8074 for ; Wed, 29 Jun 2011 23:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+NuUGN09oH4 for ; Wed, 29 Jun 2011 23:41:20 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 15A6011E811B for ; Wed, 29 Jun 2011 23:41:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-04-4e0c1a8fa6df Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 05.54.09774.F8A1C0E4; Thu, 30 Jun 2011 08:41:19 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.110]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 30 Jun 2011 08:41:19 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Cullen Jennings , "rtcweb@ietf.org" Date: Thu, 30 Jun 2011 08:41:18 +0200 Thread-Topic: [rtcweb] Media negeotiation and signalling archatecture Thread-Index: Acw2bla7NgEOoDP3S3mijKWsu6rmOgAfQZAg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Media negeotiation and signalling archatecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 06:41:21 -0000 A couple of quick comments: * The last slide now says that WhatWG proposal is low path; this is not tru= e. The WhatWG proposal as I read it is mute on how the SDPs are exchanged, = it just hands those SDPs over to the application (though high path is indic= ated: "Communications are coordinated via a signaling channel provided by s= cript in the page via the server, e.g. using XMLHttpRequest.") * Notably the WhatWG PeerConnection API does allow both high path and low p= ath. You can exchange all the SDPs over the server as the spec indicates, b= ut if your application initially only sets up a PeerConnection with no medi= a Streams, there will be a peer-to-peer datagram channel available. It can = be used by the web app to exchange the SDPs for media negotiation when you = add Streams (then we have a separate thread on that datagram channel - is i= t reliable or not - or would the app have to add reliability) * Even if you use the low path approach you still need a high path availabl= e all the time. It is needed to exchange candidates so that ICE can be used= to open the low path - and this would have to be done at the start of the = session and every time you do a NIC change (a use case you added BTW!) Stefan >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]=20 >On Behalf Of Cullen Jennings >Sent: den 29 juni 2011 17:08 >To: rtcweb@ietf.org >Subject: [rtcweb] Media negeotiation and signalling archatecture > > >One of the complicated architectural issues for this WG is=20 >what path the signaling information gets passed over, and in=20 >the parts of that that path that need to be standardized, what=20 >does the signaling information looks like. To help get=20 >discussion going on that, I have described 3 models of how the=20 >information could flow in the some pictures in the following PDF.=20 > >http://trac.tools.ietf.org/wg/rtcweb/trac/raw-attachment/wiki/W >ikiStart/RTCWeb-Signaling.pdf > >I split these up into 3 models that I call High, Mid, and Low=20 >based on the path the signaling information goes. There has=20 >been a fair amount of discussion of High and Mid models in the=20 >past in this WG thought pretty much no discussion of the Low=20 >model. The interesting things is that when I look at what is=20 >getting implemented and prototyped, a lot of it is the low model.=20 > >It certainly possible to support more than one of these but=20 >I'm interested in the pro and cons of all these but from my=20 >point of view, one of the key issues is how hard is for people=20 >to use. If you look at what things have succeeded in HTML, it=20 >is typically the things that in there simplest form provide a=20 >very simple interface to use them. Yes, they might have a more=20 >complex form that allows richer control but the basics are=20 >simple. Take the HTML5 video tag for streaming video media for=20 >example. There are zillion things that could have been passed=20 >and controlled to this flag yet the proposals that one out=20 >were the ones that provided something that was incredibly=20 >simple to use. Another example is the iPhone interface to make=20 >a phone call from the browser has been very successful from an=20 >adoption point of view.=20 > > > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb >= From niklase@google.com Thu Jun 30 01:39:59 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60E021F8757 for ; Thu, 30 Jun 2011 01:39:59 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXAxjIzSD9Fu for ; Thu, 30 Jun 2011 01:39:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 01F8D21F873D for ; Thu, 30 Jun 2011 01:39:58 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p5U8dw01007627 for ; Thu, 30 Jun 2011 01:39:58 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309423198; bh=HWoEBK2sRVnDCsj1bizTL2eXabI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Wcv2L1x0H25+nsgxNHMxpfLmoTMnICSlrF02okR0c/716/FNxanQLjiG+KYXuUzNw GGNdRLVMUM0n1l0R+uXtQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=omT05baJNPBomjs3OSsLXtr3t9+8V7BKbM6FTHu0YxhyI9otOGxsRFiWnFE6lGjsH AAZ7cIFI4WmN91+zlzaAQ== Received: from yib2 (yib2.prod.google.com [10.243.65.66]) by wpaz1.hot.corp.google.com with ESMTP id p5U8dvdW011584 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 30 Jun 2011 01:39:57 -0700 Received: by yib2 with SMTP id 2so1001106yib.24 for ; Thu, 30 Jun 2011 01:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aRvAOUNoUH1N6KpCP9SYLyfDkHuy0ktWAS+97CcAGyY=; b=waq1AcfCv8FpI6t4+BsQz+G2XgzS6TypZVIbSAnWUbltLzOsj/KQrrfqLhiKJNwXvx 5xvgJGEDAmI/wcdEXFMQ== MIME-Version: 1.0 Received: by 10.100.146.4 with SMTP id t4mr1478868and.29.1309423196861; Thu, 30 Jun 2011 01:39:56 -0700 (PDT) Received: by 10.100.165.11 with HTTP; Thu, 30 Jun 2011 01:39:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jun 2011 10:39:56 +0200 Message-ID: From: Niklas Enbom To: Cullen Jennings Content-Type: multipart/alternative; boundary=0016e64356188277d704a6e9d8e2 X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Media negeotiation and signalling archatecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 08:39:59 -0000 --0016e64356188277d704a6e9d8e2 Content-Type: text/plain; charset=ISO-8859-1 Cullen, what is meant by "current Chrome implementation" in this doc? At least what we're implementing is not using the Jingle protocol on the net. We are using libJingle internally, but the API we're building is essentially the whatwg proposal with some tweaks. Niklas On Wed, Jun 29, 2011 at 5:07 PM, Cullen Jennings wrote: > > One of the complicated architectural issues for this WG is what path the > signaling information gets passed over, and in the parts of that that path > that need to be standardized, what does the signaling information looks > like. To help get discussion going on that, I have described 3 models of how > the information could flow in the some pictures in the following PDF. > > > http://trac.tools.ietf.org/wg/rtcweb/trac/raw-attachment/wiki/WikiStart/RTCWeb-Signaling.pdf > > I split these up into 3 models that I call High, Mid, and Low based on the > path the signaling information goes. There has been a fair amount of > discussion of High and Mid models in the past in this WG thought pretty much > no discussion of the Low model. The interesting things is that when I look > at what is getting implemented and prototyped, a lot of it is the low model. > > It certainly possible to support more than one of these but I'm interested > in the pro and cons of all these but from my point of view, one of the key > issues is how hard is for people to use. If you look at what things have > succeeded in HTML, it is typically the things that in there simplest form > provide a very simple interface to use them. Yes, they might have a more > complex form that allows richer control but the basics are simple. Take the > HTML5 video tag for streaming video media for example. There are zillion > things that could have been passed and controlled to this flag yet the > proposals that one out were the ones that provided something that was > incredibly simple to use. Another example is the iPhone interface to make a > phone call from the browser has been very successful from an adoption point > of view. > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0016e64356188277d704a6e9d8e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cullen, what is meant by "current Chrome implementation" in this = doc? At least what we're implementing is not using the Jingle protocol = on the net. We are using libJingle internally, but the API we're buildi= ng is essentially the whatwg proposal with some tweaks.

Niklas


On Wed, = Jun 29, 2011 at 5:07 PM, Cullen Jennings <fluffy@cisco.com> wrote:

One of the complicated architectural issues for this WG is what path the si= gnaling information gets passed over, and in the parts of that that path th= at need to be standardized, what does the signaling information looks like.= To help get discussion going on that, I have described 3 models of how the= information could flow in the some pictures in the following PDF.

http://trac.tools.ietf.org/= wg/rtcweb/trac/raw-attachment/wiki/WikiStart/RTCWeb-Signaling.pdf

I split these up into 3 models that I call High, Mid, and Low based on the = path the signaling information goes. There has been a fair amount of discus= sion of High and Mid models in the past in this WG thought pretty much no d= iscussion of the Low model. The interesting things is that when I look at w= hat is getting implemented and prototyped, a lot of it is the low model.
It certainly possible to support more than one of these but I'm interes= ted in the pro and cons of all these but from my point of view, one of the = key issues is how hard is for people to use. If you look at what things hav= e succeeded in HTML, it is typically the things that in there simplest form= provide a very simple interface to use them. Yes, they might have a more c= omplex form that allows richer control but the basics are simple. Take the = HTML5 video tag for streaming video media for example. There are zillion th= ings that could have been passed and controlled to this flag yet the propos= als that one out were the ones that provided something that was incredibly = simple to use. Another example is the iPhone interface to make a phone call= from the browser has been very successful from an adoption point of view.<= br>



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

--0016e64356188277d704a6e9d8e2-- From john.elwell@siemens-enterprise.com Thu Jun 30 10:04:54 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6AA228018 for ; Thu, 30 Jun 2011 10:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.428 X-Spam-Level: X-Spam-Status: No, score=-106.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noxu60IJgUp6 for ; Thu, 30 Jun 2011 10:04:53 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 1037B228015 for ; Thu, 30 Jun 2011 10:04:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1309453491!9032546!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 27196 invoked from network); 30 Jun 2011 17:04:51 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-3.tower-216.messagelabs.com with SMTP; 30 Jun 2011 17:04:51 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id ABFC523F03E2; Thu, 30 Jun 2011 19:04:51 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 30 Jun 2011 19:04:51 +0200 From: "Elwell, John" To: Matthew Kaufman , Cullen Jennings Date: Thu, 30 Jun 2011 19:04:50 +0200 Thread-Topic: [rtcweb] Media negeotiation and signalling archatecture Thread-Index: Acw2s5P8VPVEsNEiRCi2KC8Y0VNtIgAk47pg Message-ID: References: <48045F08-B230-4BB8-BD8C-6D65E9EF215D@skype.net> In-Reply-To: <48045F08-B230-4BB8-BD8C-6D65E9EF215D@skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Media negeotiation and signalling archatecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 17:04:54 -0000 =20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Matthew Kaufman > Sent: 30 June 2011 00:23 > To: Cullen Jennings > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Media negeotiation and signalling archatecture >=20 >=20 > On Jun 29, 2011, at 8:07 AM, Cullen Jennings wrote: >=20 > >=20 > > One of the complicated architectural issues for this WG is=20 > what path the signaling information gets passed over, and in=20 > the parts of that that path that need to be standardized,=20 > what does the signaling information looks like. To help get=20 > discussion going on that, I have described 3 models of how=20 > the information could flow in the some pictures in the following PDF.=20 > >=20 > >=20 > http://trac.tools.ietf.org/wg/rtcweb/trac/raw-attachment/wiki/ > WikiStart/RTCWeb-Signaling.pdf > >=20 > > I split these up into 3 models that I call High, Mid, and=20 > Low based on the path the signaling information goes. There=20 > has been a fair amount of discussion of High and Mid models=20 > in the past in this WG thought pretty much no discussion of=20 > the Low model. The interesting things is that when I look at=20 > what is getting implemented and prototyped, a lot of it is=20 > the low model.=20 >=20 > I think this deck is a bit in two ways. >=20 > First, in the first slide you say (and I agree) that we agree=20 > that if there's >1 web server we don't care how they talk to=20 > each other (I'm suspecting something like SIP in most=20 > cases)... but then in the "high path" you say it "gets=20 > complicated to define what happens on the orange line"... but=20 > I disagree here. If we agree that it is SIP and SDP on the=20 > orange line then clearly the things that are needed to do NAT=20 > traversal (ICE) and codec negotiation are all able to be=20 > carried in SDP.=20 [JRE] And to add to what Matthew says concerning complexity of SIP, much of= the complexity is between a UA and its domain registrar/proxy (e.g., SIP o= utbound, GRUU assignment, Path) and a lot of features that are implemented = on SIP-PBXs, say, only operate between a UA and its domain registrar/proxy = (or B2BUA). In the high path, the web server takes on the role of domain re= gistrar/proxy, so the SIP interface is an inter-proxy, or inter-domain inte= rface, where a lot of the complexities of SIP don't appear. John >As another alternative you could simply carry=20 > something that the browser understood natively on that orange path.=20 >=20 > In fact in the "low path" slide, you talk about the current=20 > Chrome implementation and the WhatWG proposal, but both of=20 > those are actually suggesting transporting a JSON blob via=20 > the "high path" to do the ICE negotiation... and there's no=20 > reason to believe that if you can send the blob needed to do=20 > ICE that you couldn't also do the media type negotiation via=20 > the same path. >=20 > Second, the "high path" is still needed to do the actual call=20 > signaling... you can't even get the two browsers connected to=20 > the two different web services interested in setting up a=20 > session using ICE if there hasn't been communication over the=20 > "high path" to set up a call. >=20 > Matthew Kaufman >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From stewe@stewe.org Thu Jun 30 13:17:54 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D18211E8172 for ; Thu, 30 Jun 2011 13:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brWuik4LafHh for ; Thu, 30 Jun 2011 13:17:53 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC9911E824A for ; Thu, 30 Jun 2011 13:17:52 -0700 (PDT) Received: from [192.168.1.107] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 8010-1743317 for ; Thu, 30 Jun 2011 22:17:51 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Thu, 30 Jun 2011 13:17:43 -0700 From: Stephan Wenger To: Message-ID: Thread-Topic: Agenda time request Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3392284670_6261533" X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: [rtcweb] Agenda time request X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 20:17:54 -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_3392284670_6261533 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi all, We are in the process of finishing an I-D on the subject of scalable codecs for rtcweb. The draft will be uploaded by the =AD00 deadline. If there is a chance, I would like to have a few minutes session time to present it. Yes, the focus will be on technical aspects; both requirements and how they can be met. Regards, Stephan =20 --B_3392284670_6261533 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi all,
We are in = the process of finishing an I-D on the subject of scalable codecs for rtcweb= .  The draft will be uploaded by the –00 deadline.  If there= is a chance, I would like to have a few minutes session time to present it.=
Yes, the focus will be on technical aspects; both requirements an= d how they can be met.
Regards,
Stephan
 =
--B_3392284670_6261533-- From internet-drafts@ietf.org Thu Jun 30 22:52:26 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3E521F88A3; Thu, 30 Jun 2011 22:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xu11f1Uk5g05; Thu, 30 Jun 2011 22:52:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D20121F85D3; Thu, 30 Jun 2011 22:52:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110701055226.2267.16505.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2011 22:52:26 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 05:52:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : Overview: Real Time Protocols for Brower-based Applicati= ons Author(s) : Harald T. Alvestrand Filename : draft-ietf-rtcweb-overview-00.txt Pages : 13 Date : 2011-06-30 This document gives an overview and context 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, unless the RTCWEB chairs have declared consensus on an item. This document is a candidate to become a work item of the RTCWEB working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-overview-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-overview-00.txt